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

[patrysiek2]

Według mnie lepiej w sesji.

[marcio]

Według mnie lepiej w sesji.

Nie ma to jak uargumentowana odpowiedz.

Ogolnie jak dla mnie lepsze sesje mniej obciazaja "system" i mysle ze nawet latwiej jest na nich ow koszyk zbydowac

[greycoffey]

To jest dana, które pasuje TYLKO do sesji - a czy sesje będą zaimplementowane na plikach, bazie danych czy pamięci, to twoja sprawa.

[r4xz]

To jest dana, które pasuje TYLKO do sesji - a czy sesje będą zaimplementowane na plikach, bazie danych czy pamięci, to twoja sprawa.

kiedyś spotkałem się z koszykiem opartym o ciasteczka - chyba chwyt marketingowy (?). klient dodaje coś do koszyka, potem się rozmyśla i wyłącza przeglądarkę. wchodzi za jakiś czas i widzi pełen koszyk, i myśl "a może jednak to kupię?"

--edit--
osobiście popieram sesje - łatwość/wygoda manipulacji danymi oraz brak problemów z ich walidacją

Ten post edytował r4xz 5.05.2012, 21:19:43

[Niktoś]

Ja zrobiłem koszyk oparty o nierelacyjną bazę danych .Identyfikacja koszyka dla użytkownika w tej bazie po id sesji(unikalna dla każdego użytkownika), również użyłem cookies do którego zapisuje id.Jeśli sesja się kończy lub użytkownik wyłączy i włączy przeglądarkę, id sesji pobierane jest z ciasteczka . Trochę bezpieczniejsze niż sesje i bardziej wydajne niż opierając się o relacyjną bazę danych.Może się to sprawdzi:)

Ten post edytował Niktoś 5.05.2012, 21:36:09

[Fifi209]

Jak najbardziej coś w stylu pomysłu Niktosia. Dlaczego? Sesja trwa powiedzmy 15-20 minut, wystarczy że klient odejdzie na kawę, która przedłuży się o ciasteczko z koleżanką i miłą pogaduchę, wejdzie znów a tutaj pustka w koszyku a przecież miał tyle artykułów...

[usb2.0]

nie wiem czy się zbijasz @up czy mówisz poważnie ale ok
no a teraz jeśli w bazie to okej, rozumiem ze tabela z:
id ofc
fk do usera ktory zamawial
fk do sluga/id produktu
?
coś wiecej sie nada?

no i przykładowo przy wylogowaniu sie usera powinenem usuwać wszystko co miał w koszyku? koszyk to nie przechowalnia przeciez


Ten post edytował usb2.0 5.05.2012, 23:07:47

[Fifi209]

nie wiem czy się zbijasz @up czy mówisz poważnie ale ok

Całkiem poważnie.

no a teraz jeśli w bazie to okej, rozumiem ze tabela z:
id ofc
fk do usera ktory zamawial
fk do sluga produktu
?
coś wiecej sie nada?

Po co Ci np. id?

Dajesz fk do user'a + pole tekstowe w której trzymasz zserializowaną tablicę z id produktów i ilości.

[bastard13]

Zależy, czy po wyłączeniu przeglądarki i uruchomieniu jej jeszcze raz ma mieć wybrane te same produkty. Jest logowanie? W takim wypadku, czy po zalogowaniu w domu i w kafejce mam mieć w koszyku to samo?
Jeżeli logujesz użytkowników i zapamiętujesz zawartość koszyka -> baza.
Jeżeli użytkownik (w tym momencie nie istotna jest autoryzacja) widzi swój koszyk tylko na tej samej maszynie i z użyciem tej samej przeglądarki -> ciasteczka.
W innym wypadku -> sesja. Użytkownik kończy przeglądanie strony -> kończy się sesja -> koszyk przestaje istnieć(IMG:style_emoticons/default/smile.gif)

[usb2.0]

no brzmi całkiem sensownie sory ze zwiątpiłem
no po co id, hmmm coś w tym jest chyba po prostu przyzwyczajenie że w tabeli jest id i tyle (IMG:style_emoticons/default/tongue.gif)

[Niktoś]

