konto usunięte

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

Powitać,
opracowałem sobie prosty mechanizm sesji po to by połączyć aplikację w PHP z Node.js który jest wykorzystany do elementów które muszą działać w czasie rzeczywistym (czaty między pracownikami i tego typu sprawy) i tam gdzie Ajax już by się zupełnie nie nadał (zawsze mogłem użyć Ajax i long polling) czyli do elementów gdzie potrzebny jest push informacji z serwera do klientów.
Chciałem tez by sesję można było rozpocząć zarówno od strony PHP jak i Node.js.

Chciał bym opinię, sugestie i co Wam do głowy przyjdzie na temat tego pomysłu.

Po sprawdzeniu kilku opcji zdecydowałem się na utworzenie mechanizmu sesji za pomocą Redisa. Żeby łatwo było z niej korzystać (i składować dane) postanowiłem za format danych przyjąć JSON. Działa to tak:

1. Przy tworzeniu nowej sesji, zostaje wygenerowany 40-znakowy, losowy ciąg znaków który od tego momentu służy jako ID sesji.
2. Przygotowuje mały obiekt JSON w tej postaci:


{
secret: (...) // 40-znakowy sekretny ciąg generowany przy inicjacji sesji
time: (...) // timestamp
ip: (...) // IP klienta
data: {} // tutaj będą składowane dane, interfejs klasy będzie operował na tym obiekcie
hash: {} // suma kontrolna z id, ip, secret i time
}


3. Ustawiam ciasteczko w kliencie w tej postaci:
DPSID="[id]:[hash]"


4. Przy każdym odwołaniu do serwera time jest odświeżany, zmienia się hash i od nowa ustawione jest ciasteczko.

Teraz - w momencie gdy otwieramy stronę:
1. Skrypt szuka ciasteczka DPSID i odczytuje je
2. Rozbija je wg :. Na dobrą sprawę skoro SID i HASH będą miały ustaloną długość, mogę to wykorzystać nie dając znaku rozbicia.
3. Pobieram z Redisa wartość spod podanego ID
4. Sprawdzam sumę kontrolną
5. Sprawdzam czy IP nadal jest to samo
6. time również będzie wykorzystany by zrobić czasowe wygaśnięcie sesji
7. Zapisywany jest nowy timestamp i odświeżane jest ciasteczko DPSID.
8. Jeżeli wszystko jest OK, wznawiam sesję.

Wybrałem JSON z uwagi na to że łatwo go konwertować z obiektu do ciągu znaków i odwrotnie zarówno w PHP jak i JavaScript.

Redis jest szybki, wygodny i do tego dostępny u mnie na serwerze.
Zabawa z czasem, secret i hash jest po to by trudniej było przejąć sesję poprzez zakoszenie ciasteczka NAWET jeżeli atakujący ma to samo IP czy nawet wie jak generowany jest hash. Ciasteczko jest ważne tylko do następnego requesta.
Zastanawiam się nad wykorzystaniem dodatkowych informacji jak user-agent i podobne.

Wszelkie sugestie z Waszej strony mile widziane. Porady, pomysły itp. Normalnie bym się zbytnio nie przejmował ale chcę opracować taki mechanizm który później mógł bym bez problemu używać zarówno przy współpracy między PHP a Node.js jak i mając do czynienia z architekturą wielo-serwerowa.

konto usunięte

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

Pomysł ciekawy ale użycie dodatkowych danych jak user-agent zalecam jako opcje dodatkową dla połączeń wymagajacych większego bezpieczeństwa.

Możesz wprowadzić bardzo dobre zabezpieczenie w postaci tablicy kodów, podobnie jak jest to w bankach tzn:

Przy tworzeniu nowej sesji, zostaje wygenerowany 40-znakowy, losowy ciąg znaków który od tego momentu służy jako ID sesji oraz tablica kodów do autoryzacji każdego odwołania.
Potem wysyłasz to wszystko i zapisujesz u klienta a każdy request będzie wysyłał hash i jeden kod dzięki czemu przechwycenie samego hasha nie pozwoli uzyskać autoryzacji, podobnie przechwycenie całości pozwoli tylko na pojedyńczą operację.
Natomiast zmianę IP można weryfikować zapytaniem o dodatkowy kod co eliminuje możliwość podmiany treści requesta przez atakującego który przechwycił request w drodze do serwera.

Wadą takiego rozwiązania jest ograniczona ilość kodów, wymagająca ich okresowego uzupełnienienia ale można ją zmniejszyć wykorzystując zapas z poprzedniego lub pierwszego zestawu kodów autoryzujących.

konto usunięte

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

