Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Michał Łaszczewski:

Dariusz Półtorak:
Także mechanizm jakoś się broni. Reszta strony - to już zmartwienie programisty. Czy teraz wytłumaczyłem to na tyle prosto byś był to w stanie zrozumieć ? System nie ma chronić przed XSS. Ma bronić przed XSS wymierzonym bezpośrednio w sesje i to robi na kilka sposobów. Pierwszym to ciastka httpOnly niewidoczne przez JS. Druga metoda to porównanie IP i user-agenta (opcjonalnie). Trzecia metoda to hash który ubije sesje w momencie jak więcej jak 1 osoba będzie korzystać z danej sesji.
Mechanizm działa i jest przeźroczysty.

No ok, ale w przypadku konkretnego ataku XSS Twój mechanizm niewiele zmienia, bo jak mam dostęp do javascriptu to mogę sobie robić prawie dowolne zapytania http do serwera które dalej będą wewnątrz Twojej zabezpieczonej sesji. Nie potrzebuje Twoich ciasteczek żeby przejąć sesje i atakować z innego IP jeśli mogę wykonywać zapytania które będą miały i tak zaufany sessionID i hash i adres IP ofiary. Nie wiem dlaczego tak bardzo starasz się nie dostrzegać tego problemu.
Pisałem że znam PHP(starsze wersje)

Dodane:
Są gotowe backdoory napisane w JS do zrobienia tego co opisałem. Chyba nigdy nie robiłeś ataków XSS, inaczej byś o tym wiedział.

Czy Ty masz 5 lat że Ci wszystko trzeba tłumaczyć ? Może za którymś razem zrozumiesz. Mechanizm sesji to mechanizm sesji. W wypadku powodzenia w ataku XSS moim zmartwieniem jest to by nie był on skuteczny w wypadku session hijacking. Co innego zrobi atakujący mało mnie obchodzi. To już zależy od twórcy witryny. Może się bawić w setki rzeczy począwszy od wymogu podania hasła przy wrażliwych opcjach.

Mówię, znajdź sobie inną dyskusję, załóż nowy temat ze swoimi żalami i przemyśleniami bo jak na razie Twój wkład w tą jest zerowy. Idź na dwór, znajdź programistę i poproś żeby Ci wytłumaczył co Ci już drugi raz napisałem (w sumie to samo co przedtem tylko innymi słowami) bo trzeci raz tłumaczył nie będę. Podejście "niech to będzie słabe i dziurawe bo ktoś i tak może zrobić coś innego" wciskaj swoim klientom (świeć panie nad ich serwisami) nie nam.

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Dariusz Półtorak:
Czy Ty masz 5 lat że Ci wszystko trzeba tłumaczyć ? Może za którymś razem zrozumiesz. Mechanizm sesji to mechanizm sesji. W wypadku powodzenia w ataku XSS moim zmartwieniem jest to by nie był on skuteczny w wypadku session hijacking. Co innego zrobi atakujący mało mnie obchodzi. To już zależy od twórcy witryny. Może się bawić w setki rzeczy począwszy od wymogu podania hasła przy wrażliwych opcjach.

Może zacznij pić melisę bo myślenie to Ci nie wychodzi. Udowodniłem że Twój mechanizm nic nie daje, nie daje żadnego dodatkowego zabezpieczenia, a tylko niepotrzebnie komplikuje życie, ale Ty piszesz mi trzeci raz to samo. Weź ogarnij swoje ego bo nic nie wnosisz do dyskusji poza wjazdami ad persona.

Mówię, znajdź sobie inną dyskusję, załóż nowy temat ze swoimi żalami i przemyśleniami bo jak na razie Twój wkład w tą jest zerowy.

Twój wkład jest zerowy, wymyślasz koło od nowa dodatkowo wszystko komplikując. Pokazuje Ci że to bez sensu, ale Ty wolisz żyć z swoimi złudzeniami.

Podejście "niech to będzie słabe i dziurawe bo ktoś i tak może zrobić coś innego" wciskaj swoim klientom (świeć panie nad ich serwisami) nie nam.

Twoje podejście nie jest wcale silniejsze niż zwykłe proste sessionId, do tej pory nie napisałeś jaką ma nad nim przewagę w przypadku rzeczywistego ataku. Ja dobrze wiem że nie ma żadnej, a Ty jeszcze musisz się wiele nauczyć o bezpieczeństwie.

