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

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

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ą

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:)

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

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

Całkiem poważnie.


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.

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ć

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

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

Tak ale tutaj jest zbędne.


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

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.

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.

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

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

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?


True^^.


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.


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?

brzmi sensownie

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

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.

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.

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

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.

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.

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

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

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

Opisałem wcześniej, nie czytasz.

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

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

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

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



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.

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

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 )?

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.

in-process to chyba w asp.net a nie php
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.

Hahaha padłem ;D

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

I sesja jest już przechowywana w RAMie

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

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.


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

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


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

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.

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?

Dokładnie i w tym momencie sam doszedłeś do wniosku, który próbowaliśmy Ci wytłumaczyć jak napisałeś:
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.


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

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

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


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.


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.


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.


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^^:
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.

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.

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.

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.

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.

To co pokazałeś to jest sesja oparta o bazę.
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.

@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).

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.


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.

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

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

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.

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.

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



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 . Ż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.).

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.

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

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

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.