System sesji

[MMP]

Sprawa wygląda następująco...

System sesji ma podtrzymywać użytkownika jako zalogowanego. Znam dwie metody na napisanie własnego systemu sesji opartego na bazie danych.

Pierwszy:

Update sesji wykonujemy na początku kodu. Wykonane zostanie to odrazu jak strona zacznie się ładować.

Minusem tego rozwiązania jest to że jeżeli będziemy chcieli coś włożyć do sesji system musi wykonać dodatkowe zapytanie. Ilość dodatkowych wpisów do sesji = Ilość zapytań.

Drugi:

Update sesji wykonujemy na końcu kodu. Podczas trwania aplikacji możemy zebrać wszystkie dane które mają trafić do sesji i zapisać je na końcu razem z prawidłowym updatem sesji.

Jednak te rozwiązanie ma także minus. W wypadku gdy klikniemy w jakiś odnośnik a następnie przerwiemy ładowanie strony sesja może się zgubić( cookie nie zgra się z zapytaniem do bazy ) i użytkownika wylogować.

Tak źle i tak nie dobrze. Ma ktoś jakieś pomysły?

[mrtn]

po peirwsze musisz rozdzielić oprogramowanie na warstwy:

danych, przetwarzania i prezentacji.

wtedy wsadzisz sesję gdzie chcesz

[MMP]

Mrtn, można powiedzieć że tak mam, stosuje uproszczone MVC.

Aktualnie stosowałem drugie rozwiązanie, ale odkryłem że w wypadku gdy użytkownik się rozmyśli to Cookie się wysyła, ale modyfikacja danych w DB już się nie wykonuje - albo na odwrót. Zależy jak dam w kodzie.

Przejrzałem kod Code Igniter i widziałem że modyfikacja jest wykonywana na starcie, jak i przy każdym zdeklarowaniu zmiennej sesyjnej.

[mrtn]

czemu nie korzystasz z sesji PHP-owych ?

[MMP]

I to będzie chyba prawidłowa odpowiedź.

No nic, przepisanie klasy to 10minut roboty, jak nie będzie działać to będę kombinować dalej.

[Bełdzio]

bo nie są bezpieczne :-)

@MMP nie znam Twojego kodu, ale przekładając Twój dylemat na mój kod wywoływałbym zapis sesji po uruchomieniu akcji tzn:

wywołanie akcji -> akcja robi co do niej należy -> zapisanie sesji

[MMP]

Bełdzio, możesz przybliżyć niebezpieczeństwo sesji z php. Nie mam siły już o tej godzinie wertować Google.

Tak właśnie mam to zrobione, no ale sesja się traci.

[mrtn]

w 9 przypadkach na 10 czy którzy uznają sejse php za niebezpieczne sami robią ich odpowiedniki pełne dziur.

od kilku wersji php sesje są całkiem całkiem dobre !

[tomick]

Można przejąć sesję uprawnionego użytkownika poprzez zdobycie jego SESSION_ID. Można przechwycić ten identyfikator na całą masę różnych sposobów, które zostały opisane tutaj:

Wikibooks

Google Cache

Blog Łukasza Lacha

Dobry mechanizm sesji, oparty na bazie MySQL napisał Tomasz Jędrzejewski - więcej tutaj.

[mkr]

Jak dla mnie podstawą w sesjach jest weryfikacja IP i co najmniej przeglądarki przy akceptacji ID sesji. I sądzę, że taki mechanizm dla przeciętnego serwisu wystarczy.

Sesje oparte na bazie danych często powodują w moim wypadku spowolnienie strony (1-3 sekund, czasem dłużej) w godzinach szczytu, przy kilkuset osobach online. Od kilku ostatnich projektów wróciłem z powrotem na sesje z PHP.

[MMP]

Tomick dzięki, ale .... przed wszystkim się zabezpieczyłem. Myślałem że coś nowego się pojawiło.

Dobry mechanizm sesji, oparty na bazie MySQL napisał Tomasz Jędrzejewski - więcej tutaj.

Taki mechanizm nie ma PODSTAWOWE funkcji sesji - zmiennych sesyjnych. Co mi po takiej klasie?

[jubi]

MMP pisałem Ci o tym dzisiaj na ircu

[tomick]

Tomick dzięki, ale .... przed wszystkim się zabezpieczyłem. Myślałem że coś nowego się pojawiło.

Dobry mechanizm sesji, oparty na bazie MySQL napisał Tomasz Jędrzejewski - więcej tutaj.

Taki mechanizm nie ma PODSTAWOWE funkcji sesji - zmiennych sesyjnych. Co mi po takiej klasie?

Ja to rozwiązałem w taki sposób, że sobie dopisałem funkcję, która operuje (w moim przypadku był to profil użytkownika) na pozostałych polach bazy i tyle :-)

[slawek22]

Żeby nie było możliwe przejęcie SID w prosty sposób wystarczy włączyć sesje tylko po cookie, albo zmienić nazwę zmiennej w kongiguracji PHP. To czy sesja jest w bazie czy w pliku nic w tym wypadku nie zmienia, mechanizm identyfikacji użytkownika jest taki sam, bo innego po prostu nie można zaimplementować przy użyciu HTTP, ważne tylko, żeby identyfikatory generowały się możliwie losowo.

Jeśli dwóch użytkowników wyśle takie samo zapytanie HTTP z tego samego adesu to nie można go w żaden sposób rozróżnić, bo wszystkie ciastka i parametry będą takie same.

Fakt sesje na bazie mogą być bezpieczniejsze kiedy ktoś źle skonfiguruje prawa dostępu i wszyscy na serwerze mają dostęp do folderu z sesjami Ale to chyba ekstremalny przypadek. Przecież baza jest w pliku, więc jakim cudem sesje które są w jedym pliku mają być bardziej bezpieczne od sesji które są w drugim pliku o innej strukturze

[tomick]

Może dlatego, że aby dostać się do katalogu danych w MySQL potrzebna jest inwencja administratora serwera. Częściej jednak występują kardynalne błędy dotyczące dostępu do /home/mieciu na shared hosting