Niedziałająca na nowym serwerze aplikacja internetowa korzystająca z obsługi sesji może doprowadzić do rozpaczy, ale nie należy się załamywać. W pierwszej kolejności sprawdzić należy logi, gdyż tam najczęściej znajdują się cenne podpowiedzi. W jednym z ostatnich przypadków zdarzyło się, iż logi zwracały następujące informacje:
Ścieżka wskazywała pliki w których znajdował się kod tworzący i korzystający z sesji.
W związku z powyższym poszlaki wskazywały na problem z sesjami. Proste testy polegające na stworzeniu w czystym pliku sesji z dowolną informacją wykazały, iż sesje na serwerze działają prawidłowo. Test wykonany został w dwóch etapach. Na początku stworzyliśmy sesję, oraz wyświetliliśmy jej wartość w przeglądarce.
Drugi etap to zakomentowanie wiersza odpowiedzialnego za zapis danych do sesji i ponowne wyświetlenie w przeglądarce testowej strony. Jeżeli na ekranie pojawi się ponownie wartość wpisana w kroku poprzednim to sesje na serwerze działają prawidłowo.
Co w takim wypadku powoduje problem z sesjami ??
Jedyne rozsądne rozwiązanie jakie przychodzi do głowy to konfiguracja sesji i jest to prawidłowy tok rozumowania. Okazało się, iż aplikacja nie posiada zdefiniowanego własnego katalogu przechowywania plików sesji w związku z czym korzysta z katalogu domyślnego, który jest wspólny dla wszystkich aplikacji na danym serwerze. Sytuacja powyższa jest problematyczna i niebezpieczna. Po pierwsze korzystanie ze wspólnego katalogu sesji jest zagrożeniem dla bezpieczeństwa danych, gdyż możliwe jest przechwytywanie cudzych sesji celowo, bądź też przypadkiem. Po drugie możliwe są konflikty pomiędzy sesjami różnych aplikacji co właśnie wydarzyło się w omawianym przykładzie.
Rozwiązaniem problemów jest ustawienie parametrów konfiguracji sesji mniej więcej w taki sposób:
Już pierwszy parametr jest zbawienny i rozwiązuje problemy. Pozostałe zamieszczam przy okazji, gdyż przydać się mogą do określenia bardziej szczegółowej konfiguracji polityki obsługi sesji.