Zarówno w przypadku XSS, jak i MITM, jak i backdoora Twoje rozwiązanie zupełnie nic nie zmienia. Nie wiem w czym to ma pomagać, chyba tylko w obciążaniu serwera.

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Czyli masz 5 lat. Rozpisz sobie działanie tego co opisałem a później typowego mechanizmu to zobaczysz różnicę. Pomijam że tutaj głównym celem był wspólny mechanizm dla noda i php.

Tutaj masz lektury zanim zaczniesz myśleć nad tym jak działa to co opisałem z uwagi na to że wcześniej miałeś wątpliwości czy ciasteczko będzie to samo w różnych zakładkach (dziwne jak na "programistę javascript"):
http://www.nczonline.net/blog/2009/05/05/http-cookies-...
http://www.nczonline.net/blog/2009/05/12/cookies-and-s...
i najważniejsze: http://tools.ietf.org/html/rfc6265

Jak napisałem, trzeci raz tłumaczył nie będę.Dariusz Półtorak edytował(a) ten post dnia 04.11.12 o godzinie 16:40

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Zachowujesz się jak dzieciak zapatrzony w siebie, ani razu nie prosiłem Cie o tłumaczenie jak to działa, bo doskonale rozumiem. Napisałem żebyś pokazał jaką to ma przewagę nad zwykłym sessionID(który też działa na ciasteczkach) w przypadku realnych ataków, bo tak jak mówię NIE MA ŻADNEJ. Ale jako że mogę się mylić to oświeć mnie wielki mistrzu PHPa.

OGARNIJ SIĘ

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Jest to napisane w jednym z tematów wyżej. Zrozumiał byś gdybyś wiedział jak działa typowy mechanizm tego typu. A teraz proszę jak autor tematu. Przestań tu pisać, jak masz jakieś zmartwienia życiowe to załóż sobie nowy temat.

Tu chciałem porozmawiać z poważnymi ludźmi na temat który widnieje na górze strony. Tłumaczył już więcej nie mam zamiaru bo i tak nie dotrze. Skończysz szkołę i popracujesz przy poważnym projekcie z innymi ludźmi to może Ci przejdzie. Na razie rozmowa z Tobą to strata czasu.

Pozdrawiam

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Darku, nie szkoda Ci czasu na rozmowę z tym "programistą"?

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Dariusz Półtorak:
Jest to napisane w jednym z tematów wyżej. Zrozumiał byś gdybyś wiedział jak działa typowy mechanizm tego typu.

Było napisane też kilka postów wyżej dlaczego takie coś w przypadku prawdziwego ataku XSS, MITM czy backdoora, nie jest żadną przeszkodą = nie ma sensu. Naucz się czytać ze zrozumieniem.

A teraz proszę jak autor tematu. Przestań tu pisać, jak masz jakieś zmartwienia życiowe to załóż sobie nowy temat.

Przestań pisać w ogóle zanim zmądrzejesz.

Skończysz szkołę i popracujesz przy poważnym projekcie z innymi ludźmi to może Ci przejdzie.

Jak już tak bardzo chcesz ad persona to skończyłem szkołę i kilka poważnych projektów. Jak chcesz się licytować to możemy zacząć, na swoim koncie mam między innymi aplikacje wymiany plików P2P, własny system VOIP P2P, system e-commerce, każdy z nich w innym języku programowania, ty jak na razie tylko w PHP siedziałeś, świata programistów nie widziałeś więc nie pieprz głupot o doświadczeniu :)

Na razie rozmowa z Tobą to strata czasu.

Pisanie na forum o od dawna rozwiązanych problemach z człowiekiem który próbuje wynajdować koło od nowa to również strata czasu, ale ja się dobrze bawię :)

No i po raz kolejny utwierdzam się w przekonaniu że ludzie od PHPa to nie są programiści :)Michał Łaszczewski edytował(a) ten post dnia 04.11.12 o godzinie 17:13

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Sebastian Poddubiuk:
Darku, nie szkoda Ci czasu na rozmowę z tym "programistą"?

Zapomniałem o przycisku "Ignoruj autora". Można było to skończyć szybciej. Nic, wszelkie sugestie i propozycje dalej mile widziane.