User-agent będzie opcjonalny. Będzie kilka flag do ustawienia. Hash jest wprowadzony bo nie chcę zmieniać ID sesji (niewygodne jeżeli ID traktujemy jako klucz w redis) a chcę chronić chociaż odrobinę użytkownika przed przechwyceniem ciasteczka.
Zakładając że kiedyś upublicznię ten kod i to że użytkownik pozna metodę generowania sumy kontrolnej z danych które właściwie może uzyskać (id sesji, ip użytkownika i powiedzmy że czas wywołania jeżeli się pośpieszy zanim ten w coś kliknie) dorzuciłem "secret" czyli pomocniczy 40-znakowy ciąg który będzie działał do czasu zamknięcia sesji.

Jak wspominałem Redis mam na serwerze który mam wykopiony i od razu daje mi możliwość ustawienia czasu wygaśnięcia klucza co również jest bardzo pomocne i ściąga ze mnie wymóg sprzątania .

Mógł byś szerzej opisać ową koncepcję kodów ? Jeżeli nie kolidowało by to z obecnym rozwiązaniem to zawsze w wolnej chwili mógł bym dopisać takowy mechanizm jak by kiedyś komuś się to przydało.

Cóż, jeżeli ktoś ma jakieś pomysły i sugestie to walcie śmiało.

konto usunięte

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

Koncepcja kodów jest banalna i opiera się na założeniu że jeżeli nie znasz kodu to nie jesteś tym za kogo sie podajesz. Pierwszy ich zestaw jest całkowicie bezproblemowy ponieważ jest dostarczany razem z ID sesji, hashem itp i może służyć jedynie do potwierdzania zmiany IP podnosząc znacznie bezpieczeństwo. Jednak gdy skończy sie pierwszy zestaw trzeba wysłać następny nie mając pewności czy nie zostanie podsłuchany po drodze.

Używanie kodów bedzie wyglądało mniej wiecej tak:
Przypadek A:
1. serwer wykrył zmianę IP
2. serwer prosi o potwierdzenie zmiany IP poprzez podanie kodu nr x z zestawu do zmiany IP
3. jeśli klient nie poda poprawnego kodu zostaje wyrzucony

Przypadek B (w uproszczeniu bo można wykrywać dokładny rodzaj oszustwa):
1. serwer otrzymał request z kodem "xyz"
2. serwer sprawdza czy taki kod jest w kopi tablicy wysłanej klientowi, czy poprzedni kod został zużyty i czy przysłany jest niezużyty
3. jeśli coś jest nie tak serwer odrzuca request

Mam jeszcze jeden przypadek w głowie ale on sprawdzi się jedynie przy analizowaniu czy spod jednego IP nadaje atakujący i klient pod warunkiem że atakujący nie widzi wszystkich requestów klienta (czyli bezużyteczne dla ciebie bo hash go wykończy)Dawid Zając edytował(a) ten post dnia 02.11.12 o godzinie 15:54

konto usunięte

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

Czyli w skrócie mówiąc

1. generuję sesję
2. generuję lub pobieram z jakiejś listy/generatora pulę kodów (powiedzmy 100 kodów)
3. Wysyłam ją przy tworzeniu sesji.
4. Co odświeżenie (lub np wznowienie nieaktywnej sesji) oczekuję że klient poda mi w jakiś sposób (np ustawiając ciastko po swojej stronie) ów kod (no właśnie, jak podawać kod z klienta do serwera ?) co go autoryzuje.
5. Jeżeli kod jest nieprawidłowy ubijam sesję.
6. Jeżeli kody klienta zostały zużyte, serwer wysyła kolejną paczkę i jest to request zwiększonego ryzyka

Dało by się zrobić małym kosztem. Fakt faktem nadal klient jest narażony na XSS z uwagi na to że owe kody trzeba jakoś przechować. Bo ryzyko podsłuchu można zminimalizować stosując https.

konto usunięte

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

Prawidłowo to zrozumiałeś :)
Dariusz Półtorak:
... (no właśnie, jak podawać kod z klienta do serwera ?)...

W dowolny sposób oby serwer był w stanie odczytać ten ciąg znaków, nie miałem styczności z Node.js i nawet nie próbowałem wnikać w jaki sposób przekazujesz dane.
Dało by się zrobić małym kosztem. Fakt faktem nadal klient jest narażony na XSS z uwagi na to że owe kody trzeba jakoś przechować.

I tu zaczyna sie zabawa z zaawansowaną kryptografią, zdaje mi się że kilka miesięcy temu czytałem artykuł o "Nie wiem co mam ale jak wam powiem co chcecie to będziecie wiedzieli co mam" ale tak mi sie po nim zakręciło w głowie że nawet nie chcę go szukać.
Może wymyślę coś na XSS ale musisz dokładnie opisać w którym momencie wykradniesz ciastka i co możesz odczytać przy kolejnych żądaniach.

konto usunięte

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

