Na czym lepiej oprzeć logowanie użytkowników i dlaczego? Na sesjach, czy samych cookies? Jeśli możecie, podajcie także zalety i wady oby dwóch sposobów.
Ważne jest bezpieczeństwo i szybkość.

Ja używam cookies, jakoś bardziej mi przypadły do gustu.

Teraz jade na własnym systemie sesji. Aby przechować sesję w bazie danych używam właśnie cookies (noi do tego adres, ale temat jest o ciastkach).

Własny bazodoanowy system sesji + cookies, czyli jak większość

Logowanie w php-Fusion jest oparte na ciastkach i myślę, że to jest chyba dobry wybór. Nie będzie to serwera obciążać. W COOKIES będzie ID, login i hasło MD5 - nie za dużo? Jeśli się mylę, poprawcie. Może jednak lepiej to oprzeć na sesjach lub zrobić wybór w tym CMSie dla admina (ale wtedy znów więcej kodu trzeba pisać)? Czy jeszcze inaczej?
Zdarzyło się, że na WindowsXP (localhost) jakiś plik sesji miał ponad 1GB.

Ponieważ ważna jest też szybkość generowania, czy takie elementy jak nazwa katalogu skórki i język (niezarejestrowani powinni mieć dostęp do zmiany tych elementów) powinny być przechowywane w COOKIES?

Wystarczy ID, na jego podstawie będzie sprawdzane hasło i user. ID będzie unikalne i niepodrabialne, bo gdy przekroczy limit czasu to następuje zniszczenie sesji, ale gdy user jest aktywny to przekierowuje dane sesji.

@MP1 -> takie rzeczy trzyma się w sesji, a nie w cookies (czyli np w db jeśli sesja tam się trzyma)

Sesje w DB... Trzymać je w bazie? Tam będzie miejsce dla danych o użytkownikach.
Nie lepiej będzie użyć obsługi sesji wbudowanej w php?
Co wtedy, gdy serwer nie obsługuje sesji? Zrobię chyba wybór dla admina, gdzie wpisane przez użytkownika dane mają być przechowywane.

Skórkę i ID możnaby właściwie w cookies trzymać (nie jest to dużo danych), ponieważ jeśli byłoby to w sesjach przechowywane, a strona, która będzie oparta na tym CMSie będzie popularna, a każdy by zmieniał te dane, niezły śmietnik by się zrobił na serwerze.
Jeśli byłoby to w bazie, byłoby to dostępne tylko dla zarejestrowanych.

Ja właściwie również lubię używać ciastek, tyle że ....

Jakiś czas temu popełniłem taki mały portalik, w któym logowanie było oparte na cookies. I dość szybko trzeba było odpowiadać na maile ludzi, którzy włączyli sobie radośnie w Windowsie jakiś tam "największy stopień bezpieczeństwa" i których potem przerastało włączenie sobie obsługi cookies w "jedynej słusznej" przeglądarce (czyt. IE).

W sumie zależy co i dla kogo się pisze

Zdecydowanie cookies. Pomijając przykład soldata jest to najlepszy wybór.
Z sesjami jest zawsze kłopot.

A utworzenie użytkownika o nazwie Anonymus to co? Sesje dla gości też są przydatne...

No i co wtedy? Jeden użytkownik anonimowy zmienia skórkę i wszyscy pozostali goście mają taką mieć? Podobnie z językiem...

moim zdaniem takie rzeczy jak preferencje powinno trzymac sie w tabeli z danymi o userach, a w zmiennych sesyjnych przede wszystkim id usera + jakis unikalny token. w szczegolnych uzsasadnionych przypadkach takze inen dane... ale to tylko w szczegolnych ;-)

Wtedy się robi:

[PHP] pobierz, plaintext 
<?php
if($_POST['nick'] == 'Anonymus' || $_POST['nick'] == 'anonymus'  )
{
die('nieporawny uzytkownik');
}
?>
[PHP] pobierz, plaintext 

jeśli Anonymous to mocno ograniczone możliwości (odczyt, dostep do okreslonych widoków)

sesje + db + session handler - super sprawa!

Ja tam jestem za mocno ograniczonym Anonymusem...
@Ociu -> to się jednek przydaje, lepszy wgląd do tego co robią użytkownicy-goście
@pillot -> sesje + db + SH = goodgoodgood etc
W tej sprawie pełne poparcie. Powiedzmy, że gość otrzyma widok strony głównej i na widok downloadu, ale już nie ściąganie

Chodziło mi o zabezpieczenie rejestracji, przed właśnie takim userem.

Zdecydowanie odradzam COOKIES z 2 powodów:

1 - user ma wyłączoną obsługę COOKIES i się nie zaloguje
2 - dane trzymane w COOKIES można podejrzeć, a co za tym idzie poprzez zmianę tych danych w ciasteczku oszukać system.

