Witam. Mam mały problem... Nie chodzi tyle o techniczne rozwiązania co o teoretyczne rozważania.

Otóż.. Mam witrynę, coś podobnego do randek internetowych połączonych z ocenianiem i komentowaniem zdjęć. Wiadomo, ludzie się rejestrują, logują na swoje konta, więc musze używać sesji.

I pojawia się problem. Używać tylko cookie czy pozwolić serwerowi doklejać SID?

Plusy doklejania SID'a:
- strona wszystkim działa

Minusy doklejania SID'a:
- zastosowałem tzw. session killer, który nie startuje sesji gdy na stronę wejdzie robot wyszukiwarki np. google (dla lepszego indeksowania) ale... z tego co wiem to sesja wystartuje wtedy gdy (pomijam ustawienie serwera session.auto_start) wystartujemy z session_start() lub użyjemy gdzieś session_register(). Pytanie - czy sesja wystartuje gdy użyję $_SESSION ?
- użytkownicy mojej strony często wymieniają się adresami.. Wiadomo co się stanie jeżeli ktoś poda komuś adres z doklejonym SID'em :/ Druga osoba przejmie jego konto... Co prawda staram sobie z tym radzić sprawdzając za każdym razem IP i $_SERVER['HTTP_USER_AGENT'] ale wiadomo, że to nie rozwiązuje do końca problemu.
- zgodnie z manualem do php podczas używania przekierowania header doklejam ręcznie do adresu SID w ten sposób header('Location: http://adres_strony.pl/?'.SID);. Niestety tworzy się w ten sposób mało elegancki adres http://adres_strony.pl/? lub co gorsza z doklejonym SID'em. Użytkownicy mogą sobie takie adresy mieć ale wolałbym nie serwować takich adresów wyszukiwarkom.

Plusy używania tylko cookies:
- nie ma problemów z wyszukiwarkami ani z przekazywaniem adresów między ludźmi bo nigdy nie zostanie doklejony SID

Minusy używania tylko cookies:
- niestety nie wszystkim strona będzie poprawnie działała (nie ma szans żeby zmienili coś w swoim panelu bo po zalogowaniu od razu ich wyloguje :/). Ktoś wie ile osób jest tak bardzo przewrażliwionych, że mają wyłączoną obsługę ciasteczek?


Mam nadzieję, że o niczym nie zapomniałem. Co o tym wszystkim myślicie? Jak sobie z tym radzicie? Co polecacie?

mozesz narzucic swoim gosciom aby wlaczyli cookie, np. wszystkie webowe e-maile wymagaja cookies i ludzie nie maja z tym problemu, ty takrze mozesz, i uwazam ze cookies jest lepsze bo nie zasmieca URL-a

ps. i z tego co ja wiem to malo kto ma wylaczone cookies

Będziesz przejmował się mniejszością? Coś za coś - nie chcą włączyć ciastek, to nie będą mogli korzystać z serwisu. Jak ktoś nie chce syfu w ciastkach, to zawsze może zezwolić konkretnej witrynie na wysyłanie i po problemie.

Za www.ranking.pl:
"Cookies są odrzucane przez niecałe 2% internautów"

wieja - dokładnie. Cookies nie są niebezpieczne, więc nie ma ich co odrzucać.
Ja powiem tak:
olać użytkowników i robić wszystko na ciasteczkach! Sesje mają jeszcze więcej minusów - ktoś wywali hash z linku i już jest wylogowany, albo ktoś podaje drugiemu linki i ten drugi też już wylogowany (inna sesja lub jej brak). To jest beznadziejne rozwiązanie. Można użyć oczywiście zabazy w ini_set tak, żeby sesja traciła się z linków po odświeżeniu, ale to nie ma sensu.
Po prostu cookies

wybacz. bredzisz.

sesje dzialaja niezaleznie od wlaczonych/wylaczonych cookies.
cookies nie dzialaja z wylaczonymi cookies.

o tym do czego nalezy uzywac cookies a do czego sesji nawet nie chce mi sie wspominac...

Bez przesady , az tak sesje nie sa tragiczne

Też mialem z tym problem, ale zajrzałem do skryptu phpBB by Przemo - Przemek wprowadził doskonałe zabezpieczenie przed takim czymś - zrób to samo

jesli poszukasz po forum... to masz mase takich topicow

pozatym mozesz napisac wlasne sesje oparte na bazie danych

No przecież wiem, nie napisałem, że sesje są zależne od cookies...

wytlumacz mi wiec czemu sesje to "beznadziejne rozwiązanie"...

Głównie dlatego, że jest SID w linkach i zostaje się wylogowanym po utracie sesji (o co nie łatwo w przeciwieństwie do cookies).

Zawartość Cookies może być dowolnie nadzorowana przez posiadacza. To tyle o cookies.
Sesje w php to tylko przykład. W wielu wypadkach trzeba tworzyć swoje mechanizmy. Ba! Można je oprzeć na juz istniejących. Np. Można do sesji php dodać IP i przeglądarkę (możecie tez OS). Olać SID - jak masz 4 źródła informacji o użytkowniku, to utrata jednego nie jest tragedią.

No właśnie SID nie można olać - wyszukiwarki tego nie lubią Można dać session.use_trans_sid na off jednak A jeżeli dobrze używa się Cookies, to użytkownik niech sobie modyfikuje co chce, a i tak mu to nic praktycznie nie da Np. jeżeli by przenosić hasło, to lepiej dać jego hash md5

