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)

[Niktoś]

Niktosiu, w takim razie w jaki sposób implementujesz autoryzację?

Nie implementuje, mam system otwarty.Wszyscy mogą kupować.
Nierelacyjna baza to to samo co sesje?No przestań żartować.Inny obszar składowania danych,do którego użytkownik nie ma bezpośredniego dostępu,a sama aplikacja łączy się z nierelacyjną bazą danych przez tzw. connection stringa.Te połączenie akurat w tej bazie mogę zaszyfrować przez ssl.Chyba by mi się musieli na komputer wbić i bezpośredni dane z pamięci pobrać ,żeby coś naskrobać.

[greycoffey]

Nie implementuje, mam system otwarty.Wszyscy mogą kupować.
Nierelacyjna baza to to samo co sesje?No przestań żartować.Inny obszar składowania danych,do którego użytkownik nie ma bezpośredniego dostępu,a sama aplikacja łączy się z nierelacyjną bazą danych przez tzw. connection stringa.Te połączenie akurat w tej bazie mogę zaszyfrować przez ssl.Chyba by mi się musieli na komputer wbić i bezpośredni dane z pamięci pobrać ,żeby coś naskrobać.

Prawde mówiąc: gówno wiesz na temat tych ataków które wymieniłeś. Wszystkie z nich mają związek z użytkownikiem oraz serwerem, nie między serwerem a miejscem przechowywania sesji. Oraz session posioning - tutaj wymagany jest programista idiota. W takim razie jak identyfikujesz użytkownika, że to właśnei on ma jakieś konkretne zasoby w twojej sesji, tfu, przepraszam, NIERELACYJNEJ BAZIE DANYCH. Czy użytkownik ma dostęp do miejsca, w którym przechowywane są domyślne sesje PHP? Nie. TO JEST TWOJA IMPLEMENTACJA SESJI! Zresztą, widziałeś te linki które przesłałem post przed twoim? Sesja to mechanizm, który przechowuje dane i przydziela je konkretnym użytkownikom na podstawie losowego klucza, najczęściej i najbezpieczniej przechowywanego w ciasteczku z flagą httpOnly. To czy ona jest zaimplementowana na twojej NIERELACYJNEJ BAZIE DANYCH, podkreślam, NIERELACYJNEJ, i musisz wymieniać jesj NIERELACYJNOŚĆ na każdym kroku, czy na relacyjnej bazie danych, w pliku, w pamięci (PHP ma już wbudowaną obsługę memcache oraz memecached, także sqlite) czy w zaszyfrowanej ciemnej dupie - to nie ma znaczenia.

Nazwij to jak chcesz, ale twoja NIERELACYJNA BAZA DANYCH to SESJA.

[Niktoś]

Prawde mówiąc: gówno wiesz na temat tych ataków które wymieniłeś. Wszystkie z nich mają związek z użytkownikiem oraz serwerem, nie między serwerem a miejscem przechowywania sesji.

No ale standardowo sesje przecież zapisują się w obszarze pamięci serwera użytkownik "bezpośrednio" z tego opszaru korzysta, zaś nierelacyjne bazy danych w cache komputera do którego serwer aplikacji "bezpośredniego" dostępu już nie ma i to jest różnica ,którą Ty najwidoczniej nie potrafisz zauważyć.

Ten post edytował Niktoś 6.05.2012, 11:50:56

[greycoffey]

No ale standardowo sesje przecież zapisują się w obszarze pamięci serwera użytkownik "bezpośrednio" z tego opszaru korzysta, zaś nierelacyjne bazy danych w cache komputera do którego serwer aplikacji "bezpośredniego" dostępu już nie ma i to jest różnica ,którą Ty najwidoczniej nie potrafisz zauważyć.

Śmiesznyś! Standardowo sesje zapisują się w /tmp (obszar pamięci serwera? dysk po prostu), ale to mozna zmienić - session.save_path. Powiedz mi w takim razie, co pośredniczy między serwerem aplikacji a twoją nierelacyjną bazą danych, jak to wpływa na bezpieczeństwo i czym się to różni od sesji oprócz miejsca przechowywania danych? Uzytkownik nie korzysta z tego obszaru, bo nie ma do niego dostępu. Na jakiej podstawie rozpoznajesz, że dany użytkownik posiada dany koszyk?
Nie zmienia to jednak faktu który od początku tego tematu wymieniam: To, że korzystasz ze swojej nierelacyjnej bazy danych zamiast z jakiegoś innego kontenera danych, nie zmienia faktu, że jest to sesja i nic więcej.

[tehaha]

nierelacyjne bazy danych w cache komputera do którego serwer aplikacji "bezpośredniego" dostępu już nie m

W jakim cache komputera? Mógłbyś to rozwinąć?

[wNogachSpisz]

Pytanie dobre, ale obawiam się że autor w zależności od odpowiedzi weźmie się za pisanie zupełnie różnego kodu. Bez sensu.
W CodeIgniterze jest to rozwiązane prawidłowo. Koszyk korzysta z sesji a sesja korzysta albo z cookie albo z bazy - do ustawienia w configu. Amen.

[greycoffey]

Generalnie najlepiej zaimplementować to w PHP 5.4 używając już istniejących klas i interfejsów, ale można też napisać własną nakładkę na sesję - klasa Factory tworząca odpowiednie obiekty interfejsu SessionHandlerInterface, obsługujące poszczególne bazy danych, pliki, pamięć czy wszystko co sobie wymyślisz.

[Niktoś]

W jakim cache komputera? Mógłbyś to rozwinąć?

Chodziło mi o to że działa w innym,odrębnym procesie systemowym niezależnym od serwera IIS, czy innym.

Standardowo sesje zapisują się w /tmp (obszar pamięci serwera? dysk po prostu), ale to mozna zmienić - session.save_path.

Widzisz ,a u mnie w nierelacyjnej bazie nie ma śladu na dysku ,ani żadnych folderów ,aplikacja korzysta z pamięci RAM, i jest niezależna od serwera.
Więcej info Tutaj

Powiedz mi w takim razie, co pośredniczy między serwerem aplikacji a twoją nierelacyjną bazą danych.

Klient(zbiór klas) tejże bazy, odpowiadających za nawiązanie połączenia z bazą i manipulowanie danymi.

Na jakiej podstawie rozpoznajesz, że dany użytkownik posiada dany koszyk?

Opisałem wcześniej, nie czytasz.

Nie zmienia to jednak faktu który od początku tego tematu wymieniam: To, że korzystasz ze swojej nierelacyjnej bazy danych zamiast z jakiegoś innego kontenera danych, nie zmienia faktu, że jest to sesja i nic więcej.

Tak,relacyjne(MySql, MSSQL ,inne) jak i nie relacyjne bazy danych, pliki tekstowe jak i xml pełniące funkcję kontenerów danych to wszystko to są sesje (IMG:style_emoticons/default/wink.gif)

Ten post edytował Niktoś 6.05.2012, 16:06:29

[tehaha]

Tak,relacyjne(MySql, MSSQL ,inne) jak i nie relacyjne bazy danych, pliki tekstowe jak i xml pełniące funkcję kontenerów danych to wszystko to są sesje