Grzechem jest równiez trzymanie w COOKIES wszelkich loginów, haseł, itd. Jestem STANOWCZO NA TAK za sesjami, baza danych nie jest wymagana. Wystarczy zapisać do sesji id sesji, status usera, czy zalogowany, itd. a to wszystko zaszyfrować bądź hashować. Wtedy bezpieczeństwo jest duże. Bo kto w 42 znakowym hashu domyśli się co tam jest zapisane

weg najnowszych danych ranking.pl 98,1 % odwiedzajacych polskei strony ma wlaczone cookies. wymuszanie cookies + wyjasnienie dlaczego chcemy wlaczonego cookies + opisana polityka prywatnosci jest pewny sposobem aby userzy wlaczyli cookies dla naszej strony



mozna to rozwiazac przez odpowiedni system unilanych tokenow czy cos w tym rodzaju. samego loginu czy id oczywiscie trzymac sie nie powinno.



wystarczy ze ktos mi da adres z id sesji na koncu i po sprawie... nie musze znac loginow, hasel, itp. system sam mnie zwerfikuje po id sesji...

Dlatego pisze się własny system sesji, a o ty, czy jest się zalogowanym trzyma się albo w ciachu, albo w adresie.

Proponujecie oprzeć system logowania na własnych sesjach przechowywanych w bazie. W jaki sposób? Jeśli w ciastkach zapisywany byłby sam ID, można w ten sposób uzyskać dostęp do konta innego usera.
Np. w SQLu zapisywane są wpisane w formularzu dane. Jeśli są zgodne z prawdziwym loginem i hasłem, jesteśmy zalogowani.
W ciasteczku zmieniamy wartość ID na inny z nadzieją, że użytkownik nie wylogował się ręcznie. W ten sposób uzyskujemy dostęp.

Trzymanie wpisanych danych w cookies to jednak bezpieczniejsze rozwiązanie, gdy hasło zapisujemy w MD5().
Są 2 ciastka. Jedno zawiera tylko indetyfikator sesji, zaś drugie - dane (login, hasło MD5 - potrzebne wtedy, gdy sesja wygaśnie).

Tak poza tym - długo trwa wysyłanie danych ciastka z loginem i zakodowanym MD5 hasłem? php-Fusion też trzyma w cookies. Wtedy po co pchać sesje?

http://www.php.pl/index.php/phppl/artykuly...handler_czesc_i
A no np. w ten sposób
A wracając do ciastek - zakładamy wrzucasz ID - ja znam kod wiem, że np. dzięki MD5 hashujesz id - a ja sobie zshashuje jakiś inny ID - wrzuce do ciastka i co wtedy ?

No, ale sesje php działają nawet bez cookies, bo wtedy php samo dodaje ID sesji do linków. A jak to zrobić swoim skryptem??

Znaczy się co ?
Dodanie SID następuje automacznie na 99% serwerów.

Co myślicie o logowaniu:

[PHP] pobierz, plaintext 
<?php
  if (!isset($_SERVER['PHP_AUTH_USER'])) { 
	header('WWW-Authenticate: Basic realm=\"My Realm\"');
	header('HTTP/1.0 401 Unauthorized');
	echo 'Tekst do wysłania, jeśli użytkownik wciśnie przycisk Anuluj';
	exit;
  } else {
	echo &#092;"<p>Hej {$_SERVER['PHP_AUTH_USER']}.</p>\"; 
	echo &#092;"<p>Twoje hasło to {$_SERVER['PHP_AUTH_PW']}.</p>\"; 
  }
?>
Powyższy przykład pochodzi z podręcznika php.
[PHP] pobierz, plaintext 

Czy wykorzystując logowanie przeglądarki nie byłoby lepsze? Większość ten sposób obsługuje (jak tam z Lynx?). Wtedy nie byłoby skryptowego zapamiętywania hasła, przeglądarki mają taką możliwość (IE, Firefox na pewno).


Więc jak jest najbezpieczniej? Zaraz... da się problem rozwiązać z SQLem.

BŁĄD/ROZWIĄZANIE 1.
Wpisane dane - komórki w SQLu (sesje własne)
Indetyfikator sesji - cookies
Typ autoryzacji: sprawdzenie, czy w ID sesji (pobranym z cookies) w SQLu wpisane dane są takie same, jak w danych o użytkowniku.
Błąd: zmiana ID sesji może spowodować dostęp do innego użytkownika.
Rozwiązanie: dodatkowy element - kod ochrony (także zapisywany w cookies) oraz szyfrowanie.

Czy to dobre rozwiązanie? Każda sesja ma inny kod ochrony (generowany m. in. funkcją RAND).