To ja może po kolei odpowiem:


Czyli przyznawanie losowych identyfikatorów sesjom możemy pominąć? To teraz zagadka dla Ciebie Mamy sieć osiedlową, która ma powiedzmy 1000 użytkowników i 10 zewnętrznych adresów IP. 81% użytkowników używa Windowsa XP, a 66% z nich Internet Explorera 6.x. Prosta statystyka, oblicz ilu użytkowników prześle te same dane w żądaniu, jeżeli będziesz ich identyfikował po IP, przeglądarce i systemie operacyjnym, czyli po jednej informacji, którą dzieli przeciętnie 100 użytkowników i dwóch pozostałych przesyłanych w nagłówku, który byle kto może sobie nadpisać. Nie ma innej możliwości niż przesłanie ciastka z unikalnym identyfikatorem sesji do użytkownika. Dopisywanie id do URL żądania bywa niebezpieczne, kiedy zaczyna się kopiowanie linków i nie ma na to pewnego lekarstwa.

Jak odtwarzać sesje, kiedy czas jej życia upłynął? To proste - ciastko z nazwą użytkownika i hashem jego hasła. Jeżeli ukradną mu ciastko, to mogą mu ukraść historię, dane o systemie czy wykorzystać sam jego system do uzyskania dostępu do chronionej treści. Lepszej metody do tej pory nikt nie wymyślił.

Skąd wyszło porównanie sesji do ciastek? Przecież to dwa zupełnie inne mechanizmy, z których jeden korzysta z drugiego. Ciastka sprawdzają się, kiedy mamy do przeniesienia między żądaniami małą ilość informacji. Pomnóż te dane razy dwa, potem pomnóż razy ilość wyświetleń, otrzymasz ilość zmarnowanego transferu. Nie radzę przechowywać innych danych niż jakieś identyfikatory. Od tego są właśnie sesje, które trzymają dane na maszynie serwera, żeby zapewnić ich bezpieczeństwo i oszczędzić trochę ruchu.

Kwestia bezpieczeństwa. Gdzie będziecie trzymać obiekt użytkownika wraz z jego uprawnieniami?
a ) w ciastku, aby użytkownik mógł sobie dopisać jakąś rolę, gdyby odczuł potrzebę.
b ) w ciastku, ale będziemy sprawdzać co żądanie czy nie zmienił danych i zasypiemy bazę masą niewydajnych zapytań
c ) nigdzie, przy każdym wywołaniu strony będziemy pobierać dane z bazy i pobawimy się w optymalizację sql'a.
d ) w sesjach, do których użytkownik nie ma dostępu, a będziemy identyfikować go po ciastku, które będzie miało powiedzmy 73 bajty (32 znaki na nazwę użytkownika, 1 znak na separator, 40 znaków na hash hasła sha1)

To by było na tyle ode mnie.

Masz rację Ludvik. Pośpieszyłem się z tym IP i Browserem .
Dwa tygodnie temu wpadłem na pomysł systemu zabezpieczeń, którego podstawą jest unikalny dokument html/xhtml. Użytkownik przy każdym wywołani strony wysyła pewne okreslone wcześniej (możliwe, że losowe) informacje, które muszą być zgodne z tymi przechowywanymi na serwerze. Czy myślicie, że to byłoby rozsądne i podniosłoby poziom zabezpieczeń? Że jest to wykonalne, to nie mam wątpliwości.

Czyli coś w rodzaju certyfikatów... Nie wiem czy to tak bardzo potrzebne, szczególnie że nie będzie to wygodne dla końcowego użytkownika. Ten plik można tak samo łatwo przechwycić jak ciastko z identyfikatorem sesji. Póki co, to nie wymyślono niczego lepszego niż login, hasło i id sesji (chyba, że ja jestem niedoinformowany) i ja bym przy tym został. Nie bez powodu tak zachowują się domyślnie sesje. Z resztą tak mam to zaimplementowane w swoim systemie autentykacji i nie mam zamiaru tego zmieniać, chociaż pomyślałem o takiej możliwości wcześniej.

IMHO jaki ses maja takie kombinacje jesli połączenia niesa szyfrowane? Itak najsłabszym elementem bezpieczenstwa systemów informatycznych są userzy. Zabezpieczenia stosowane w bankach też są o pupe rozbic jesli user pozwoli sobie wpuscic trojana. System bezpieczeństwa powinien być tak jak cały system informacyjny poddany analizie, projektowi i validacji. Warto tez wyposarzyć go w modół wychwytywania i raportowania prób naruszenia bezpieczeństwa. I powiedzmy sobie szczerze każdy system da sie "złamac" kwestia tylko czasu, pieniędzy i znajomosci socjotechniki, pytanie tylko czy tworzone przeznas systemy musza być mega bezpieczne? Chyba wystarczy: polityka haseł(validacja ich siły oraz wymuszanie ich zmian jesli jest to potrzebne) szyfrowanie połączeń, własny mechanizm sesji (DB i kilka info o hoscie kienta), mechanizm wykrywania prób naruszenia bezpieczenstwa. Wszelkie zwiekszanie bezpieczenstwa ponadto to juz aplety lub aplikacje kryptograficzne po stronie klienta.
Chyba w tym goracu niepopisałem durnoty