Znaczy się zabawa z kodami sprawi że po tym jak użytkownik ukradnie powiedzmy ciastko zawierające kody (zakładając że obejdzie resztę zabezpieczeń) będzie mógł wykonać requesty do czasu aż ten drugi coś zrobi.
Myślę że to całkiem niezłe rozwiązanie.

Tylko żeby je zrobić łatwiejszym do zaimplementowania głosował bym za takim rozwiązaniem.

1. W konfiguracji obiektu obsługującego sesje ustawiasz ilość kodów, powiedzmy na 200.
2. Kody to losowe, 5 literowe ciągi znaków (przykładowo).
3. Przy pierwszym utworzeniu sesji wysyłasz 1000-znakowy ciąg (z tego co pamiętam, bezpieczny limit dla przeglądarek to 4000 znaków)
Przy każdym wywołaniu strony skrypt js sprawdza ciastko, ucina je o pierwsze 5 znaków i ustawia te 5 znaków na nowo generują drugie ciastko z tokenem.
4. Serwer sprawdza to ciastko przy wywołaniu adresu i jeżeli się zgadza z 5 znakami które ma na początku u siebie, autoryzuje wejście i obcina 5 znaków z początku ciągu.
5. Jak ciąg osiągnie 0, w tym momencie ustawiane jest ciastko z ciągiem na nowo.

konto usunięte

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

Nieźle zakombinowałeś z ucinaniem, czytając to wpadłem na pomysł przesyłania w odpowiedzi serwera kolejnego kodu, dzieki temu uzupełniany będzie zapas a kody będące w ciastku starczą na wiele bezpiecznych połączeń zanim dojdzie do użycia tego potencjalnie możliwego do podsłuchania.

Edit:
A jeśli chodzi o połączenie serwer-serwer to można osiągnąć bardzo wysoki stopień bezpieczeństwa (do złamania jedynie przez podstawiony router) gdyby z otrzymanego kodu i swojego stałego tajnego identyfikatora generować jednorazowy klucz, dzięki temu nawet podsłuchanie czegokolwiek nic nie daje bo przesyłana tablica kodów jest bezużyteczna.
Działałoby to mniej więcej tak:
1. Klient-serwer otrzymuje tablice kodów i wysyła żadanie dołączając jednorazowy klucz
2. Serwer główny otrzymuje klucz i sprawdza czy wygenerowany przez niego (na podstawie kodu i identyfikatora klienta który zna bo administrator wpisał) jest identycznyDawid Zając edytował(a) ten post dnia 02.11.12 o godzinie 18:53

konto usunięte

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

Aktualnie robię projekt na node.js, memcached, php i mysql zabieg jaki wykorzystałem jest następujący.

W bazie użytkowników trzymam (poza podstawowymi danymi):
userID, phpID, socketID

przy wywołaniu strony przez zalogowanego użytkownika ustawiam phpID = id_sesji, socketID = '',
Po załadowaniu podstawowego kodu strony socket.io łączy się z node.js i klient otrzymuje socketID.
socketID zapisuję przy pomocy AJAX do konkretnego użytkownika w mySQL.

Zatem po całkowitym połączeniu mam w bazie informację kto, z jakiej sesji PHP oraz z jakiego socketa się łączy. Dane te trzymam także w memcached aby móc z nich skorzystać w node.js.

Przy każdym zapytaniu do node.js sprawdzam w memcached czy socketID jest przypisane do jakiegoś użytkownika i po tym go identyfikuję.

Przy rozłączeniu dana informacja usuwana jest z memcached.

ID sesji PHP tworzone jest na podstawie IP, przeglądarki oraz losowych 10 cyfr.

P.S. w node.js trzymam też obiekt z informacjami
[md5(socketID) : [sesja, userID, _GET], .....] dzięki czemu np. na czacie wiem do których użytkowników i co ma wysyłać node.js (na podstawie tego skąd wywołali połączenie z socketem)Sebastian Poddubiuk edytował(a) ten post dnia 03.11.12 o godzinie 14:42

konto usunięte

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

Sebastian Poddubiuk:
Aktualnie robię projekt na node.js, memcached, php i mysql zabieg jaki wykorzystałem jest następujący.

W bazie użytkowników trzymam (poza podstawowymi danymi):
userID, phpID, socketID

Tylko że mechanizm sesji powinien działać samodzielnie. Nie powinien być związany z użytkownikiem w systemie tylko użytkownikiem odwiedzającym stronę.

przy wywołaniu strony przez zalogowanego użytkownika ustawiam phpID = id_sesji, socketID = '',
Po załadowaniu podstawowego kodu strony socket.io łączy się z node.js i klient otrzymuje socketID.
socketID zapisuję przy pomocy AJAX do konkretnego użytkownika w mySQL.