Nie to nie są sesje, sesja to mechanizm pozwalający na identyfikację użytkownika pomiędzy żądaniami http poprzez identyfikator w ciastku, a to czy sesja jest oparta o pliki czy bazę to już inna kwestia.

Chodziło mi o to że działa w innym,odrębnym procesie systemowym niezależnym od serwera IIS, czy innym.

Ogólnie to trochę kręcisz, bo wcześniej pisałeś, że trzymasz te dane tam gdzie serwer nie ma do nich dostępu, co ma zabezpieczać przed włamaniem, może najlepiej jakbyś pokazał kawałek kodu to wtedy skończymy te puste odbijanie piłeczki, bo wygląda na to, że używasz sesji opartej o bazę, ale wydaje Ci się, że to nie jest sesja bo nie jest oparta o domyślne pliki w tmp/.

aplikacja korzysta z pamięci RAM, i jest niezależna od serwera.

różnica między trzymaniem sesji na dysku a w pamięci RAM jest bardziej w wydajności niż bezpieczeństwie, poza tym RAM ma tą wadę, że te dane mogą zostać łatwo utracone i użytkownicy zostaną wylogowani lub utracą inne dane

@Niktoś nie traktuj tego personalnie bo chodzi głównie o to, że potem początkujący czytają takie tematy i głupio powtarzają "a ja czytałem, że sesje są niebezpieczne i nie można z nich korzystać" bo ostatnio co raz więcej takich ludzi na forum, trzeba być świadomym zagrożeń i zabezpieczać się poprzez odpowiednią logikę systemu i standardowe zabezpieczenie. Ponadto należy stosować rozwiązania zgodnie z ich przeznaczeniem bo nie ma nic gorszego niż fałszywe poczucie bezpieczeństwa

[Niktoś]

Nie to nie są sesje, sesja to mechanizm pozwalający na identyfikację użytkownika pomiędzy żądaniami http poprzez identyfikator w ciastku, a to czy sesja jest oparta o pliki czy bazę to już inna kwestia.

Ja to wiem, ale co niektórzy chyba myślą inaczej.

Ogólnie to trochę kręcisz, bo wcześniej pisałeś, że trzymasz te dane tam gdzie serwer nie ma do nich dostępu, co ma zabezpieczać przed włamaniem, może najlepiej jakbyś pokazał kawałek kodu to wtedy skończymy te puste odbijanie piłeczki, bo wygląda na to, że używasz sesji opartej o bazę, ale wydaje Ci się, że to nie jest sesja bo nie jest oparta o domyślne pliki w tmp/.

Używam sesji,a raczej jej SID tylko i wyłącznie do kojarzenia kosza z użytkownikiem, bo jest unikalna. Równie dobrze mógłbym w MSSQL ,czy w MYSQL utworzyć unikalny token i po nim identyfikować i sesji w ogóle nie używać, ale po co jak to się sprawdza. Absolutnie nie są używane sesje jako kontener danych, to robi nierelacyjna baza.Jeśli chodzi o kod ,to co mam pokazać jak nawiązuje połączenie z tą bazą danych? Dane pochodzą bezpośrednio z wysyłanych formularzy i zapisywane do nierelacyjnej bazy danych.Zobacz na ten link co podałem wyżej a będziesz wiedział, mniej więcej jak to działa. Fajna rzecz, naprawdę.

różnica między trzymaniem sesji na dysku a w pamięci RAM jest bardziej w wydajności niż bezpieczeństwie, poza tym RAM ma tą wadę, że te dane mogą zostać łatwo utracone i użytkownicy zostaną wylogowani lub utracą inne dane

Tu się z tobą zgodzę-chociaż nie za bardzo rozumie co miałeś na myśli ,przez "łatwo".Chodzi o ewentualny restart komputera,chwilowy zanik prądu itp.?Sesje też na to nie są odporne przynajmniej te in-proc,zapisywane w bazie danych czy na serwerze owszem są.

@Niktoś nie traktuj tego personalnie bo chodzi głównie o to, że potem początkujący czytają takie tematy i głupio powtarzają "a ja czytałem, że sesje są niebezpieczne i nie można z nich korzystać" bo ostatnio co raz więcej takich ludzi na forum, trzeba być świadomym zagrożeń i zabezpieczać się poprzez odpowiednią logikę systemu i standardowe zabezpieczenie. Ponadto należy stosować rozwiązania zgodnie z ich przeznaczeniem bo nie ma nic gorszego niż fałszywe poczucie bezpieczeństwa

Nie biorę tego personalnie, ale jak pisałem w jednym z pierwszych postów, dużo czytałem o bezpieczeństwie sesji i może udzieliła mi się paranoja-nie wiem. Ogólnie rzecz biorąc takie rozwiązanie jakie zastosowałem ,wydaje mi się dużo bezpieczniejsze.

Ten post edytował Niktoś 6.05.2012, 17:51:48

[r4xz]

Używam sesji,a raczej jej SID tylko i wyłącznie do kojarzenia kosza z użytkownikiem, bo jest unikalna

a więc jesteś narażony na wszystkie ataki (które wymieniłeś), co gorsza - korzystasz z ciasteczek, a więc ktoś może przechwycić twoje dane! tylko na co komu kolejne wydatki (pełen kosz) etc...? twoja obsesja na punkcie bezpieczeństwa kompletnie traci tutaj sens (IMG:style_emoticons/default/wink.gif)

prosta sesja i po sprawie, a bezpieczeństwo? owszem, ale nie trzymamy tutaj danych kodu genetycznego czy czegoś w tym stylu, tylko zwykł koszyk... w supermarkecie chyba też nie przykrywacie koszyka kocem żeby nikt nie ukradł co nie (trochę taki dziwny przykład, ale jest (IMG:style_emoticons/default/smile.gif) )?

[tehaha]

Równie dobrze mógłbym w MSSQL ,czy w MYSQL utworzyć unikalny token i po nim identyfikować i sesji w ogóle nie używać,

No właśnie nie mógłbyś byś. Bo jak wtedy zidentyfikujesz użytkownika bez sesji? Sesja oparta o MsSQL/MySQL to jest dalej sesja.

Sesje też na to nie są odporne przynajmniej te in-proc, zapisywane w bazie danych czy na serwerze owszem są.

in-process to chyba w asp.net a nie php

Ogólnie rzecz biorąc takie rozwiązanie jakie zastosowałem ,wydaje mi się dużo bezpieczniejsze.

No właśnie, wydaje Ci się... bo wydaje Ci się, że sesji nie używasz i przez to nie jesteś podatny na jej ataki, ale okazuje się, że jednak sesji używasz i to jest właśnie to fałszywe poczucie bezpieczeństwa.

[greycoffey]

w supermarkecie chyba też nie przykrywacie koszyka kocem żeby nikt nie ukradł co nie (trochę taki dziwny przykład, ale jest (IMG:style_emoticons/default/smile.gif) )?

Hahaha padłem ;D

Btw, PHP ma już wbudowany mechanizm sesji korzystający z memcache (IMG:style_emoticons/default/wink.gif) Ja sobie piszę coś na APC, bo z tego akceleratora korzystam.
Co do przechowywania na dysku a nie w ram, można zrobić tak:

Kod

mount -t tmpfs -size=128M,nr_inodes=1M tmpfs /tmp

I sesja jest już przechowywana w RAMie (IMG:style_emoticons/default/wink.gif)

Kolejny raz ewangelizuję: Sesja to mechanizm kojarzący konkretnego użytkownika z jego konkretnymi danymi przechowywanymi na serwerze.
Jako, że HTTP to protokół bezstanowy, najlepszym i najbezpieczniejszym rozwiązaniem jest kojarzenie na podstawie losowo utworzonego klucza przechowywanego w ciastku użytkownika z flagą httpOnly (i jeśli się da - SSL).

Ten post edytował greycoffey 6.05.2012, 18:45:23

[Niktoś]

No właśnie nie mógłbyś byś. Bo jak wtedy zidentyfikujesz użytkownika bez sesji?

No właśnie nie czytałeś, albo zbyt ogólnikowo to napisałem.Mógłbym dla każdego użytkownika utworzyć unikalny token i zapisać w MSSQL, czy MySQL i według tego identyfikować kosz dla użytkownika.Wcale bym nie musiał używać SID'a sesji,ale po co-to rozwiązanie jest łatwiejsze.Jak nie będzie spełniało moich wymogów bezpieczeństwa(będą częste manipulacje), to utworzę dodatkową kolumnę w bazie MSSQL z unikatowym tokenem.Na razie nie ma ani jednego odwołania do bazy danych MSSQL w moim systemie koszyka.Następuje dopiero przy realizacji zamówienia i o taki efekt mi chodziło.

a więc jesteś narażony na wszystkie ataki (które wymieniłeś), co gorsza - korzystasz z ciasteczek, a więc ktoś może przechwycić twoje dane!

I tutaj się bardzo mylisz, bo ja nie zapisuję danych do ciasteczek ,tylko SID ,żeby sesję podtrzymać jak ktoś zamknie browser i wróci ponownie, dane zaś siedzą sobie w nierelacyjne bazie danych,czyli w oddzielnej aplikacji.
Jak nawet ktoś zmanipuluje danymi czy to w cookies,czy w sesji to po prostu otrzyma inny (czyjś)koszyk,ale nie zmieni samych danych(kwot,nazw przedmiotów,adresu itp.),bo te dane siedzą w nierelacyjnej bazie danych,ewentualnie doda nowy produkt lub jakiś usunie i tyle uda mu się uzyskać nic poza tym.

W przypadku manipulacji koszyku opartym na sesji,przechwycenie ,czy wstrzyknięcie(poisoning) może mieć znacznie gorsze konsekwencje np. manipulacja danymi ,podmiana kwot ,podmiana nazw produktów itp., gdyż wszystkie dane są (zserializowane) i umieszczone w sesji.Nie wiem jak przebiega dokładnie ataki na sesje ,czy są trudne ,czy w ogóle praktycznie możliwe, ale możliwości ataków są i nie należy ich wykluczać.

I teraz takie praktyczne pytanie:Można przejrzeć liczne tematy, liczne fora i wszędzie programiści piszą :"nie przechowuje się haseł w sesjach !". Dlaczego tak piszą, jeżeli rzeczywiście sesje są tak bezpieczne jak co niektórzy piszą?
EDIT: @DOWN

Nie chodzi o to gdzie zapiszesz ten identyfikator tylko w jaki sposób użytkownik będzie Ci go przesyłał jeśli nie przez mechanizm sesji?

W końcu zajarzyłem-np.przez geta w urlu.

Na razie nie ma ani jednego odwołąnia do bazy danych w moim systemie koszyka

Te 2 chyba trochę sobie przeczą....

Chodziło mi o bazę danych MSSQL.Poprawiłem bo faktycznie namieszałem.

ale na pozostałe rodzaje ataków Twój sposób już jest narażony, bo przykładowo jak hacker ukradnie użytkownikowi sesje, żeby się za niego poszyć to nie ma w tym momencie znaczenia czy masz sesję opartą o bazę, pliki, czy ram.

Nie, globalnie mam flagę httpOnly na coocies,dodatkowo mogę wprowadzić flagę secure na sesje(wymaga ssl).

Nie chce nabijać postów więc odpowiadam tutaj.

Ten post edytował Niktoś 6.05.2012, 21:11:02

[tehaha]

Mógłbym dla każdego użytkownika utworzyć unikalny token i zapisać w MSSQL, czy MySQL i według tego identyfikować kosz dla użytkownika.Wcale bym nie musiał używać SID'a sesji

Nie chodzi o to gdzie zapiszesz ten identyfikator tylko w jaki sposób użytkownik będzie Ci go przesyłał jeśli nie przez mechanizm sesji?

Jak nawet ktoś zmanipuluje danymi czy to w cookies,czy w sesji to po prostu otrzyma inny (czyjś)koszyk,ale nie zmieni samych danych(kwot,nazw przedmiotów,adresu itp.)

Dokładnie i w tym momencie sam doszedłeś do wniosku, który próbowaliśmy Ci wytłumaczyć jak napisałeś:

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

Przy odpowiedniej logice systemu manipulacja danych w sesji nie jest w takim przypadku groźna, więc koszyk można spokojnie o to oprzeć. Ale podmiana danych to tylko jeden z możliwych ataków na sesje, ale na pozostałe rodzaje ataków Twój sposób już jest narażony, bo przykładowo jak hacker ukradnie użytkownikowi sesje, żeby się za niego poszyć to nie ma w tym momencie znaczenia czy masz sesję opartą o bazę, pliki, czy ram.

Na razie nie ma ani jednego odwołąnia do bazy danych w moim systemie koszyka

,bo te dane siedzą w relacyjnej bazie danych

Te 2 chyba trochę sobie przeczą....

I teraz takie praktyczne pytanie:Można przejrzeć liczne tematy, liczne fora i wszędzie programiści piszą :"nie przechowuje się haseł w sesjach !". Dlaczego tak piszą, jeżeli rzeczywiście sesje są tak bezpieczne jak co niektórzy piszą?

Amen, napisali i my też piszemy: "nie przechowuje się haseł w sesjach !", a nie: "nie używaj sesji", w bazie danych tak samo nie przechowuje się haseł, ani w plikach i ramie też nie.

Ogólnie z tematu zrobił się już trochę śmietnik, a chodzi o jedną prostą rzecz: napisałeś, że sesji nie używasz bo są niebezpieczne ale właśnie to co opisujesz to jest mechanizm sesji i go używasz, a jak używasz to go zabezpiecz. pozdro

[greycoffey]

No właśnie nie czytałeś, albo zbyt ogólnikowo to napisałem.Mógłbym dla każdego użytkownika utworzyć unikalny token i zapisać w MSSQL, czy MySQL i według tego identyfikować kosz dla użytkownika.Wcale bym nie musiał używać SID'a sesji,ale po co-to rozwiązanie jest łatwiejsze.Jak nie będzie spełniało moich wymogów bezpieczeństwa(będą częste manipulacje), to utworzę dodatkową kolumnę w bazie MSSQL z unikatowym tokenem.Na razie nie ma ani jednego odwołąnia do bazy danych w moim systemie koszyka.Następuje dopiero przy realizacji zamówienia i o taki efekt mi chodziło.