Ale dzięki niemu dowiedzieliśmy się że:
~ ciasteczka nie działają w zakładkach (faktycznie o to pytał - programista JavaScript)
~ programiści Javy (nie wiem co mieli do tego) napisali mechanizm sesji działający z PHP i Node.js już wiele lat temu (o dziwo przed powstaniem Node.js)
~ nie należy zabezpieczać sesji przed session hijacking za pomocą XSS bo scriptkid zawsze może zrobić coś innego - więc najlepiej pozwolić mu na wszystko.
~ nie ma różnicy między mechanizmem który pozwoli przechwycić sesję unieważniając ją dla jednego z klientów a takim który takie zdarzenie jest w stanie wykryć i całą sesję ubić
~ Języki dynamicznie typowane są dla amatorów poza JavaScript w którym on pisze
~ Tylko gimnazjaliści piszą w PHP
~ Można mówić o PHP nawet nie wiedząc nic o nim (zaczynając od domknięć którymi się podniecał a które PHP ma)
~ Najwyraźniej ktoś już napisał mechanizm sesji wspólny dla PHP i Node.js i stał się on powszechnym standardem a ja tutaj wynajduję koło od nowa.
~ Można się wypowiadać w temacie na forum nie na temat.
~ Zamiast w parę godzin dorobić czat + aktualizacje w czasie rzeczywistym lepszym i bardziej opłacalnym rozwiązaniem jest przepisanie całego intranetu firmowego zrobionego w PHP na noda poświęcając na to miesiące.
~ Nie wiadomo czego ludzie piszą w PHP (ślij petycję do Facebooka, NK, Allegro i innych amatorów)

Aż się strach odezwać. Pewnie dlatego ktoś z tej dyskusji już prowadzi ją ze mną dalej przez prywatne wiadomości żeby nie prowokować krzykacza.Dariusz Półtorak edytował(a) ten post dnia 04.11.12 o godzinie 17:42

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Dariusz Półtorak:

Sebastian Poddubiuk:
Darku, nie szkoda Ci czasu na rozmowę z tym "programistą"?

Zapomniałem o przycisku "Ignoruj autora". Można było to skończyć szybciej. Nic, wszelkie sugestie i propozycje dalej mile widziane.

Ale dzięki niemu dowiedzieliśmy się że:
~ ciasteczka nie działają w zakładkach (faktycznie o to pytał - programista JavaScript)
~ programiści Javy (nie wiem co mieli do tego) napisali mechanizm sesji działający z PHP i Node.js już wiele lat temu (o dziwo przed powstaniem Node.js)
~ nie należy zabezpieczać sesji przed session hijacking za pomocą XSS bo scriptkid zawsze może zrobić coś innego - więc najlepiej pozwolić mu na wszystko.
~ nie ma różnicy między mechanizmem który pozwoli przechwycić sesję unieważniając ją dla jednego z klientów a takim który takie zdarzenie jest w stanie wykryć i całą sesję ubić
~ Języki dynamicznie typowane są dla amatorów poza JavaScript w którym on pisze
~ Tylko gimnazjaliści piszą w PHP
~ Można mówić o PHP nawet nie wiedząc nic o nim (zaczynając od domknięć którymi się podniecał a które PHP ma)
~ Najwyraźniej ktoś już napisał mechanizm sesji wspólny dla PHP i Node.js i stał się on powszechnym standardem a ja tutaj wynajduję koło od nowa.
~ Można się wypowiadać w temacie na forum nie na temat.
~ Zamiast w parę godzin dorobić czat + aktualizacje w czasie rzeczywistym lepszym i bardziej opłacalnym rozwiązaniem jest przepisanie całego intranetu firmowego zrobionego w PHP na noda poświęcając na to miesiące.
~ Nie wiadomo czego ludzie piszą w PHP (ślij petycję do Facebooka, NK, Allegro i innych amatorów)

Aż się strach odezwać. Pewnie dlatego ktoś z tej dyskusji już prowadzi ją ze mną dalej przez prywatne wiadomości żeby nie prowokować krzykacza.

Ło żesz... :))

+ prawdziwi mężczyźni bash/sh nie używają

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Wydaje mi się, że sam mechanizm sesji powinien być prosty - generujesz unikalny Session ID (np. te 40 znaków jako wynik funkcji skrótu na podstawie ip:timestamp:seckret)

