Koszyk w sesji czy w bazie? Opcje

[usb2.0]

Witam
jak w temacie
sam nie wiem jak do końca to rozwiązać więc czekam na za i przeciw.
Pozdrawiam

[viking]

Tak czytam i aż mnie dziw bierze jak bardzo ludzie nie rozumieją o co chodzi w sesjach. Sesje to nasz pośrednik pomiędzy klientem i serwerem w bezstanowym protokole HTTP. Aby móc powiązać te dane potrzebujemy:
- utworzyć identyfikator sesji (SID czy jakkolwiek go sobie nazwiemy)
- gromadzić dane sesji

Sesje implementujemy po stronie klienta za pomocą:
- doklejania parametru sesji (SID) do adresu (jeżeli nie ma obsługi np cookies)
- za pomocą cookies
- można się ewentualnie pokusić o local storage (choć nie wiem czy ktoś tak aktualnie robi, są rozwiązania w JS wykorzystujące różne handlery w zależności od technologii którą klient wspiera) tyle że też nowoczesne przeglądarki ze wsparciem ogółu technologii zwanych HTML5 otwierają ogromne pole do popisu dla włamów
Po stronie klienta możemy trzymać albo sam SID, albo jakieś dodatkowe, tymczasowe dane ale nic ważnego (ciastko można skasować, można je zmienić, wirus może próbować je odczytać albo zmienić).

Oraz po stronie klienta za pomocą dowolnego mechanizmu przechowywania. Może to być:
- relacyjna baza danych
- nierelacyjna baza danych
- pliki tekstowe
przy czym rozwiązania te są zupełnie niezależne od naszej implementacji sesji a zależą od dostępności technologii i wymagań projektu. Jak ktoś wcześniej zauważył można nawet podmontować obszar pamięci jako katalog i obsługa operacji na danych jest zrzucona na system operacyjny (kernel, który we wszystkich rozwiązaniach i tak pośredniczy, to tak off-topicowo).
Tutaj, z racji tego że klient dostępu do tych danych nie ma, przechowujemy dane ważne. Tyle że rozwiązania te muszą być zabezpieczone przed typowymi próbami nieupoważnionego dostępu jak choćby SQL Injection czy inne wymienione w wątku.

W obu przypadkach od nas zależy co przechowujemy w tych implementacjach ponieważ każde z nich ma jakieś ograniczenia. Cookie do 4kB, relacyjne bazy danych mogą być wolne (ale nie przesadzajmy, przy ilości zapytań potrzebnych do obsługi całego sklepu to pryszcz dla silnika), trzymanie w pamięci może sprawić że dane stracimy.

Sam mechanizm sesji to całkowicie nasza inicjatywa bo akurat w tym przypadku można skorzystać z gotowych, dostępnych w PHP metod ale też napisać klasę która nic z SessionHandler czy interface nie implementuje. Chodzi tylko o to żeby powiązać SID klienta z SID serwera. Co więcej, można nawet napisać taki mechanizm, który dla danych mniej istotnych tworzy namespace pracujący w backendzie na noSQL a dla danych istotnych dla baz relacyjnych.