Może generalizuje ,ale:
sesja= session hijacking, session fixation, session Poisoning-dużo możliwości manualowania danymi.To samo tyczy się coockies ,a może są jeszcze bardziej niebezpieczne.

Załóżmy klient kupuje artykułów na 20tys, głupio by było jakby tobie zamówienie wysłał na 2zł bo dobry hacker z niego i podmienił tobie dane sesji.Nie mówię już o wykradaniu adresów i e-maili.Chyba,że w sesji będziesz przechowywał klucze główne(id) do poszczególnych kolumn i wiązał je z bazą danych, wtedy to będzie w miarę bezpieczne.

Może to paranoja, ale dużo się naczytałem, że kluczowych danych w sesji czy cookie nie przechowuje się.

Ten post edytował Niktoś 6.05.2012, 00:09:59

[Fifi209]

no po co id, hmmm coś w tym jest chyba po prostu przyzwyczajenie że w tabeli jest id i tyle (IMG:style_emoticons/default/tongue.gif)

Tak ale tutaj jest zbędne.


@Niktoś
Kto normalny przechowuje np. ceny czy wartość zamówienia w sesji/cookies?

[spokoloko123]

Bardzo wygodnie wszystko jest rozwiązane na helion.pl. Trzymają w bazie - to pewne, ale na jakiej podstawie identyfikują wpisy z danym użytkownikiem to nie jestem pewien, ale session_id odpada bo koszyk się nie usuwa. A sesje to raczej standard i to mało ciekawy, oraz beznadziejny jeśli chodzi o analizę. Lepiej stworzyć bazę danych.

[Niktoś]

Dane koszyka to raczej dane temporalne-użytkownik może zamówić, ale nie musi zrealizować zamówienia. Dlatego ta część aplikacji może stanowić problem. Używając bazy danych, w pewnym momencie może okazać się ,że jest to niewydajne.Są wszakże tabele temporalne(do czasu trwania sesji lub aplikacji) ,ale to także generuje masę zapytań do bazy danych ,a przy złożeniu zamówienia przez użytkownika trzeba by było zrobić zrzut zamówionych towarów z tabeli temporalnej do tabeli właściwej,aby zachować te dane.

Używanie samych sesji czy cookies do tego typu rzeczy do najbezpieczniejszych sposobów nie należy.