Ale czy to nie oznacza że będziesz miał tam tylko socketId najnowszej zakładki ? Mówiąc o sytuacji gdzie ktoś otworzy kilka zakładek z Twoją stroną.

konto usunięte

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

ad 1), W tym co robię niezalogowany użytkownik nic nie może więc to nie problem
ad 2), Tak, tak jak w niektórych bankach, otworzenie nowej karty/okna unieważnia poprzednie

konto usunięte

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

Sebastian, to o czym piszesz to nie sesje tylko widoki :)

Po co łączyć PHP z node.JS? Przecież javascript jest wielokrotnie lepszy od PHP.
Po drugie to przywiązywanie adresu IP do sesji jest raczej bez sensu, jak ktoś ma paranoje to o wiele lepiej użyć np. podpisu cyfrowego. Zakładanie że ktoś przechwyci kod i podszyje się pod użytkownika z innego IP jest również bez sensu. Jak ktoś może przechwycić komunikacje, to może też spoofować i zrobić połączenie z tego samego adresu IP.
Po trzecie dane sesji trzyma się w bazie danych, i w tym momencie odpada problem przekazywania danych sesji między klientami.

Coś mi się wydaje że próbujecie od nowa rozwiązywać problemy które zostały już dawno temu rozwiązane.

Dodane:
Jak wam tak zależy na bezpieczeństwie, to lepiej użyć JavyEE.Michał Łaszczewski edytował(a) ten post dnia 03.11.12 o godzinie 16:36

konto usunięte

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

Faktycznie trochę za bardzo kombinujemy ale zapomniałeś chyba że np obecnie wielu ludzi korzysta z nieszyfrowanego WIFI i dodatkowe zabezpieczenie sesji jest bardzo wskazane, a samo ID nie służy zabezpieczaniu a jedynie identyfikacji.

konto usunięte

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

Michał Łaszczewski:
Po co łączyć PHP z node.JS? Przecież javascript jest wielokrotnie lepszy od PHP.

Aż boję się zapytać pod jakim względem. Ale pomijając całą dywagację na ten temat i puste spory - odpowiedź jest prosta.
Jak Ci trzeba jakiś czat, aktualizacje w czasie rzeczywistym czy musisz mieć push z serwera bez czekania na request klienta na witrynie PHP nie przepisujesz całej witryny na Noda. Dopisujesz co Ci trzeba w Node i robisz co trzeba by ze sobą odpowiednio współpracowali.

Poza tym popraw mnie jeżeli się mylę ale jak ostatnio sprawdzałem Node.js nie przychodzi w pakiecie z obsługą sesji. Express.js owszem ma coś takiego i o ile pamiętam działa tylko w obrębie jednego serwera.

Także tak czy siak coś takiego się przyda.
Po drugie to przywiązywanie adresu IP do sesji jest raczej bez sensu, jak ktoś ma paranoje to o wiele lepiej użyć np. podpisu cyfrowego. Zakładanie że ktoś przechwyci kod i podszyje się pod użytkownika z innego IP jest również bez sensu. Jak ktoś może przechwycić komunikacje, to może też spoofować i zrobić połączenie z tego samego adresu IP.

Wybacz ale to co mówisz to są kompletne bzdury. Mechanizm sesji opierający się na ciasteczku ma tę wadę że jeżeli z powodzeniem wykonamy XSS możemy zakosić komuś dane ciasteczko i zwyczajnie wznowić sesję u siebie. Testowanie IP to jedna z metod które temu przeciwdziałają.
Owszem, zawsze można użyć httpOnly ale też głupotą jest wg mnie poleganie na tym że przeglądarka (jakakolwiek by nie była) będzie to obsługiwać, nie będzie miała luki czy czegoś innego. Lepiej takie coś mieć i nie potrzebować jak potrzebować i nie mieć.
Po trzecie dane sesji trzyma się w bazie danych, i w tym momencie odpada problem przekazywania danych sesji między klientami.

A dlaczego mam zaprzęgać bazę danych ? Osobiście uważam Redis za jedno z lepszych rozwiązań. Załatwia za mnie sprawę wygaśnięcia sesji, jest bardzo szybki, jest w stanie obsłużyć znacznie więcej requestów niż MySQL i podobne nie mówiąc o tym że sam Redis jest nieporównywalnie lekki w porównaniu do jakiejkolwiek odpalonej bazy (utworzyłem 10000 sesji i zajął całe G pamięci).

Coś mi się wydaje że próbujecie od nowa rozwiązywać problemy które zostały już dawno temu rozwiązane.

Coś mi się wydaje że nie masz racji. Rozglądając się za różnymi implementacjami sesji widziałem sporo różnych rozwiązań i nie powiem żeby ktoś polecał jakieś konkretne. Każdy robi wg tego co ma akurat pod ręką i na czym mu zależy.
Zrobiłem własne na szczególne potrzeby i stąd ten temat by ten mechanizm uczynić jeszcze lepszym.Dariusz Półtorak edytował(a) ten post dnia 03.11.12 o godzinie 16:58

