[wybacz]

chcialem sobie poczytac jak stworzyc prosty mechanizm autoryzacji/autentykacji dla mojej apki SPA i po 2 godzinach wertowania neta - o ja #!$%@?!

nigdy nie widzialem takiego rozgardiaszu i mnogosci opinii xD jeden drugiego przekrzykuje czy lepsze JWT czy sesje, czy trzymac dane w ciasteczkach czy w local storage

w sumie beka ze to jeden z najwazniejszych aspektow tworzenia apek i nie wiadomo jak to robic

takie tam #zalesie - gdybym byl nowicjuszem to pewnie bym sie zalamal, ale lecimy dalej :D

moze #programista15k ma cos do dodania w tej kwestii?

#programowanie

[yhbgrobdoivbvwamsv]

@wybacz: Witamy w świecie webowym.
Świecie stworzonym do robinia stron o kotkach na którym ludzie upieraja sie robic skomplikowane aplikacje mimo ze mamy dużo lepsze środowisko do robienia aplikacji które nazywa się system operacyjny xD

[WypadlemZKajaka]

nie wiadomo jak to robic

@wybacz: Ty nie wiesz jak to robić, to raz, a dwa dobierasz technologię do wymagań biznesu.

[wybacz]

@WypadlemZKajaka:

Ty nie wiesz jak to robić, to raz

no ja nie, internet tymbardziej :D

a dwa dobierasz technologię do wymagań biznesu.

co to ma do tematu

[WypadlemZKajaka]

co to ma do tematu

@wybacz: to, że autentykacja/autoryzacja nie w każdym projekcie wygląda tak samo, jest masa czynników, które wpływają na to, którą technologię się wybiera.

[S.....i]

@wybacz: jak masz SPA to masz API, zapewne REST - ktory jest stateless, wiec jakie sesje? odpowiedz jest prosta, JWT bo nie trzeba tego storowac na BE a to jak bedziesz trzymac sesje dla FE, to juz inna para kaloszy, ciastka nie maja tu racji bytu...

[wiesiu2]

@wybacz: w jakiej technologii to piszesz?

[wybacz]

@wiesiu2:

node, react

[uzytkownik_wykop_pl]

@wybacz Jest kilka rozwiązań, dobierasz je do potrzeb/projektu. #!$%@? które jest lepsze to mogą robić ludzie po bootcampie.

[wybacz]

@uzytkownik_wykop_pl:

Jest kilka rozwiązań, dobierasz je do potrzeb/projektu

no to napisalem jaka mam potrzebe: prosty mechanizm autoryzacji/autentykacji dla mojej apki SPA

[Parmenides69]

@Szubrawski: JWT może być stateless i stateful, jedno i drugie ma swoje zalety i wady. Chociażby przy stateless nie zrobisz token invalidation dla pojedynczego usera.
Nie do końca rozumiem co ma REST do sesji usera, chyba że mowa tu dokładniej o session cookie.

@wybacz: Przy logowaniu generujesz jakiś random string, zapisujesz go w pamięci (stałej np. w DB albo RAM, zależnie czy sesja ma żyć po ubiciu backendu) wiążąc z

[S.....i]

Nie do końca rozumiem co ma REST do sesji usera, chyba że mowa tu dokładniej o session cookie.

@Parmenides69: bo REST jest stateless, nie ma zadnej potrzeby zeby przechowywac jakichkolwiek danych ani dla BE ani dla FE, czy to w JWT czy w cookie a sesje dla FE, OP niech sobie zrobi w local storage po bozemu...

[Parmenides69]

@Szubrawski: Bezstanowość REST-a nie ma nic do rzeczy ze stanem mieszanym FE-BE którym jest sesja usera, w jakiś sposób musi istnieć efektywny identyfikator do kogo dana instancja FE należy i jakie ma uprawnienia.
Już pomijam że najpierw mówisz:

nie ma zadnej potrzeby zeby przechowywac jakichkolwiek danych ani dla BE ani dla FE

A dalej:

OP niech sobie zrobi w local storage po bozemu...

Przecież tu wtedy local storage przechowuje stan, a

[S.....i]

ze stanem mieszanym FE-BE

@Parmenides69: poczytaj jednak o SPA i REST bo chyba cos ci sie miesza w stanie :)

Przecież tu wtedy local storage przechowuje stan, a raczej wersję frontendową ww. stanu bycia zalogowanym. Niekoniecznie ta wersja musi się zgadzać z tym co myśli BE

trzeci raz ci mowie, API RESTowe jest STATELESS, nie potrzebuje zadnych sesji, zadnych danych po za tokenem autoryzacyjnym na podstawie ktorego identyfikuje uzytkownika i jego

[Parmenides69]

@Szubrawski: Problem widzę jest taki że nie do końca rozumiesz że "sesja" to bardziej abstrakcyjne pojęcie i w momencie np. gdy uzyskując dane logowania BE po zwalidowaniu ich odsyła token to powstaje wtedy sesja.
Protokół nie ma tu nic do rzeczy, musi powstać powiązanie danego klienta FE z user'em na BE. Tym czymś jest token (+ ewentualnie dodatkowy stan na BE)

[S.....i]

dane logowania BE po zwalidowaniu ich odsyła token to powstaje wtedy sesja.

@Parmenides69: sesja powstaje w momencie wejscia uzytkownika na strone, jego autoryzacja i kolor skarpet nie ma nic do rzeczy, REST to nie protokol, protokolem RESTa jest HTTP a teraz do spania madralo bo, jutro musisz troche o tym poczytac :)

[Parmenides69]

REST to nie protokol, protokolem RESTa jest HTTP

@Szubrawski: Mowa tu o protokole komunikacji z BE, jest to w skrócie mówiąc protokół REST lub dla pedantów zbudowany na REST - jest zestaw ściśle określonych dozwolonych requestów oraz jak powinien wyglądać response do nich co stanowi protokół komunkacji z BE zbudowany na bazie REST

sesja powstaje w momencie wejscia uzytkownika na strone

Ale rozumiesz jeszcze raz że mówiłem w kontekście sesji użytkownika,

[S.....i]

protokół REST lub dla pedantów zbudowany na REST

@Parmenides69: Redefiniujesz pojecia pod swoja teze wlasnie dlatego, musze ci tlumaczyc te same rzeczy po kilka razy.

Ale rozumiesz jeszcze raz że mówiłem w kontekście sesji użytkownika, usera w logice biznesowej?

Ale rozumiesz ze poruszasz sie po jakiejs abstrakcji w ktorej sam sobie definiujesz pojecia byle udowodnic prawdziwosc swojej tezy?

Jeżeli wyklepie zapytanie cURL-em w terminalu do jakiegoś /login to znaczy że nie

[WhatElseToSay]

Tak totalnie z boku waszej dyskusji. W kontekście SPA istnieje taki pattern jak BFF( Backend for Frontend). Wtedy uwierzytelniając się to ten backend tworzy sesje w której może przechowywać twoj token JWT i sam BFF działa jako proxy, walisz do niego requesty, on wzbogaca je o JWT czy nawet jakiś inny mechanizm i przesyła request do docelowego backendu.

[wybacz]

@Szubrawski:

to jak bedziesz trzymac sesje dla FE, to juz inna para kaloszy, ciastka nie maja tu racji bytu...

no dobra, to gdzie chcesz trzymac tokeny? w localStorage?

[S.....i]

@wybacz: moze byc local storage ale lepiej session storage :)