Ja użyłem nierelacyjną bazę danych -gdzie tak jak w cookies czy w sesji jest expiration time(można ustawić czas życia koszyka, co dla danych tymczasowych jest idealnym rozwiązaniem. Same dane zapisują się w pamięci-więc dostęp do nich jest znacznie szybszy.Cookies i Sesje identyfikują użytkownika po (SID) i po nich następuję pobranie odpowiednich danych z nierelacyjnej bazy danych.W sesji czy cookies nie ma żadnych dodatkowych danych tylko SID.Nawet jak ktoś mi zmanipuluje tymi danymi to co najwyżej dostanie inny koszyk, lecz nie zmanipuluje danymi w nich.

Ten post edytował Niktoś 6.05.2012, 09:20:14

[usb2.0]

skorzystałem z rady @Fifi209 i oparłem to na serializowanych tablicach i pomiająć jakieś tam szczegóły jest to całkiem przyjemne wyjście.
A to co wyżej napisaleś to nie dla mnie takie cuda:P

[Niktoś]

Nom w darmowym ,czy nawet płatnym hostingu tego nie zrobisz, musiałbyś co najmniej dedyka sobie sprawić.

[greycoffey]

Może generalizuje ,ale:
sesja= session hijacking, session fixation, session Poisoning-dużo możliwości manualowania danymi.To samo tyczy się coockies ,a może są jeszcze bardziej niebezpieczne.

Załóżmy klient kupuje artykułów na 20tys, głupio by było jakby tobie zamówienie wysłał na 2zł bo dobry hacker z niego i podmienił tobie dane sesji.Nie mówię już o wykradaniu adresów i e-maili.Chyba,że w sesji będziesz przechowywał klucze główne(id) do poszczególnych kolumn i wiązał je z bazą danych, wtedy to będzie w miarę bezpieczne.

Może to paranoja, ale dużo się naczytałem, że kluczowych danych w sesji czy cookie nie przechowuje się.

Niktosiu, w takim razie w jaki sposób implementujesz autoryzację? Czy wy nie rozumiecie, że sesje mogą być różnie zaimplementowane?
Session hijacking - obrona przed CSRF - tokeny oraz ciasteczko z SID httpOnly, w przypadku ataku man-in-the-middle pomoże wam tylko SSL, w innym wypadku ktoś i tak może się podszyć pod daną osobę, nei tylko przez ciastko z SID, ale także podsłuchując dane logowania, adresy etc.
Session fixation - wybacz, ale to zagrożenia związanee nie z samymi sesjami, potrzebna jest tu inna luka, przeważnie XSS.
Session poisoning - jak kotś ustawia dane sesyjne, na podstawie klucz generowanego przez podaną przez użytkownika daną, to jest głupi i zamiast programowaniem, powinien się zająć czymś innym.
Hahaha, w takim razie jak powiążesz kluczowe dane z niezalogowanym użytkownikiem, jak nie losowym kluczem przechowywanym w $_COOKIE?

@Niktoś
Kto normalny przechowuje np. ceny czy wartość zamówienia w sesji/cookies?

True^^.

Dane koszyka to raczej dane temporalne-użytkownik może zamówić, ale nie musi zrealizować zamówienia. Dlatego ta część aplikacji może stanowić problem. Używając bazy danych, w pewnym momencie może okazać się ,że jest to niewydajne.Są wszakże tabele temporalne(do czasu trwania sesji lub aplikacji) ,ale to także generuje masę zapytań do bazy danych ,a przy złożeniu zamówienia przez użytkownika trzeba by było zrobić zrzut zamówionych towarów z tabeli temporalnej do tabeli właściwej,aby zachować te dane.

Używanie samych sesji czy cookies do tego typu rzeczy do najbezpieczniejszych sposobów nie należy.

Ja użyłem nierelacyjną bazę danych -gdzie tak jak w cookies czy w sesji jest expiration time(można ustawić czas życia koszyka, co dla danych tymczasowych jest idealnym rozwiązaniem. Same dane zapisują się w pamięci-więc dostęp do nich jest znacznie szybszy.Cookies i Sesje identyfikują użytkownika po (SID) i po nich następuję pobranie odpowiednich danych z nierelacyjnej bazy danych.W sesji czy cookies nie ma żadnych dodatkowych danych tylko SID.Nawet jak ktoś mi zmanipuluje tymi danymi to co najwyżej dostanie inny koszyk, lecz nie zmanipuluje danymi w nich.

Ta twoja nierelacyjna baza danych to właśnie WŁASNA IMPLEMENTACJA SESJI, dlatego twoja implemntacja, tak samo jak podstawowa i wszystkie inne, może być podatna na wyżej wymienione przez ciebie ataki.
Mechanizm jest taki sam. Identyfikacja użytkownika po losowym kluczu, tylko zamiast z pliku korzystasz z bazy danych.
Twoja nierelacyjna baza danych to SESJA, przed którą tak bardzo przestrzegasz.

Nom w darmowym ,czy nawet płatnym hostingu tego nie zrobisz, musiałbyś co najmniej dedyka sobie sprawić.

Wystarczy VPS.

Śmieszy mnie niektórych niechęć wobec sesji, a zwłaszcza kiedy mówicie, że są złe, a sami używacie ich alternatywnej wersji "bazy danych". Wasz mechanizm różni się tylko tym, że dane są przechowywane w innym miejscu. A jakie tutaj zagrożenia? I do twojej bazy danych, i do tamtego pliku również można się w jakiś sposób dostać, czy bezpieczeństwo jest większe?

[usb2.0]

brzmi sensownie (IMG:style_emoticons/default/tongue.gif)

[greycoffey]

Btw. PHP oferuje nawet podstawowe API do tworzenia własnych implementacji sesji:
session_set_save_handler();
Oraz od PHP5.4: SessionHandlerInterface i jego defaultowa implementacja SessionHandler.

Przeglądania manuala z nudów naprawde wnosi bardzo wiele w wiedze programistyczną. (IMG:style_emoticons/default/wink.gif)