Natomiast w samej sesji możesz trzymać dodatkowe informacje (np. wspomniane tokeny środowiskowe - IP, USER-AGENT, etc. - oraz oczywiście inne sesyjne rzeczy i to wszystko zserializowane do postaci którą wybrałeś, tj. json) i sprawdzać wiarygodność połączenia, per request. Taka już jest natura stateless, w tym przypadku HTTP, że mechanizm sesji po stronie klienta sprowadza się do identyfikacji połączenia (przekazywany w cookie identyfikator, wygenerowany po stronie serwera). Sam akt utworzenia klucza sesji nastepuje w momencie pierwszego połączenia z serwerem (==brak identyfikatora w cookie, ==unieważniona sesja/nieznany klucz) - załóż, że ten identyfikator zwsze można przechwycić (to nie mija się przecież z prawdą)

Do wykonania uwierzytelnienia użytkownika czy autoryzacji akcji/transakcji potrzebna jest wcześniejsza identyfikacja połączenia, są to jednak odrębne mechanizmy "wartstw wyżej"

1. [Identyfikacja połączenia]
2. [Uwierzytelnienie]
3. [Autoryzacja]Łukasz Podkalicki edytował(a) ten post dnia 04.11.12 o godzinie 18:33

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Tylko że sam hash w przypadku podsłuchania umożliwia wykonanie dowolnej ilości zapytań do czasu gdy ofiara nie podejmie jakiejś akcji, rozwiązanie z kodami eliminuje taką możliwość pozwalając wykonać tylko jedna akcję co gwarantuje bezpieczeństwo opcji wymagających dwukrotnego przeładowania strony.

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Dawid Zając:
Tylko że sam hash w przypadku podsłuchania umożliwia wykonanie dowolnej ilości zapytań do czasu gdy ofiara nie podejmie jakiejś akcji, rozwiązanie z kodami eliminuje taką możliwość pozwalając wykonać tylko jedna akcję co gwarantuje bezpieczeństwo opcji wymagających dwukrotnego przeładowania strony.

W 99% przypadków podsłuchania, jest możliwy również spoofing i izolacja ofiary, tak więc bez różnicy. Ale twórca tego tematu nie dopuszcza do siebie tak złych wiadomości :PMichał Łaszczewski edytował(a) ten post dnia 04.11.12 o godzinie 19:54

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Michał w domu nie ma drzwi, w końcu jak ktoś będzie chciał się włamać i tak się włamie...

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Tutaj się z Michałem zgadzam. Wszystko co trafia do aplikacji klienckiej po http (np. przeglądarki) i co z niej "wylatuje" również po http - jest do przejęcia i nie może mieć statusu - bezpieczne.

@Dawid
Mechanizm z kodami, o którym pisałeś, byłyby kryptograficznie silny jeśli mógłbyś takie kody generować po stronie klienta na bazie jakiegoś SecretID - znanego również serwerowi ale bez jawnej wymiany tej 'secret' informacji po http (bo można podsłuchać) Można oczywiście tutaj wykorzystać np. wymianę kluczy Diffie-Hellmana ale do czego dąże - wymiana takiej utajnionej soli jest przeważnie skomplikowana dlatego projektanci najczęściej sięgają po http over SSL. Kiedyś czytałem prezentację <nie pamiętam nazwy> firmy, która - zdaje się, że 2005 roku - opatentowała swój mechanizm, coś w rodzaju Cookie-OTP. Mechanizm miał być rozwijany, ze względu na prawo w USA, które z roku na rok wprowadza coraz większe restrykcje dot. bezpieczeństwa bankowości elektronicznej. Niestety, w prezentacji nie było nic na temat jak to robią :)Łukasz Podkalicki edytował(a) ten post dnia 04.11.12 o godzinie 20:36

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Łukasz Podkalicki:
Tutaj się z Michałem zgadzam. Wszystko co trafia do aplikacji klienckiej po http (np. przeglądarki) jest do przejęcia i nie może mieć statusu - bezpieczne.

Prawda ale to nie znaczy że należy zrezygnować z wszelkich zabezpieczeń jak tenże sugeruje. Ja jako osoba która wykonała mechanizm sesji mam w interesie by w wyniku ewentualnego ataku tejże sesji nie dało się przejąć a jeżeli ktoś to zrobi - należy mu utrudnić życie ile można.
Niech się programista który napisał aplikację martwi jak minimalizować szkody w wypadku udanego XSS.
Ataki man in the middle swoją drogą. Tutaj ciężko coś zrobić bez SSL itp.