konto usunięte

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

Sebastian Poddubiuk:
ad 1), W tym co robię niezalogowany użytkownik nic nie może więc to nie problem
ad 2), Tak, tak jak w niektórych bankach, otworzenie nowej karty/okna unieważnia poprzednie

Wiesz, jak by na to nie patrzeć, jeżeli piszesz mechanizm sesji to piszesz go tak by był uniwersalny. Wszystko o czym mówisz jestem w stanie osiągnąć ze swoim jednocześnie niczego nie poświęcając.
Dodatkowo wydaje mi się prostszy i bardziej niezawodny niż to co opisałeś, zaczynając od tego że nic nie gwarantuje że ajax przyjdzie jak powinien.
Osobiście wolę trzymać cały mechanizm sesji po stronie serwera a po stronie klienta trzymać tylko powiązany z nią identyfikator. Dariusz Półtorak edytował(a) ten post dnia 03.11.12 o godzinie 17:23

konto usunięte

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

Dawid Zając:
Nieźle zakombinowałeś z ucinaniem, czytając to wpadłem na pomysł przesyłania w odpowiedzi serwera kolejnego kodu, dzieki temu uzupełniany będzie zapas a kody będące w ciastku starczą na wiele bezpiecznych połączeń zanim dojdzie do użycia tego potencjalnie możliwego do podsłuchania.

Edit:
A jeśli chodzi o połączenie serwer-serwer to można osiągnąć bardzo wysoki stopień bezpieczeństwa (do złamania jedynie przez podstawiony router) gdyby z otrzymanego kodu i swojego stałego tajnego identyfikatora generować jednorazowy klucz, dzięki temu nawet podsłuchanie czegokolwiek nic nie daje bo przesyłana tablica kodów jest bezużyteczna.
Działałoby to mniej więcej tak:
1. Klient-serwer otrzymuje tablice kodów i wysyła żadanie dołączając jednorazowy klucz
2. Serwer główny otrzymuje klucz i sprawdza czy wygenerowany przez niego (na podstawie kodu i identyfikatora klienta który zna bo administrator wpisał) jest identyczny

Tak rozpisałem sobie to o czym mówiłeś na papierze i muszę powiedzieć że na razie tego nie widzę. W wypadku stosowania ajax ten mechanizm często będzie zawodził bo niestety token po stronie klienta jest jeden a niestety serwer nie musi otrzymać requestów w tej samej kolejności w jakiej zostały wysłane.

Rozwiązaniem jakimś jest listowanie bezpiecznych adresów które wywołają opisany mechanizm (przytną ciąg i porównają z tokenem) tak by tylko tam gdzie potrzeba użyty był token co zminimalizuje problem jednoczesnych requestów (tylko konkretne adresy będą obsługiwały mechanizm). Tylko wtedy po stronie klienta trzeba dopisać kod który wywoła przestawienie tokena. Nie będzie już tego można robić automatycznie.

konto usunięte

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

Dariusz Półtorak:
Tak rozpisałem sobie to o czym mówiłeś na papierze i muszę powiedzieć że na razie tego nie widzę. W wypadku stosowania ajax ten mechanizm często będzie zawodził bo niestety token po stronie klienta jest jeden a niestety serwer nie musi otrzymać requestów w tej samej kolejności w jakiej zostały wysłane.

O takiej możliwości nie pomyślałem, ale są 2 rozwiązania:

1. Do każdego requesta oprócz identyfikatora dodajesz też orginalny nieprzetworzony kod i znacznik czasu dzieki czemu serwer nie musi otrzymywać kolejno requestów, a jeśli dostałby wyprzedzony identyfikator to mógłby zaczekać z odpowiedzią aż dojdzie poprzedni.(swoja drogą można sprawdzać wiarygodność takich requestów wzajemnie ale chyba nie ma sensu robić aż tak skomplikowanego rozwiązania bo nie będzie uniwersalne)

2. Stworzyć bazę gotowych identyfikatorów na serwerze odbierajacym i sprawdzać czy przysłany istnieje w niej jako niewykorzystany.

Co prawda w tym drugim rozwiązaniu tracimi możliwość wykrywania czy ktoś przechwycił identyfikator i wykonał nim zapytanie ale to właściwie nieistotne bo sposoby na to są tylko 2:
A) Któryś z serwerów został przejęty przez atakującego dzieki czemu zdobył on tablicę kodów i 'sól' do generowania klucza
B) Request został przechwycony przez router lub serwer pośredniczący i podmieniony przez atakującego
Jak dla mnie w obu tych przypadkach masz Game Over i nie warto ich rozważaćDawid Zając edytował(a) ten post dnia 03.11.12 o godzinie 22:12

