Czas wygaśnięcia sesji

[michalk]

Witam!

Mam problem z panelem obsługi jednego skryptu. Po zalogowaniu się bardzo szybko kończy mi się sesja. Dowiedziałem się, że zmienia się to w php.ini. Na niektórych serwerach można zmienić przez ini_set, ale problem w tym, że wartość mam na 30 minut, a sesja na pewno tyle nie trwa. Co jeszcze można zrobić?

[stat4seo]

w .htaccess

php_value session.gc_maxlifetime 3600

i w php

ni_set('session.gc_maxlifetime', '3600');

i potem wywołaj

phpinfo();

dla sprawdzenia wartości.

[Mion]

session_set_cookie_params

[slawek22]

Z tym może być problem.

ini_set('session.gc_maxlifetime', '3600');

Jeśli masz wiele skryptów na jednym dzielonym koncie to teoretyczna długość życia sesji dla każdego z nich to długość trwania najkrótszej sesji. Jeśli plik sesji jest starszy niż gc_maxlifetime to zostaje skasowany.

Teraz masz jeden skrypt w którym ustawiasz sesje za pomocą ini_set na 30 minut i niby jest ok. Tyle, że drugi skrypt ma gc_lifetime dajmy na to ustawione na 10 minut. Teraz po wykonaniu drugiego skryptu WSZYSTKIE sesje które są starsze niż 10 minut zostają usunięte.

Ja mam taki kod:

session_set_cookie_params(3600*24*7 , '/', '.domena.com');	
ini_set("session.cache_expire", 60*24*7); // minutes
ini_set("session.gc_maxlifetime", 3600*24*7); 
() session_save_path("/tmp/long_sessions");

[Kobol]

A co trzymasz w tej sesji?

Jeśli jakieś dane, które możesz odtworzyć z bazy, to możesz temat ugryźć od innej strony. Tj. dajesz ciastko userowi, i przed rozpoczęciem wykonania skryptu patrzysz czy user ma ciacho a nie ma sesji. Jeśli tak jest to ją rozpoczynasz wczytując wszystko do sesji. W wielu frameworkach do php są tzw. filtry, które pozwalają wykonać tego typu zadania automatycznie dla każdej akcji.

Zazwyczaj wystarcza jeśli chodzi o logowanie, przechowywanie danych koszyka w sklepie (oczywiście jeśli te dane masz również w bazie, bo trzeba je wczytać jeśli sesja się zakończy).

[slawek22]

Nie wiem po co to, ale to nic dobrego nie jest. Jedynie spowalnia i komplikuje działanie skryptu. Bo masz 2 identyfikatory sesyjne i dane rozwalone na dysku i w bazie. Plus filtry. Jakby to nie było jeszcze dość dziwne i jakby po prostu nie można było zwiększyć czasu życia jednego cookie który już i tak jest tworzony, trzeba zrobić drugie i powiązać go z pierwszym, kosmos Jak będziesz chciał znowu zwiększyć czas życia sesji to zrób jeszcze trzecie cookie i kolejne powiązanie

Daj sobie spokój z takim pieprzeniem się. Jeśli dane są w bazie to się je pobiera kiedy potrzeba a nie na początku sesji to raz. 2 - Będziesz przepisywał pół skryptu kiedy ten mechanizm w końcu okaże się zbyt wolny. No i jeszcze 3 - php ma wystarczająco dużo natywnych modułów obsługi sesji które są kilkakrotnie szybsze niż obsługa sesji implementowana jako kod PHP i do tego jeszcze jakieś inne dziwactwa, stawiam że to będzie działać 5-100x wolniej.

Zmiana dobrze rozwiązanego mechanizmu sesji to zmiana 1 linijki w kodzie, w wypadku takiego podejścia do sprawy ... przepisanie połowy skryptu od nowa.

[Kobol]

Sławku chyba trochę dramatyzujesz ;-) Z tego co piszesz to myślę, że trochę źle zrozumiałeś moje intencje.

W dobrym frameworku takie "odświeżenie" sesji to 5 linijek kodu - ładne i przejrzyste rozwiązanie nie komplikujące kodu akcji itp. - wszystko ładnie ustawiasz w pliku konfiguracyjnym.

W ten sposób np. bardzo często robię filtry typu "rememberMe", który pozwala na "zalogowanie" usera powracającego po tygodniu z ciastka, czy np. wczytaniu wartości koszyka i ilości produktów po wygaśnięciu sesji.

Jeśli chodzi o przejrzystość kodu to filtry są IMHO genialnym rozwiązaniem. Co do dodatkowego obciążenia... no umówmy się te parę linijek kodu nie robi różnicy chyba, że z aplikacji korzysta na codzień 500.000 userów.

Co do rozbicia danych na sesję i bazę, przecież i tak zawsze dane z sesji trzymasz w bazie. W przypadku logowania przecież posiadasz i tak id usera w bazie, w sklepie masz produkty z koszyka i tak w bazie itd. Przecież nikt nie trzyma danych tylko w sesji, bo sesja... to sesja i zawsze może ją szlag trafić. Oczywiście nie mówię, że wszystko trzeba trzymać w sesjach, ale są rzeczy, które warto powielić w sesji... Przykładowo masz sklep - nie wiedzę sensu za każdym odświeżeniem obliczać sumy produktów w koszyku ich ilości itp - wydajniej jest zrobić to raz i trzymać w sesji.

[slawek22]

Jakoś te rozwiązanie mnie nie przekonuje. Nie chodzi mi o to, że niepotrzebnie powielasz dane z bazy (potrzebnie albo nie, nie wiem, nie widziałem skryptu), tylko o to, że niepotrzebnie tworzysz kopię danych sesyjnych.

Zapisujesz 2 razy te same dane, raz w sesji i kopiujesz zawartość sesji do bazy, wiążesz to z losowym ID cookie. Potem pozwalasz, żeby sesja wygasła i ładujesz znowu te same dane z bazy do sesji (remember me). To nie lepiej po prostu ustawić dla sesji dłuższy czas życia lub dodać do bazy pole mówiące o tym, kiedy sesja wygasa?

[Kobol]

Oj, źle mnie zrozumiałeś. Nigdy nie działam w kierunku zapisu danych z sesji do bazy - raczej sesje w wielu przypadka wykorzystuję do przechowania danych, które mam w bazie, żeby zredukować liczbę zapytań - np. login usera, wartość koszyka towarów etc. W przykładowym sklepie możesz zaoszczędzić ~3-5 zapytań do bazy na każde wywołanie, a to już sporo.

Co do przedłużenia sesji to nie zawsze jest to możliwe na serwerze współdzielonym - sam ostatnio walczyłem z panelem do pisania artykułów, gdzie często podczas pisania arta wygasała sesja - zrobiłem chyba wszystko co znalazłem w sieci aby tą sesję przedłużyć, ale nie zadziałało - ostatecznie zrobiłem 5 linijek z filtrem i po kłopocie.

Zresztą czasami sesję chcesz odnowić dla użytkownika powracającego - np. automatyczne logowanie usera na forum - filtr w takim przypadku do mnie bardzo przemawia jako eleganckie rozwiązanie.

Ogólnie zdaje mi się, że ogarniam o co Tobie chodzi (o jakie przypadki) i tu się zgodzę, ale często moje podejście ma sens. Też nie jestem zwolennikiem trzymania połowy skryptu w sesji. Wiadomo, że zawsze trzeba podejść do problemu na logikę i zobaczyć co się opłaca.