@Dawid
Mechanizm z kodami, o którym pisałeś, byłyby kryptograficznie silny jeśli mógłbyś takie kody generować po stronie klienta na bazie jakiegoś SecretID - znanego również serwerowi ale bez jawnej wymiany tej 'secret' informacji po http (bo można podsłuchać) Można oczywiście tutaj wykorzystać np. wymianę kluczy Diffie-Hellmana ale do czego dąże - wymiana takiej utajnionej soli jest przeważnie skomplikowana dlatego projektanci najczęściej sięgają po http over SSL. Kiedyś czytałem prezentację <nie pamiętam nazwy> firmy, która - zdaje się, że 2005 roku - opatentowała swój mechanizm, coś w rodzaju Cookie-OTP. Mechanizm miał być rozwijany, ze względu na prawo w USA, które z roku na rok wprowadza coraz większe restrykcje dot. bezpieczeństwa bankowości elektronicznej. Niestety, w prezentacji nie było nic na temat jak to robią :)

Wtedy wracamy do pytania - jak taki klucz bezpiecznie przetrzymywać po stronie klienta.Dariusz Półtorak edytował(a) ten post dnia 04.11.12 o godzinie 20:48

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Dariusz Półtorak:

Łukasz Podkalicki:
Tutaj się z Michałem zgadzam. Wszystko co trafia do aplikacji klienckiej po http (np. przeglądarki) jest do przejęcia i nie może mieć statusu - bezpieczne.

Prawda ale to nie znaczy że należy zrezygnować z wszelkich zabezpieczeń jak tenże sugeruje. Ja jako osoba która wykonała mechanizm sesji mam w interesie by w wyniku ewentualnego ataku tejże sesji nie dało się przejąć a jeżeli ktoś to zrobi - należy mu utrudnić życie ile można.
Niech się programista który napisał aplikację martwi jak minimalizować szkody w wypadku udanego XSS.
Ataki man in the middle swoją drogą. Tutaj ciężko coś zrobić bez SSL itp.

Jak najbardziej Twoją słuszność sugerowałem w poprzednim poście. Ale idąc tą drogą wydzieliłbym w "Identyfikacja połączenia", tj,

1.1 [identyfikacja klucza sesji] - implementacja standardowego modelu sesji
1.2 [autoryzacja klucza sesji] - sprawdzanie tokenów środowiskowych, etc. - jeśli coś nie tak to ubijamy,

Wtedy wracamy do pytania - jak taki klucz bezpiecznie przetrzymywać po stronie klienta.

Tak, jak wymienić i jak przetrzymać :)

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Dariusz Półtorak:
Prawda ale to nie znaczy że należy zrezygnować z wszelkich zabezpieczeń jak tenże sugeruje. Ja jako osoba która wykonała mechanizm sesji mam w interesie by w wyniku ewentualnego ataku tejże sesji nie dało się przejąć a jeżeli ktoś to zrobi - należy mu utrudnić życie ile można.
Niech się programista który napisał aplikację martwi jak minimalizować szkody w wypadku udanego XSS.

W przypadku udanego XSS zabezpieczenie mechanizmu sesji jest bez znaczenia, bo można np. forwardować zapytania HTTP przez backdoora napisanego JS z użyciem np. JSONP - wtedy mechanizm sesji nic nie wykryje.

Wtedy wracamy do pytania - jak taki klucz bezpiecznie przetrzymywać po stronie klienta.

I tutaj również odpowiedź jest prosta: Nie ma takiej możliwości.
Chyba że ktoś rozważa “security through obscurity” = “the road to Hell is paved with good intentions” :)

Po prostu odpowiedzialność za MITM zwalamy na admina sieci, odpowiedzialność za XSS na programistę strony, odpowiedzialność za backdoory na administratora komputera. Żadnego z tych 3 zagrożeń nie da się zmniejszyć zmieniając mechanizm sesji.

Sprawa jest dość stara, dlatego ten temat to odkrywanie koła na nowo.

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Łukasz Podkalicki:

Jak najbardziej Twoją słuszność sugerowałem w poprzednim poście. Ale idąc tą drogą wydzieliłbym w "Identyfikacja połączenia", tj,