konto usunięte

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

Dariusz Półtorak:
Aż boję się zapytać pod jakim względem. Ale pomijając całą dywagację na ten temat i puste spory - odpowiedź jest prosta.
Jak Ci trzeba jakiś czat, aktualizacje w czasie rzeczywistym czy musisz mieć push z serwera bez czekania na request klienta na witrynie PHP nie przepisujesz całej witryny na Noda. Dopisujesz co Ci trzeba w Node i robisz co trzeba by ze sobą odpowiednio współpracowali.
Tylko po co to PHP? Przywiązany do niego jesteś czy co?
Dariusz Półtorak:
Poza tym popraw mnie jeżeli się mylę ale jak ostatnio sprawdzałem Node.js nie przychodzi w pakiecie z obsługą sesji. Express.js owszem ma coś takiego i o ile pamiętam działa tylko w obrębie jednego serwera.
Sesje się trzyma w bazie danych.
Wybacz ale to co mówisz to są kompletne bzdury. Mechanizm sesji opierający się na ciasteczku ma tę wadę że jeżeli z powodzeniem wykonamy XSS możemy zakosić komuś dane ciasteczko i zwyczajnie wznowić sesję u siebie. Testowanie IP to jedna z metod które temu przeciwdziałają.
To zabezpiecz stronę przez XSS. Przez XSS można jeszcze zrobić wiele innych gorszych rzeczy niż ukradnięcie ciasteczka. Po pierwsze po co kraść ciasteczko jeśli mamy przejętą kontrolę przez XSS?
Po trzecie dane sesji trzyma się w bazie danych, i w tym momencie odpada problem przekazywania danych sesji między klientami.

A dlaczego mam zaprzęgać bazę danych ? Osobiście uważam Redis za jedno z lepszych rozwiązań. Załatwia za mnie sprawę wygaśnięcia sesji, jest bardzo szybki, jest w stanie obsłużyć znacznie więcej requestów niż MySQL i podobne nie mówiąc o tym że sam Redis jest nieporównywalnie lekki w porównaniu do jakiejkolwiek odpalonej bazy (utworzyłem 10000 sesji i zajął całe G pamięci).
To użyj np. mongo albo cassandry, a nie MySQL, jak napisałem bazę danych to nie miałem na myśli SQLa. Dodatkowo mongo może pracować rozproszone więc odpada problem skalowalności.

Coś mi się wydaje że nie masz racji. Rozglądając się za różnymi implementacjami sesji widziałem sporo różnych rozwiązań i nie powiem żeby ktoś polecał jakieś konkretne. Każdy robi wg tego co ma akurat pod ręką i na czym mu zależy.
Zrobiłem własne na szczególne potrzeby i stąd ten temat by ten mechanizm uczynić jeszcze lepszym.
Nie wiem jak sprawa wygląda w PHP w którym i tak piszą tylko gimnazjaliści, ale w JavieEE te problemy zostały rozwiązane wiele lat temu.

Dodatkowo w ramach trollowania:
Jak ktoś uważa że PHP jest lepsze od JavaScripta to znaczy że ma zerowe pojęcie o programowaniu. Jak w ogóle można uważać że język funkcyjno-obiektowy, zbliżony do LISPa jest gorszy od czegoś tak niezdefiniowanego, zaśmieconego i nielogicznego jak PHP.Michał Łaszczewski edytował(a) ten post dnia 03.11.12 o godzinie 18:34

konto usunięte

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

Michał Łaszczewski:
Dariusz Półtorak:
Aż boję się zapytać pod jakim względem. Ale pomijając całą dywagację na ten temat i puste spory - odpowiedź jest prosta.
Jak Ci trzeba jakiś czat, aktualizacje w czasie rzeczywistym czy musisz mieć push z serwera bez czekania na request klienta na witrynie PHP nie przepisujesz całej witryny na Noda. Dopisujesz co Ci trzeba w Node i robisz co trzeba by ze sobą odpowiednio współpracowali.
Tylko po co to PHP? Przywiązany do niego jesteś czy co?

Myślałem że napisałem to wyraźnie. Widocznie nie za co przepraszam więc wyjaśnię w punktach.