Czyli używasz SIDa - btw. SID to Session IDentity, czyli jakikolwiek identyfikator sesji.

I tutaj się bardzo mylisz, bo ja nie zapisuję danych do ciasteczek ,tylko SID ,żeby sesję podtrzymać jak ktoś zamknie browser i wróci ponownie, dane zaś siedzą sobie w nierelacyjne bazie danych,czyli w oddzielnej aplikacji.
Jak nawet ktoś zmanipuluje danymi czy to w cookies,czy w sesji to po prostu otrzyma inny (czyjś)koszyk,ale nie zmieni samych danych(kwot,nazw przedmiotów,adresu itp.),bo te dane siedzą w relacyjnej bazie danych,ewentualnie doda nowy produkt lub jakiś usunie i tyle uda mu się uzyskać nic poza tym.

Ech.. Sesja a ciastka łączą się tym, że ciastka zawierają bardzo czesto SID - a to jest dobrym rozwiązaniem. Jedynie idioci (z punktu bezpieczeństwa) zapisują dane przeznaczone dla sesji w ciasteczkach.
To twoje zachowanie cechuje się dla praktycznie każdej sesji, a możliwo·ść ataku Session Poisoning to wina programisty.

W przypadku manipulacji koszyku opartym na sesji,przechwycenie ,czy wstrzyknięcie(poisoning) może mieć znacznie gorsze konsekwencje np. manipulacja danymi ,podmiana kwot ,podmiana nazw produktów itp., gdyż wszystkie dane są (zserializowane) i umieszczone w sesji.Nie wiem jak przebiega dokładnie ataki na sesje ,czy są trudne ,czy w ogóle praktycznie możliwe, ale możliwości ataków są i nie należy ich wykluczać.

Ponownie: g**** wiesz. Jak już wyżej wspomniałem, Session Poisoning to wina daremnego programisty, który tworzy potworki typu:

[PHP] pobierz, plaintext 
$_SESSION[$_GET['name']] = $_GET['value'];
[PHP] pobierz, plaintext 

A przechwycenie sesji, jak wyżej wspomniałeś: zmanipuluje danymi czy to w cookies,czy w sesji to po prostu otrzyma inny (czyjś)koszyk,ale nie zmieni samych danych(kwot,nazw przedmiotów,adresu itp.),bo te dane siedzą w relacyjnej bazie danych,ewentualnie doda nowy produkt lub jakiś usunie i tyle uda mu się uzyskać nic poza tym.

I teraz takie praktyczne pytanie:Można przejrzeć liczne tematy, liczne fora i wszędzie programiści piszą :"nie przechowuje się haseł w sesjach !". Dlaczego tak piszą, jeżeli rzeczywiście sesje są tak bezpieczne jak co niektórzy piszą?

Nie przechowuje się haseł w sesjach. Nie przechowuje się cen produktów w sesjach. Nie przechowuje się nazw przedmiotów w sesjach.
Sesje poprawnie zaimplementowane są bezpieczne, jednak zgodnie z zasada przezorny zawsze ubezpieczony oraz atomowości danych, nie przechowuje się rzeczy stałych (nazwa produktu, cena) tylko identyfikator (wskaźnik) do nich. Sesje są ulotne, nie ma sensu klonować bytów. Czy w twojej implementacji sesji nei da się wstawić ceny do sesji? Jeśli tak, to gratuluje pomysłowo·ści oraz świetnej sztucznej inteligencji.

Nie wiem jak przebiega dokładnie ataki na sesje ,czy są trudne ,czy w ogóle praktycznie możliwe

I to podsumowywuje twój poziom wiedzy. Nie wiesz jak ich dokonać, nie wiesz jak się przed nimi bronić. Nie wiesz nawet, czy to, przed czym się "bronisz" jest możliwe. Praktykę i teorię trzeba łączyć. A tutaj widzę, że nawet teorii nie ma. Session Hijacking jest możliwe w praktycznie każdej implementacji sesji, kiedy połączenie nie jest szyfrowane w obrębie całego zasięgu ciastka z SIDem (chociaż wtedy można pewnie dokonać MITM). Session Fixation to właściwie brute-force na identyfikatorze sesji, tutaj siła zabezpieczenia jest równa ilości wszystkich możliwych identyfikatorów sesji. Sesion Poisoning to już wina programisty-idioty, jak już wcześniej wspomniałem.

Update do twojego update^^:

Nie, globalnie mam flagę httpOnly na coocies,dodatkowo mogę wprowadzić flagę secure na sesje(wymaga ssl).

To nei wyklucza ataku MITM, CSRF w celu uzyskania identyfikatora sesji. Dodatkowo, SID może być generowany po kolei przez włamywacza, w celu trafienia na jakiś - tutaj przydają się dodatkowe zabezpieczenia jak np. sprawdzanie czy w jednej sesji nie zmienił się USER_AGENT, akceptowane języki etc. - stałe ustawienia danej przeglądarki.


Ten post edytował greycoffey 6.05.2012, 21:15:43

[aachi]

Przepraszam, że się wtrącam w waszą dyskusję, ale kilka razy sam zbytnio się zagalopowałem na innych forach i byłem wdzięczny, gdy postronne osoby pomogły mi ochłonąć.

Więc Niktoś... Nie masz racji. Greycoffey ma - CAŁKOWITĄ. Przeczytaj uważnie co Ci napisał, wiele się nauczysz, bo on na prawdę gada z sensem.

Wydaje mi się Niktoś, że dla Ciebie pojęcie sesji oznacza tylko i wyłącznie session w PHP (czyli session_start(), tablica $_SESSION itd.). Jest to pojęcie błędne. Sesja, jak greycoffey i tehaha tłumaczył, to każdy mechanizm pozwalający w bezstanowym protokole jakim jest HTTP, zidentyfikować kolejne połączenia od tego samego użytkownika. I też się pod tym podpisuje, a kompletnie nie znam tych dwóch panów.

Rozumiem, że dane "co kto trzyma w koszyku" zapisujesz w bazie, a do identyfikacji użytkownika używasz wbudowanego mechanizmu sesji PHP. Z tego co mówisz nadal jednak wynika, że te dane w bazie to dane sesyjne (bez względu czy do ich przechowywania używasz mechanizmu wbudowanego w PHP, czy innego - w tym wypadku swojego własnego).

Więc jeszcze raz: Niktoś zagalopowałeś się i zaczynasz coraz bardziej bełkotać. I kolejna osoba stara się Ci to wytłumaczysz (JA). Tylko od Ciebie zależy, czy zignorujesz te wiele osób i będziesz dalej upierał się przy swoim odosobnionym zdaniu. W tym wątku to greycoffey ma rację.

Przepraszam, że się wtrąciłem.

[Niktoś]

A niech to odpalę troszeczkę kodu ,mam nadzieję ,że ktoś go zrozumie bo to c#.NET:
Nawiązuje połączenie z nierelacyjną bazą danych (klient-serwer),może być połączenie szyfrowane lub nie:

[CSHARP] pobierz, plaintext 
if (((Session["SSID_SESJI"] == null) || &&(!Page.IsPostBack))
        {
            Session["SSID_SESJI"] = HttpContext.Current.Session.SessionID;
            HttpCookie Cuzytk = new HttpCookie("UZ");
            Cuzytk.Expires.AddMinutes(20);
            Cuzytk.Secure = true;
            Cuzytk.HttpOnly = true;
            Cuzytk.Value = Session["SSID_SESJI"].ToString();
            Response.Cookies.Add(Cuzytk);
        }
        else {
            Session["SSID_SESJI"] = Request.Cookies["UZ"].Value;
 
        }
 
If(IsPostback){
TupleSpace ts = new TupleSpace("localhost", PORT, "INSTANCJA", "", new String[] { "NazwaPołączenia" });
 string Dane_Z_Inputa = Request["input1"];
string Dane_Z_Inputa1 = Request["input2"];
string Dane_Z_Inputa2 = Request["input3"];
string Dane_Z_Inputa3 = Request["input4"];
Field a = new Field(Dane_Z_Inputa );
Field b = new Field(Dane_Z_Inputa1);
Field c = new Field(Dane_Z_Inputa2);
 Field d = new Field(Dane_Z_Inputa3);
Field e= new Field(Session["SSID_SESJI"].ToString());
 Collide.SQLSpaces.Tuple tup = new Collide.SQLSpaces.Tuple(new Field[] { a, b, c, d,e});
TupleID id = ts.write(tup);
}
[CSHARP] pobierz, plaintext 

Wyszukiwanie w że tak powiem w "rekordach" bazy danych:

[CSHARP] pobierz, plaintext 
Collide.SQLSpaces.Tuple templates = new Collide.SQLSpaces.Tuple(new Field[] { new Field(typeof(string)), new Field(typeof(string)), new Field(typeof(string)), new Field(typeof(string)),HttpContext.Current.Session["SSID_SESJI].ToString())) }); //zapis ten odczytuje wszystkie rekordy,które zawierają Session["SSID_SESJI]-to jest właśnie powiązanie użytkownika z koszem
            Collide.SQLSpaces.Tuple[] tup2 = ts.readAll(templates);
[CSHARP] pobierz, plaintext 

Tup2 zawiera wszystkie rekordy użytkownika Session["SSID_SESJI]-Żadnych danych do sesji nie pchałem,oprócz jej SID.

Z tego co mówisz nadal jednak wynika, że te dane w bazie to dane sesyjne (bez względu czy do ich przechowywania używasz mechanizmu wbudowanego w PHP, czy innego - w tym wypadku swojego własnego).

Tak tylko i wyłącznie SID jak przykład wskazuje.
Zresztą ta implementacja bazy danych również jest dostępna dla języka PHP-link wyżej.

Ten post edytował Niktoś 6.05.2012, 22:26:36

[Fifi209]

Niktoś robisz straszny burdel w kodzie. Czemu dane z inputa nie są tablicą ? Tylko 1,2,34 ? Tak samo Field nie wiem czy wiesz ale możesz tworzyć tablice obiektów, listę danego typu etc.

Poziom kodu równie niski co dyskusji, którą śledzę cały czas.

Ten post edytował Fifi209 6.05.2012, 22:31:40

[tehaha]

To co pokazałeś to jest sesja oparta o bazę.

Tak tylko i wyłącznie SID

No i właśnie na tym SID opiera się sejsa i ono ma tutaj fundamentalne znaczenie...bo teoretycznie dalej przy pomocy xss czy też session sidejacking, można podszyć się pod użytkownika, więc wcale się przed tym nie zabezpieczyłeś tylko założyłeś, że jak zaimplementowałeś własny mechanizm sesji to wyeliminowałeś wszystkie możliwości ataku na sesje, co jest niestety błędnym założeniem. Tyle w temacie. Dziękuję dobranoc.

[mortus]

@Niktoś: SQLSpaces nie jest nierelacyjną bazą danych. SQLSpaces to implementacja tuple space bazująca na relacyjnych bazach danych, przy czym domyślnie korzysta z HSQL, a dodatkowo może korzystać z MySQL, czy PostgreSQL.
Tuple space natomiast to implementacja paradygmatu pamięci asocjacyjnej dla obliczeń równoległych/rozproszonych. Tuple space może być rozumiana jako rozproszona pamięć współdzielona.

Ogólnie rzecz biorąc, raczej średnio (żeby nie rzec, że w ogóle nie) nadaje się to do implementacji koszyka użytkownika.

Osobiście oparłbym implementację sklepowego koszyka o mechanizm sesji, a dodatkowo umożliwiłbym użytkownikowi podejmowanie decyzji, czy przechowywać te dane, czy też nie (a tu z pomocą przychodzą zarówno ciasteczka, jak i system baz danych, w zależności od tego, jaką decyzję podejmie użytkownik, przy czym poinformowałbym go również co się stanie, jeśli nie podejmie żadnej decyzji).

Ten post edytował mortus 6.05.2012, 23:37:33

[Niktoś]

Sidejacking is still a problem for many sites on the internet. The only way to protect yourself on every site you visit is to secure and encrypt your connection for all requests. SheepSafe from Nick Sieger is an easy to install solution for Mac that relies on an SSH tunnel and SOCKS proxy to encrypt every HTTP request you make, no matter what site you're on.

Ale żeś mi armatę wystawił, chyba najgorszy atak na sesję, przed którym trudno się uchronić.Nawet Facebook,google(widziałem na filmiku włam na poczte) sobie nie radzą ,a mają przecież ekspertów przy których ja się chowam.

Mam ,na to pomysł- oprócz SSL, zaimplementować dodatkowo (IPsec), może uchroni.

Ogólnie rzecz biorąc, raczej średnio (żeby nie rzec, że w ogóle nie) nadaje się to do implementacji koszyka użytkownika.

Można wiedzieć dlaczego tak sądzisz?
Nie wiem dlaczego wiki sklasyfikował Turple Space do grupy NoSQl-czyli tych nierelacyjnych,a w liście relacyjnych baz danych tej bazy nie ma,zaś samo HSQLDB jest?Nie wiem jakaś hybryda to.
http://en.wikipedia.org/wiki/NoSQL
Zobacz na listę poniżej.
Key-value cache in RAM

Tuple space
Velocity //Nowsza wersja AppFabric?Zarówno jedno i drugie to nakładki/narzędzia na bazy danych?

Sugerowałem się tą listą, ale doczytałem solidnie i faktycznie relacyjna, oparta na HSQLDB, która napisana jest w javie a dane przetrzymuje w pamięci RAM.Choć naprawdę nie dostrzegam tam klucza głównego i relacji między tabelami.

Ten post edytował Niktoś 7.05.2012, 01:21:15

[tehaha]

Ale żeś mi armatę wystawił, chyba najgorszy atak na sesję, przed którym trudno się uchronić.Nawet Facebook,google(widziałem na filmiku włam na poczte) sobie nie radzą ,a mają przecież ekspertów przy których ja się chowam.

Mam ,na to pomysł- oprócz SSL, zaimplementować dodatkowo (IPsec), może uchroni.

Szczerze mówiąc to nie rozumiem Twojej uwagi, jeżeli zagłębisz się odrobinę w tematykę zabezpieczenia sesji to odkryjesz, że oprócz tego ssl'a jest jeszcze kilka technik i praktyk, które częściowo zabezpieczają oraz redukują szkody powstałe w wyniku przechwycenia sesji. A skoro korzystasz z sesji to chyba warto się dowiedzieć jak ją zabezpieczyć.

[spokoloko123]

Zrobienie tego w sesji jest po prostu głupie. Nikt z takiego sklepu nie będzie chciał korzystać (firma, właściciel sklepu) ponieważ odbierasz w ten sposób możliwość analizy rynkowej, i nie masz wglądu jakie towary zostają porzucone, na jakim etapie. Bez takich danych nie przeprowadzisz żadnej analizy. Gdy budujemy na bazie danych to jeśli jest ona dobrze zrobiona to możemy nawet zebrać informacje o stronie. Na przykład gdy porzucenia koszyka kończą się na formularzu wysyłania to być może proces wysyłki jest opisany niezrozumiale, albo nie jest wygodny i to jest znak że trzeba coś zmienić. Tak już działa rynek.

Chcesz robić sesje? Twoja sprawa, ale nikt poważny się tym nie zainteresuje.

Pozdrawiam

Ten post edytował spokoloko123 7.05.2012, 06:07:17

[m44]

spokoloko123 w jaki sposób chcesz to zrobić, jeśli nie w oparciu o sesje?

Niektórzy dyskutanci słusznie od początku wątku zwracają uwagę na fakt, że HTTP jest protokołem bezstanowym.
W celu zachowania stanu jakichkolwiek danych między żądaniami musisz napisać własną implementację sesji.

[mortus]

Można wiedzieć dlaczego tak sądzisz?
Nie wiem dlaczego wiki sklasyfikował Turple Space do grupy NoSQl-czyli tych nierelacyjnych,a w liście relacyjnych baz danych tej bazy nie ma,zaś samo HSQLDB jest?Nie wiem jakaś hybryda to.
http://en.wikipedia.org/wiki/NoSQL
Zobacz na listę poniżej.
Key-value cache in RAM

Tuple space
Velocity //Nowsza wersja AppFabric?Zarówno jedno i drugie to nakładki/narzędzia na bazy danych?

Sugerowałem się tą listą, ale doczytałem solidnie i faktycznie relacyjna, oparta na HSQLDB, która napisana jest w javie a dane przetrzymuje w pamięci RAM.Choć naprawdę nie dostrzegam tam klucza głównego i relacji między tabelami.

SQLSpace to nie baza danych, a jedynie interfejs/łącznik pomiędzy przestrzenią tupletów (tak brzmiałoby chyba dosłowne tłumaczenie zwrotu tuple space), a systemem zarządzania relacyjną bazą danych. Domyślnie systemem tym jest HSQLDB, który przechowuje dane w pamięci operacyjnej. Można jednak skonfigurować HSQLDB tak, by przechowywał dane w pliku. Użytkownik korzystający z SQLSpace może w tej chwili wybrać, z którego RDBMS-a chce korzystać, przy czym dotychczas zaimplementowano wsparcie tylko dla HSQLDB, MySQL i PostgreSQL. Zauważ przy tym, że bazy danych MySQL i PostgreSQL mogą również rezydować tylko i wyłącznie w pamięci operacyjnej.
Same przestrzenie tupletów możemy zakwalifikować do noSQL-owych baz danych, gdyż umożliwiają one przechowywanie danych postaci klucz - wartość w pamięci operacyjnej i nie wymagają od nas definiowania jakichkolwiek relacji. Jednak SQLSpace to tylko i aż implementacja tuple space.

Być może pospieszyłem się z oceną przydatności SQLSpace do implementacji sklepowego koszyka, jednak uważam, że używanie tak potężnego "narzędzia" do realizacji tak "błahych" mechanizmów mija się z celem. Przede wszystkim należy pamiętać, że SQLSpace działają na zasadzie rozproszonej pamięci współdzielonej, z czego wynika fakt, że może być wykorzystywana jednocześnie przez setki różnych systemów, być zlokalizowana w wielu pamięciach operacyjnych na raz a jej celem jest zapewnienie ujednoliconego interfejsu wzajemnej wymiany danych pomiędzy wspomnianymi systemami. "Zaprzęganie" SQLSpace do realizacji koszyka na zakupy wydaję się być lekkim nadużyciem, tym bardziej, że możliwość przechowywania danych tylko w pamięci operacyjnej, zapewniają nam już same RDBMS-y.

@spokoloko123: A co ma koszyk wspólnego ze zbieraniem informacji na temat tego, na którym etapie użytkownik wycofał się z dokonania zakupów? Co najwyżej można ten koszyk wykorzystać, do analizowania informacji jakie produkty chciał użytkownik nabyć. Wątpię, aby sesje miały w tym przeszkadzać. Poza tym analizowanie takiej informacji bez wiedzy i zgody użytkownika stanowi poważne naruszenie praw konsumenta. No chyba, że będą to dane w 100% anonimowe, a użytkownik zostanie wcześniej poinformowany o tym, że jego zakupy będą "śledzone". W przeciwnym przypadku wymagałoby to wcześniejszej rejestracji użytkownika i zaakceptowania przez niego odpowiednio sformułowanego regulaminu.

Ten post edytował mortus 7.05.2012, 09:24:19

[spokoloko123]

spokoloko123 w jaki sposób chcesz to zrobić, jeśli nie w oparciu o sesje?

No chyba jasno się wyraziłem. Tworzysz sobie tablice, a użytkowników owszem rozpoznajesz po session_id, ale wszystko i tak pozostaje w bazie. Po tym jak porzuci koszyk to on dla użytkownika przestaje istnieć, ale ty wiesz, że masz to w bazie i poddajesz to analizie. A gdy kupuje faktycznie i dokonał wpłaty, czy ogólnie zamówienie zostało złożone to przenosisz z tej tabeli "koszyka" do tabeli realizacji zamówień.

A co ma koszyk wspólnego ze zbieraniem informacji na temat tego, na którym etapie użytkownik wycofał się z dokonania zakupów?

Nie przyszło ci do głowy, że w tabeli nazwijmy ją "koszyk" można stworzyć kolumnę, która zbiera informacje na jakim etapie się znajdujemy? Na etapie samego dodawania jest lvl 1 - załóżmy, a w kolejnych inkrementujemy tę wartość. Trochę wyobraźni (IMG:style_emoticons/default/wink.gif) . Żadne śledzenie tylko do numeru id sesji masz przypisane do jakiego etapu użytkownik doszedł. Żaden regulamin do tego potrzebny nie jest.

Ten post edytował spokoloko123 7.05.2012, 08:23:23

[mortus]

Nie przyszło ci do głowy, że w tabeli nazwijmy ją "koszyk" można stworzyć kolumnę, która zbiera informacje na jakim etapie się znajdujemy? Na etapie samego dodawania jest lvl 1 - załóżmy, a w kolejnych inkrementujemy tę wartość. Trochę wyobraźni (IMG:style_emoticons/default/wink.gif) . Żadne śledzenie tylko do numeru id sesji masz przypisane do jakiego etapu użytkownik doszedł. Żaden regulamin do tego potrzebny nie jest.

No i po co mi do tego baza danych? Przecież równie dobrze mogę sobie taką informacje zapisać w sesji. Piszesz, że chcesz identyfikować etap dokonywania zakupów, poprzez dodatkową kolumnę w tabeli koszyka, ale gdy użytkownik zdecyduje się na zakup i go dokona, albo przynajmniej złoży zamówienie, to czy konieczne jest dalsze przechowywanie informacji o zawartości koszyka w tabeli koszyk? Odpowiem - NIE. Tracisz zatem informację na temat tego, na jakim etapie użytkownik wycofał się z ewentualnego dokonania zakupu. Choć tak naprawdę odpowiedzialność za tę część analizy rynkowej (jak to ładnie nazwałeś) przejmuje moduł realizacji zamówień. Informacja o tym na jakim etapie użytkownik wycofał się z dokonywania zakupów nie ma nic wspólnego z zawartością koszyka, a jeśli ma podlegać analizie, to powinna być zapisywana w zupełnie odrębnej/ych tabeli/ach, która/e "gromadzi/ą" wszystkie dane podlegające takiej analizie.

PODSUMOWUJĄC:
- koszyk na zakupy powinien bazować na sesji,
- jeśli użytkownik musi odejść od komputera na czas dłuższy, aniżeli czas życia sesji, to powinien mieć możliwość zapisania zawartości koszyka do bazy danych lub w ciasteczku,
- jeśli użytkownik zdecyduje się zapisać zawartość koszyka w ciasteczku, to warto go poinformować, że gdy usunie ciasteczka, straci zawartość koszyka (ta opcja często jest pomijana, a domyślnie zawartość koszyka zapisywana jest w ciasteczku o długim czasie życia),
- zapisanie zawartości koszyka w bazie danych wiąże się z nadaniem odpowiedniego identyfikatora dla tego koszyka (może wymagać rejestracji użytkownika, ale nie musi, i nie może być identyfikowane przez id sesji, bo sesja w czasie nieobecności użytkownika może wygasnąć),
- do analizy rynkowej należy użyć odrębnego modułu wykorzystującego dane przechowywane w tabeli bazy danych, sesji lub innej pamięci, przy czym dane do tej analizy mogą być dostarczane przez aplikację (każdy moduł raportuje dane do analizy samodzielnie, korzystając jednak z tego samego/unikalnego identyfikatora, jakim może być id sesji), czy system baz danych (np. triggery, które automatycznie dokonują odpowiednich wpisów do bazy danych w zależności od tego, jaką akcję podejmie użytkownik - opuszczenie koszyka (równoważne de facto usunięciu odpowiedniej zawartości z sesji, bazy danych, czy innej pamięci), wycofanie zamówienia, brak wpłaty w określonym terminie, itp.).

Ten post edytował mortus 7.05.2012, 09:54:29

[Niktoś]

- zapisanie zawartości koszyka w bazie danych wiąże się z nadaniem odpowiedniego identyfikatora dla tego koszyka (może wymagać rejestracji użytkownika, ale nie musi, i nie może być identyfikowane przez id sesji, bo sesja w czasie nieobecności użytkownika może wygasnąć),

Może być identyfikowane przez id sesji używając przy tym cookies do podtrzymania sesji jak np.ja zrobiłem.

Czytałem o HSQLDB i jest kilkakrotnie szybsza niż PostreSQL-zostawię tą implementacje, gdyż sama waga tej bazy jest bardzo lekka(silnik 100kb) a dostęp do danych szybki.

Kurcze chciałem nierelacyjną ,a mam relacyjną bazę danych przez nieporozumienie z TupleSpace .Potrzebowałem narzędzia do przechowywania key value pairs.Początkowo zaimplementowałem Redisa ,ale na windowsie to jest na cygwinie i to zniechęciło mnie(cygwiny są mało stabilne,i kiepsko wyglądają).Dlatego wybór padł na SqlSpaces, który wydawał mi się dość podobny w sposobie działania i nieoparty na cygwinie.

Są lepsze narzędzie jak AppFabric, ale zaimplementować nie mogłem ze względu na OS. Mam nadzieje ,że wybór był dobry, ale to się okaże.

[mortus]

Może być identyfikowane przez id sesji używając przy tym cookies do podtrzymania sesji jak np.ja zrobiłem.

Pamiętaj tylko, że cookies można usunąć.

Czytałem o HSQLDB i jest kilkakrotnie szybsza niż PostreSQL-zostawię tą implementacje, gdyż sama waga tej bazy jest bardzo lekka(silnik 100kb) a dostęp do danych szybki.

Nie doczytałem o PostgreSQL, ale najszybciej SQLSpaces działa z MySQL, przynajmniej taką informację znalazłem na stronie projektu.

Kurcze chciałem nierelacyjną ,a mam relacyjną bazę danych przez nieporozumienie z TupleSpace.

Już sama nazwa, która zawiera w sobie akronim SQL sugeruje, że dotyczy "to" relacyjnych baz danych. Zresztą tutaj i tak lepszym rozwiązaniem będzie relacyjna baza danych, ponieważ pomiędzy produktami a zawartością koszyka, jakaś relacja jednak istnieje. Co więcej najlepiej/chyba najwydajniej by było zrealizować wszystko w jednym systemie baz danych.

Ten post edytował mortus 7.05.2012, 09:45:32

[spokoloko123]

@mortus
Nie rozumiesz zasad e-commerce. Nie będę tego tłumaczyć 2 raz. Analiza rynkowa nie jest dokonywana na podstawie tego co jest w koszyku tylko an tym co zostało kupione. Ehhh... A po tym gdzie proces zakupów został przerwany jest ważne z kilku powodów i możemy w ten sposób dowiedzieć się czy np warunki przesyłki mu nie odpowiadały, może nie wszystko jest napisane jasno i miał wątpliwości, może okres realizacji zamówienia był za długi itd. itp.

Ten post edytował spokoloko123 7.05.2012, 18:58:42

[mortus]

@mortus
Nie rozumiesz zasad e-commerce. Nie będę tego tłumaczyć 2 raz. Analiza rynkowa nie jest dokonywana na podstawie tego co jest w koszyku tylko an tym co zostało kupione. Ehhh... A po tym gdzie proces zakupów został przerwany jest ważne z kilku powodów i możemy w ten sposób dowiedzieć się czy np warunki przesyłki mu nie odpowiadały, może nie wszystko jest napisane jasno i miał wątpliwości, może okres realizacji zamówienia był za długi itd. itp.

To Ty kolego nie rozumiesz, że nijak się to ma do implementacji koszyka na zakupy. Informacja o tym, co zostało kupione powinna się znaleźć w tabeli zamówień zrealizowanych, a informację o tym, w którym "miejscu" użytkownik odstąpił od dokonania zakupu powinien przesyłać sam system, a nie konkretnie koszyk na zakupy. Zauważ, że jeśli użytkownik dokona zakupu, to przechodzi do modułu odpowiedzialnego za realizacje zamówień, jeśli wycofa się w tej chwili, to właśnie ten moduł powinien raportować, że użytkownik wycofał się z realizacji zamówienia. Tak na dobrą sprawę powodów, dla których użytkownik "napełnił" koszyk i zostawił może być mnóstwo i możemy tylko przypuszczać, dlaczego postąpił on tak, a nie inaczej. Wątpię aby te dane były przydatne z punktu widzenia Twojej analizy rynkowej. Inaczej ma się sprawa zamówień na produkty, które już są w koszyku (kolejny, że tak to nazwę, krok podczas zakupów). Tutaj wykorzystujemy implementację koszyka tylko do pobrania informacji o produktach, które użytkownik do koszyka "wrzucił" i tyle. Resztą zajmuje sie moduł obsługi zamówień. Zrozum wreszcie, że są to dwie różne "rzeczy".

Ten post edytował mortus 7.05.2012, 19:18:42

[tehaha]

@spokoloko123 pomysł bardzo fajny, ale i tak ten kosz warto zrobić na sesji, a w bazie rejestrować zmiany kosza. Chociaż realizując Twoją koncepcję warto by zrobić coś bardziej rozbudowanego, ponieważ samo zapisanie kosza to marne narzędzie analityczne. Co Ci daje informacja, że ktoś zrezygnował mając mp3player'a w koszyku? Jeżeli chcemy na poważnie analizować utraconych klientów to warto by rejestrować wszystkie kroki tego klienta na naszej stronie, czyli nie tylko co dodał, ale też co oglądał i całą drogę jaką dany klient przebył w serwie, skąd zaczął, a gdzie skończył. Wydaje mi się, że takie narzędzie do analizy to zupełnie odrębny i o wiele bardziej zaawansowany temat. Ponadto tego typu dane nabierają wartości raczej przy dużym ruchu na stronie, małej ilości danych nie da się poddać rzetelnej analizie.

[Niktoś]

Taka analiza ma tylko i wyłącznie sens w przypadku użytkowników, którzy dokonali wcześniej rejestracji.

[mortus]

Taka analiza ma tylko i wyłącznie sens w przypadku użytkowników, którzy dokonali wcześniej rejestracji.

To zależy, co chcemy analizować. Bo jeśli np. badamy, czy asortyment jest wystarczający (tzn. umożliwia zadowolenie większości potencjalnych klientów) to musimy rejestrować większość ruchów użytkownika, o czym pisał tehaha, np. to po jakich kategoriach się poruszał, jakie produkty dodawał do koszyka, czy z niego usuwał, czy w ogóle coś dodawał i usuwał. Tutaj nie ma potrzeby zakładania konta, czy rejestrowania się i użytkownik nie musi wiedzieć, że go "obserwujemy" dopóki jest on użytkownikiem anonimowym. Jeśli analizujemy "sprawność" systemu, to musimy zapisywać i analizować informacje, o jakich pisał spokoloko123, czyli to, czy użytkownik zrezygnował z zakupu, na jakim etapie wtedy był, czy może jednak zdecydował się dokonać zakupu, a może nie odpowiadał mu sposób dokonywania płatności, itd.. Im więcej danych zbierzemy, tym dokładniejsza i bardziej wiarygodna będzie analiza.

Ogólnie jest to tak szerokie zagadnienie, że można by książkę napisać, albo więcej książek. Jednak nadal przekonuję, że nijak ma się do sposobu implementacji sklepowego koszyka.

Edycja:
Poza tym to off-top.

Ten post edytował mortus 7.05.2012, 19:51:43

[Niktoś]

No ale jeśli użytkownik nie będzie zarejestrowany,to wobec czego będziecie go kojarzyć(jest anonimowy jak nazwa wskazuje),po Ip (jest zmienne),DNS(także zmienne),User Agent(może korzystać z różnych browserów)?Może dodać koszyk usunąć, zamknąć browser, otworzyć inny browser i dokonać zakupu tego samego przedmiotu, a ty dostaniesz dwie różne statystyki tego samego użytkownika w rezultacie czego statystyki będą odzwierciedlały fałszywy obraz.
Jedyne co mi na myśl przychodzi to budowanie statystyk dla anonimowego użytkownika na podstawie coocies, ale to chyba byłoby wariactwo.

Ten post edytował Niktoś 7.05.2012, 20:00:21

[mortus]

No ale jeśli użytkownik nie będzie zarejestrowany,to wobec czego będziecie go kojarzyć(jest anonimowy jak nazwa wskazuje),po Ip (jest zmienne),DNS(także zmienne),User Agent(może korzystać z różnych browserów)?Może dodać koszyk usunąć,zamknąć browser,otworzyć inny browser i dokonać zakupu tego samego przedmiotu, a ty dostaniesz dwie różne statystyki tego samego użytkownika.
Jedyne co mi na myśl przychodzi to budowanie statystyk dla anonimowego użytkownika na podstawie coocies, ale to chyba byłoby wariactwo.

Oczywiście jeśli użytkownik się zarejestruje, a co więcej poda swój wiek, to przyczyni się do tego, że analiza będzie bardziej szczegółowa. Będzie można np. określić grupę docelową dla produktów z danej kategorii.
Natomiast każdy ruch użytkownika, czy to dodanie przedmiotu do koszyka, czy przejście do kategorii to nic innego jak wywołanie żądania obsługiwanego przez określony moduł systemu i każdy taki moduł "zobowiązany jest do raportowania swojego stanu". Te informacje zapisujemy w bazie danych i poddajemy analizie.

Ten post edytował mortus 7.05.2012, 20:06:46

[tehaha]

@Niktoś identyfikacji użytkownika pomiędzy żądaniami dokonujesz na podstawie ID sesji

Może dodać koszyk usunąć, zamknąć browser, otworzyć inny browser i dokonać zakupu tego samego przedmiotu, a ty dostaniesz dwie różne statystyki tego samego użytkownika w rezultacie czego statystyki będą odzwierciedlały fałszywy obraz.

Oczywiście, że tak może być, każde badanie statystyczne jest obciążone błędem pomiaru i zawiera "obserwacje odstające", nie istnieje idealne badanie, które przedstawi 100% rzeczywisty obraz sytuacji. Aczkolwiek tego typu badanie i tak będzie wartościowe, ponieważ po pierwsze niewiele kosztuje w porównaniu do innych metod badawczych bo drugie statystyki są gromadzone w sposób ciągły i przy dużych ruchu można wyciągnąć bardzo wiele wniosków i obserwować zmiany po ulepszeniach i zmianach w serwisie.

[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.

[uupah5]

No ale jeśli użytkownik nie będzie zarejestrowany,to wobec czego będziecie go kojarzyć(...)

dla jednego browsera: permanent cookie, panopticlick
sytuacja "zamknąć browser, otworzyć inny browser i dokonać zakupu tego samego przedmiotu" jest możliwa ale marginalna (ZU trzyma się jednej przeglądarki)