1.1 [identyfikacja klucza sesji] - implementacja standardowego modelu sesji
1.2 [autoryzacja klucza sesji] - sprawdzanie tokenów środowiskowych, etc. - jeśli coś nie tak to ubijamy,

I tak to działa. ID sesji + hash po stronie klienta. time użyty do generowania hasha + secret + ip klienta po stronie serwera. ID sesji jest po to by wiedzieć jaką sesję załadować i w wypadku problemów - jaką ubić. To 40-znakowy losowy ciąg znaków. Hash służy do weryfikacji sesji + jest regenerowany co request na podstawie time i z użyciem secret. Secret jest unikalny dla danej sesji.

To coś pomiędzy tym o czym mówił Dawid (tokeny) a standardowym mechanizmem (ciastko z ID i wznawiamy wg niego).

Wtedy wracamy do pytania - jak taki klucz bezpiecznie przetrzymywać po stronie klienta.

Tak, jak wymienić i jak przetrzymać :)

Wymiana to bajka. Na dobrą sprawę można użytkownikowi jakiś popup i wymagać by go ręcznie wpisał zostawiając kwestię przesłania adminowi i jemu. Problem jest z przechowywaniem.
Ostatnio z kolegą zastanawialiśmy się nad podobnym mechanizmem. Jeszcze się za to nie zabraliśmy ale w wolnej chwili chcemy porozglądać się po API rozszerzeń w Chrome i Firefox i sprawdzić czy dało by coś takiego osiągnąć w ten sposób.

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Michał Łaszczewski:
W przypadku udanego XSS zabezpieczenie mechanizmu sesji jest bez znaczenia, bo można np. forwardować zapytania HTTP przez backdoora napisanego JS z użyciem np. JSONP - wtedy mechanizm sesji nic nie wykryje.

Doprowadzenie do możliwości wykonania XSS na stronie można porównać do zostawienia zalogowanego konta w przeglądarce w "Kafejce". Projektant aplikacji powinien zabezpieczyć wykonanie akcji we wszystkich "wrażliwych" obszarach - np. autoryzacja hasłem, tokenem czy innym kluczem. No chyba, że mu słabo płacą :P

Sprawa jest dość stara, dlatego ten temat to odkrywanie koła na nowo.

Ale Michale, wartości poznawcze i doświadczenie, o jakie wzbogaci się Dariusz podczas projektowania rzeczy z półki "internals" są bezcenne. Nie traktowałbym tego jak wymyślanie koła.., tylko szukanie odpowiedniego rozwiązania. W tym przypadku - nieufność do otaczającej nas masy kodu sugeruje wręcz poprawnie naukowe podejście - nie wierzy, chce to zbadać i udoskonalić.

Temat: Sesja między PHP a Node.js czy wieloma serwerami - pomysły ?

Łukasz Podkalicki:

Sprawa jest dość stara, dlatego ten temat to odkrywanie koła na nowo.

Ale Michale, wartości poznawcze i doświadczenie, o jakie wzbogaci się Dariusz podczas projektowania rzeczy z półki "internals" są bezcenne. Nie traktowałbym tego jak wymyślanie koła.., tylko szukanie odpowiedniego rozwiązania. W tym przypadku - nieufność do otaczającej nas masy kodu sugeruje wręcz poprawnie naukowe podejście - nie wierzy, chce to zbadać i udoskonalić.

Temat dotyczy przede wszystkim mechanizmu sesji wspólnego dla Noda i PHP. I nie nazwał bym tego wymyślaniem koła od nowa. Rozwiązanie jest standardowe ale temat powstał po to by:
1. je udoskonalić
2. uzupełnić je o różne pomysły (jak np wspomniany system tokenów)
Wymiana doświadczeń nigdy nie jest zła. Dlatego nie chce mi się już z Michałem dyskutować bo ledwo ze szkoły wyszedł, jeszcze na poważnie nie pracował a już zachowuje się jak by pozjadał wszystkie rozumy jednocześnie albo mówiąc kompletne bzdury albo coś co w ogóle nic dodatniego nie wnosi do dyskusji.
Omówiłem dotychczasowe działanie mechanizmu z uwagi na to żeby rozmawiający wiedzieli o co chodzi.
Niektórzy mają bardzo duży problem ze zrozumieniem tego i przez niektórzy mam na myśli jedną osobę.