1. Chodzi o stronę w PHP która JUŻ JEST NAPISANA i nie jest mała. To firmowy intranet. Wymaga usprawnień. Chodzi o aktualizacje w czasie rzeczywistym tu i ówdzie + czat pomiędzy pracownikami. Node się świetnie do tego nadaje.
2. Wbrew pozorom ów czat + aktualizacje to szybka piłka. Node + socket.io + mongoose (intranet używa MongoDB).
3. O wiele szybsza piłka niż w wypadku przepisywania CAŁEGO intranetu na nowo pod Noda. Ani czasu na to nie ma ani to się nie opłaca.
4. Mechanizm już jest i działa. Temat stworzyłem bo chcę zobaczyć czy czegoś nie przeoczyłem robiąc go, co mógł bym tam jeszcze dorzucić i może w którymś momencie rzucę go na github.
Dariusz Półtorak:
Poza tym popraw mnie jeżeli się mylę ale jak ostatnio sprawdzałem Node.js nie przychodzi w pakiecie z obsługą sesji. Express.js owszem ma coś takiego i o ile pamiętam działa tylko w obrębie jednego serwera.
Sesje się trzyma w bazie danych.

Mówię o samym mechanizmie sesji w Node. Nie ma takowego serwowanego z całą paczką jak w wypadku PHP.
Wybacz ale to co mówisz to są kompletne bzdury. Mechanizm sesji opierający się na ciasteczku ma tę wadę że jeżeli z powodzeniem wykonamy XSS możemy zakosić komuś dane ciasteczko i zwyczajnie wznowić sesję u siebie. Testowanie IP to jedna z metod które temu przeciwdziałają.
To zabezpiecz stronę przez XSS. Przez XSS można jeszcze zrobić wiele innych gorszych rzeczy niż ukradnięcie ciasteczka. Po pierwsze po co kraść ciasteczko jeśli mamy przejętą kontrolę przez XSS?

Co nie zmienia faktu że jeżeli komuś powiedzie się atak XSS to jednak wolę by session hijacking nie był na liście tego co może zrobić.
Poza tym przeceniasz XSS. Czasem wystarczy wrażliwe operacje zabezpieczyć poprzez wymóg podania hasła administratora i po ptakach. Trzeba się już postarać.
Po trzecie dane sesji trzyma się w bazie danych, i w tym momencie odpada problem przekazywania danych sesji między klientami.

A dlaczego mam zaprzęgać bazę danych ? Osobiście uważam Redis za jedno z lepszych rozwiązań. Załatwia za mnie sprawę wygaśnięcia sesji, jest bardzo szybki, jest w stanie obsłużyć znacznie więcej requestów niż MySQL i podobne nie mówiąc o tym że sam Redis jest nieporównywalnie lekki w porównaniu do jakiejkolwiek odpalonej bazy (utworzyłem 10000 sesji i zajął całe G pamięci).
To użyj np. mongo albo cassandry, a nie MySQL, jak napisałem bazę danych to nie miałem na myśli SQLa. Dodatkowo mongo może pracować rozproszone więc odpada problem skalowalności.

Dałem tylko przykład. Akurat w tym wypadku Redis był już dostępny to grzech było nie skorzystać. Dodam że poprzedni mechanizm sesji był na MySQL (stąd mój komentarz) i fakt faktem kompletnie się nie sprawdzał.
Redis jest po prostu szybszy i bardzo lekki.

Coś mi się wydaje że nie masz racji. Rozglądając się za różnymi implementacjami sesji widziałem sporo różnych rozwiązań i nie powiem żeby ktoś polecał jakieś konkretne. Każdy robi wg tego co ma akurat pod ręką i na czym mu zależy.
Zrobiłem własne na szczególne potrzeby i stąd ten temat by ten mechanizm uczynić jeszcze lepszym.
Nie wiem jak sprawa wygląda w PHP w którym i tak piszą tylko gimnazjaliści, ale w JavieEE te problemy zostały rozwiązane wiele lat temu.

Mechanizm sesji dla Javy i Node.js wiele lat temu ? Biorąc pod uwagę że Node jest chyba z 2010 roku to kłaniam się przed programistami Javy którzy napisali ładny mechanizm sesji dla niej zanim sam Node powstał.
Nie wiem czy widzisz jak głupio brzmisz. Poza tym Twój komentarz na PHP pokazuje jaki sam dorosły jesteś więc proszę - znajdź sobie inny wątek. Takiego poziomu tu w dyskusji nie chcemy.

Potrzebny był mechanizm sesji dla Noda i PHP. Nie jest to jakaś skomplikowana czy czasochłonna rzecz. Składuję dane z użyciem JSON bo zarówno PHP jak i Node mają natywną obsługę tego formatu co ułatwia sprawę.

Dodatkowo w ramach trollowania:
Jak ktoś uważa że PHP jest lepsze od JavaScripta to znaczy że ma zerowe pojęcie o programowaniu. Jak w ogóle można uważać że język funkcyjno-obiektowy, zbliżony do LISPa jest gorszy od czegoś tak niezdefiniowanego, zaśmieconego i nielogicznego jak PHP.

