Session handler, Czy opłaca się trzymać osobno zmienne? Opcje

[Prph]

Witam,

W PHP5 zaawansowane programowanie autorzy przedstawili mechanizm obslugi sesji, ktory trzymal zmienne w osobnej tabeli. Dzieki tezmu wydajnosc miala nieco wzrosnac.

Takie rozwiazanie jednak ma pewna wade - zmienne pobierane za z sesji poprzez metody __get i __set, nie zaś $_SESSION['zmienna'];

W chwili obecnie przysparza mi to więcej problemów niż mogłem to sobie wyobrazić.

Jak Wy organizujecie session handlera? Jest sens dzielenia sesji na zmienne i info o sesji?

Pozdrawiam,
Adrian.

[hawk]

@Prph:

1) Sesja, tak jak pisze Ociu, powinna być jednak oddzielona od uwierzytelniania. Bo jedno i drugie ma mało wspólnego. Można mieć przecież otwartą sesję nie będąc uwierzytelnionym (zalogowanym). Łącząc to bardzo się ograniczasz:
- tworzysz obiekt User, mimo że klasa sesji nie ma co z tym obiektem zrobić i w efekcie zwraca puste nie-wiadomo-co
- nie możesz wybierać źródła danych o użytkownikach (DB, pliki passwd, SMB i inne, LDAP, ...)
- nie możesz rozbudować uwierzytelniania chociażby o przypisanie użytkownika do grup, bo wszystko jest hard-coded w klasie sesji

2) Bug: wcale nie jest powiedziane, że session_name() == 'PHPSESSID', a twój kod to zakłada. Poza tym, nie jest powiedziane, że sesje przekazywane są przez cookies, chociaż to akurat założenie ma chyba wiele kilka zalet.

3) Sprawdzanie poprawności sesji (tutaj: user agent) nie powinno odbywać się w klasie sesji. Takie rozwiązanie powoduje, że:
- nie można tej funkcjonalności wyłączyć, gdy nie jest potrzebna
- nie można jej rozszerzyć, gdy nie jest wystarczająca
A przecież można zaprojektować to obiektowo, i dodawać do obiektu sesji obiekty "walidatorów", które sprawdzałyby poprawność i ew. zapisywały sobie user agent, referrer, IP lub inne dane potrzebne później do walidacji. Prosto, łatwo, obiektowo (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) .

4) Bardzo mi się za to podoba usuwanie niepotrzebnego cookie oraz przede wszystkim wywalanie sesji, gdy w cookie przyszedł session id nie istniejący w bazie. Domyślnie php (na plikach) tworzy wtedy nową sesję z podanym ID i dziura w bezpieczeństwie gotowa (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

5) Nie podoba mi się natomiast wywoływanie metody _checkForActiveSession() z konstruktora. To zdecydowanie za wcześnie. Po pierwsze, nie wiadomo, czy sesja na pewno będzie na tej stronie potrzebna (może obiekt był utworzony na zapas, a session_start() nigdy nie będzie wywołane?). Po drugie, nie wiadomo, jaka będzie nazwa sesji. Weźmy taki kod:

[PHP] pobierz, plaintext 
<?php
$s = new Session();
session_name('foo');
session_start();
?>
[PHP] pobierz, plaintext 

Powyższy kod zakończy się pewnie katastrofą.

6) W metodzie _readSession, po stworzeniu nowej sesji nie ma sensu odczytywać jej z bazy (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)