2011-02-08 15 views
9

byłem obserwując identyfikatory sesji nad kolejnymi wnioskami i przestrzegać pewnych rzeczy nie mogę wyjaśnić:Zamieszanie nad identyfikatorów sesji za pomocą connect

1) Dzwoniąc req.sessionID vs. req.cookies["connect.sid"] wartości są różne (wydaje sięrequest.sessionID jest magicznie zwracającym identyfikator SID z powiązanej odpowiedzi - co wydaje mi się niemożliwe).

Z mojego rozumienia kodu źródłowego Connect, req.sessionID jest synonimem klucza cookie, dlaczego różnica?

2) Po pierwszym uruchomieniu żądania z serwera węzła przeglądarka otrzymuje identyfikator SID (nazwijmy to SID1). Przy następnym połączeniu przeglądarka otrzyma SID2. Trzeci i kolejny raz ponownie otrzymuję SID2. Dlaczego węzeł + Connect wystawia dwa identyfikatory sesji, zanim się uspokoi?

+0

Myślę, że znalazłem rozwiązanie, wyjaśnienie poniżej w odpowiedziach. – Matt

Odpowiedz

8

Więc to co ja zawarły:

1) Ponieważ wniosek przechodzi middleware/modułów, mogę tylko przypuszczać, obecny SID jest przymocowana do wniosku przed zalogowaniu kopnięć w. Byłoby to częściowe wyjaśnienie, dlaczego req.sessionID może zawierać SID2, gdy req.cookies["connect.sid"] zawiera poprzedni SID1.

Niektóre Ostrzeżenia:

  • Zjawisko to występuje tylko wtedy, gdy przeglądarka łączy się po raz pierwszy do nowej instancji serwera węzła.

  • Przeglądarka musi być połączona z poprzednim wystąpieniem serwera węzła, który wydał plik cookie o tej samej wartości klucza (np. connect.sid).

2) Po wgląd wokół kodu źródłowego zarówno sezamowy i Połącz Doszedłem do zrealizowania one prowadzić rejestr wszystkich identyfikatorów sesji, które wydały - nieznanych wcześniej do mnie. Podejrzewam, że jest to jeden krok w kierunku zapobiegania fiksacji sesji.

Pamiętając o tym zdałem sobie sprawę, że SID1 wysłano w żądaniu podczas początkowego połączenia z poprzedniego pliku cookie sesji. Connect będzie szukał sesji w swoim magazynie sesji pasującej do SID1 wysłanego cookie, ale ponieważ było to nowe wystąpienie serwera węzła (tylko sesje pamięci, brak trwałych sesji ATM), nie udało się go znaleźć, stąd nowy identyfikator SID (SID2) zostanie wydany - ten do przyklejenia. Powinienem o tym pomyśleć wcześniej. :)

TL; DR Oczekiwany sposób zachowania. Pliki cookie ze starych sesji nie są ponownie wykorzystywane ze względu na bezpieczeństwo.

3

Numer req.sessionID jest taki sam jak req.cookies["connect.sid"].

Jeśli jednak użyłeś supervisor lub nodemon, serwer zostanie zrestartowany po zmodyfikowaniu plików. Gdy serwer zostanie zrestartowany, usunie wszystkie sesje przechowywane przez serwer, ale klient nie wyczyścił starego identyfikatora sesji przechowywanego w pliku cookie. Możesz więc uzyskać różne parametry sessionID.

Aby uzyskać więcej informacji, zobacz numer this answer.

Powiązane problemy