Biorąc pod uwagę że PHP dorósł już 8 lat temu jeżeli chodzi o obiektówkę a obecnie ma już domknięcia, przestrzenie nazw, krótki zapis tablic, pozwala od razu po metodzie/funkcji która zwraca tablicę poprosić o odpowiedni klucz ( doSomething()[1]; - nie pamiętam fachowej nazwy ), do tego traitsy i parę innych rzeczy - dość łatwo mi z Twoim zdaniem polemizować.
Trudno mówić lepszy/gorszy z uwagi na to że jednak PHP i JS się znacząco różnią jednak na pewno nie powiem by PHP miał się czego wstydzić w dniu dzisiejszym.

Proponuje byś znalazł sobie inny temat. Tu chcemy poważnie rozmawiać a nie słuchać kolejnego trolla ewangelisty.Dariusz Półtorak edytował(a) ten post dnia 03.11.12 o godzinie 21:26

konto usunięte

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

Dariusz Półtorak:
1. Chodzi o stronę w PHP która JUŻ JEST NAPISANA i nie jest mała. To firmowy intranet. Wymaga usprawnień. Chodzi o aktualizacje w czasie rzeczywistym tu i ówdzie + czat pomiędzy pracownikami. Node się świetnie do tego nadaje.
To macie przerąbane, ja utknąłem w czymś podobnym i teraz muszę też cudować, ale docelowo zamierzam przepisywać całość na Node.JS
Mówię o samym mechanizmie sesji w Node. Nie ma takowego serwowanego z całą paczką jak w wypadku PHP.
Mechanizm sesji to 3 linie kodu - pobranie zawartości cookie(czy innego parametru w przypadku ws/ajaxa), pobranie sesji z bazy danych po id, sprawdzenie klucza. Cudujecie panowie, cudujecie strasznie.
Co nie zmienia faktu że jeżeli komuś powiedzie się atak XSS to jednak wolę by session hijacking nie był na liście tego co może zrobić.
Co nie zmienia faktu że jak komuś powiódł się atak XSS to może zrobić wszystko. A blokując po IP utrudniasz ludziom z różnymi dziwnymi łączami normalne używanie strony, i i tak nie masz pewności czy ktoś IP nie może ukraść. W przykładzie z nieszyfrowanym Wifi jest to dość proste.
Poza tym przeceniasz XSS. Czasem wystarczy wrażliwe operacje zabezpieczyć poprzez wymóg podania hasła administratora i po ptakach. Trzeba się już postarać.
No ale w takim wypadku kradzież sesji również nic nie daje.
Mechanizm sesji dla Javy i Node.js wiele lat temu ? Biorąc pod uwagę że Node jest chyba z 2010 roku to kłaniam się przed programistami Javy którzy napisali ładny mechanizm sesji dla niej zanim sam Node powstał.
Jaki jest problem z przepisaniem mechanizmu sesji z Javy do Node i PHP? Sam algorytm został już wymyślony, i to w całej masie wariacji, kombinowanie przy tym to odkrywanie koła na nowo.
Nie wiem czy widzisz jak głupio brzmisz. Poza tym Twój komentarz na PHP pokazuje jaki sam dorosły jesteś więc proszę - znajdź sobie inny wątek. Takiego poziomu tu w dyskusji nie chcemy.
Widziałeś stronę banku napisaną w PHP? stronki w PHP tworzą gimnazjaliści, a poważne firmy używają Javy albo dotNeta.
Potrzebny był mechanizm sesji dla Noda i PHP. Nie jest to jakaś skomplikowana czy czasochłonna rzecz. Składuję dane z użyciem JSON bo zarówno PHP jak i Node mają natywną obsługę tego formatu co ułatwia sprawę.
JSON to dobry wybór, w zasadzie jedyny słuszny.
Biorąc pod uwagę że PHP dorósł już 8 lat temu jeżeli chodzi o obiektówkę a obecnie ma już domknięcia, przestrzenie nazw, krótki zapis tablic, pozwala od razu po metodzie/funkcji która zwraca tablicę poprosić o odpowiedni klucz ( doSomething()[1]; - nie pamiętam fachowej nazwy ), do tego traitsy i parę innych rzeczy - dość łatwo mi z Twoim zdaniem polemizować.
Żadnej z tych rzeczy nie miał na początku, wyglądają one na doklejone albo przybite gwoździem. Język który był na początku źle zaprojektowany nie może nagle stać się dobry. Poza tym PHP jest niekompatybilny między wersjami. Jest ekstremalnie powolny, synchroniczny i jednocześnie jednowątkowy. Gdyby PHP był dobry to nie używał byś NodeJS bo czegoś nie da się w nim zrobić.
Domknięcia, obiekty, krótki zapis, rachunek lambda, asynchroniczność i metaprogramowanie były w JS od samego początku.

Lepiej wymyślił byś coś ciekawego zamiast po raz kolejny odkrywać od nowa koło.

Następna dyskusja:

Node.js czy Apache/PHP




Wyślij zaproszenie do