React + Sesje w Spring Security

0

Cześć,
Tworzę aplikację webową w springu, raczej standardowy CRUD i zastanawiam się w jaki sensowny sposób połączyć Reacta z sesjami w spring security. Mam standardowy endpoint który rejestruje User'a, oraz endpoint od logowania. Przy logowaniu tworzy się sesja, która pozwala wchodzić na zabezpieczone endpointy - czyli między requestami przesyła session id w cookies'ach. Czy macie może jakieś dobre materiały/tutoriale by obsłużyć to rozwiązanie w React? Niestety google zasypane jest rozwiązaniami React + Spring Security + JWT, więc ciężko cokolwiek wysnuć.

Z góry dzięki za pomoc.

0

Jeżeli zabezpieczasz na bazie sesji to raczej nic specjalnego nie musisz robić, tj. mówisz serwer ustawia id sesji jako cookie.
Następnie do każdego requestu cookie z sesją jest dodawane. Jednak przy aplikacjach typu SPA preferowanym rozwiązaniem
jest jakiegoś rodzaju token np. JWT.

1

@lookacode1: Dlaczego przy SPA preferowany jest token zamiast ciastka?

0
Charles_Ray napisał(a):

@lookacode1: Dlaczego przy SPA preferowany jest token zamiast ciastka?

Raczej token zamiast sesji. Ciastko można wykorzystać jako mechanizm do storowania tokenu podobnie jak jest
z sesją. Tokeny JWT przechowują wszystkie niezbędne informacje i są podpisane kluczem przez serwer w związku z tym
serwer nie musi ich przechowywać a więc łatwiej skalować i mniej strzałów do bazy. W spring security sesja jest zapisywana
w pamięci / na dysku w zależności od kontenera więc średnio ze skalowalnością. W SPA backend jest odseparowany,
wydaje mi się, że łatwiej jest przechowywać podstawowe dane / kontekst użytkownika po stronie frontu np. w JWT niż
strzelać do jakichś endpointów, które jeszcze coś pobierają z sesji trochę to by było dziwne.
Co do cookie z API mogą korzystać jeszcze aplikacje mobilne, które średnio wspierają mechanizm cookie, bardziej bazują na tokenach.
Od sesji z tego co zaobserwowałem to już raczej się odchodzi na rzecz stateless, chyba, że ktoś ma / widział z Was jakieś ciekawe zastosowanie
gdzie sesja była niezbędna?

0

Zgoda, ale wg. mojej wiedzy od sesji (i ogólnie stanu) odchodzi się nie dlatego, że SPA tak ma, tylko właśnie ze względu na skalowalność backendu

0

Czyli według Was lepiej przerzucić się na JWT? Z tego co czytałem, JWT przydatne jest w przypadku komunikacji między aplikacjami (np webowa i mobilna), a w moim przypadku bedzie to zwykła SPA webowa.

0

Jak nie podasz jakie są wymagania co do tej apki, to niewiele pomożemy

0

Chcę mieć prostą rejestrację konta, logowanie przez maila/login - obojętne. Po takim zalogowaniu, chcę aby osoba mogła wchodzić na endpointy na które potrzebna jest autoryzacja - np endpoint dodawania komentarzy, edycji konta itp. Raczej standard jeśli chodzi o security. Dodatkowo chciałbym to zrobić z Reactem po stronie frontu

0

Chłopacy raczej pytają czy chcesz, żeby po prostu działało, czy moze chcesz sie czegos nauczyc. Czy bedzie to 1req/sec, czy moze jutro juz 10 000 req/sec.

1

Wystawianie JWT na świat jako mechanizm do obsługi sesji to moim (i nie tylko moim) zdaniem zły pomysł. Przykładowy post wyjaśniający problemy z używaniem JWT dla sesji jest tutaj: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

Argument z tym, że w JWT można zmieścić jakieś dane oprócz ID sesji jest słaby, bo te informacje można przechowywać po stronie serwera, upraszczając (np łatwiej modyfikować dane w Key-Value Store niż w zdalnym tokenie) i oszczędzając transfer między klientem, a serwerem. Skalowalność też łatwo ogarnąć po stronie serwera - to co trzymałbyś w JWT trzymaj w jakimś skalowalnym Key-Value Store np Redis (który ma opcję zapisu danych na dysk z niewielkim lagiem).

Pewną hybrydą klasycznych ciastek i JWT jest trzymanie JWT w ciastku. W tym rozwiązaniu mechanizm ciastek zapewnia bezpieczeństwo, a JWT standaryzuje format zapisu danych w ciastku. Jeśli takie coś jest wymuszone przez framework to można się ograniczyć do trzymania minimalnego zbioru danych w JWT, czyli przede wszystkim numeru sesji.

JWT są natomiast spoko na backendzie (np w komunikacji między mikroserwisami albo instancjami aplikacji w klastrze) jeżeli ich nigdzie nie przechowujemy tylko na bieżąco generujemy (podczas wysyłania żądania HTTP) i weryfikujemy (podczas obsługi żądania HTTP). Innymi słowy: wtedy gdy są jednorazowego użytku. Gdy mamy JWT wielorazowego użytku (access token, refresh token, cokolwiek) to pojawiają się problemy opisane w artykule, który podlinkowałem na początku posta.

0

To tak: apka raczej nie będzie przyjmowała 10k req/sec, bliżej do 1req/sec. Co do chęci nauczenia się czegoś to tak, oczywiście chciałbym przy tym się czegoś nauczyć.
@Wibowit tak, czytałem ten temat i wiem, że wypychanie JWT na obsługę sesji to nie jest zbyt dobry pomysł. Czyli do obsługi sesji postawić Redis'a, który byłby moim cache na sesje userów? Ogólnie chciałem to rozwiązać jak najprościej, a przy okazji optymalnie i poprawnie. Do takich sesji w Redisie mógłbym użyć ewentualnie Spring Session Redis, ale najbardziej problematyczne jest obsłużenie tego po stronie frontu, z uwagi na to że w SPA i ogólnie frontendzie jestem dość zielony.

0

Skoro już są gotowce do Spring Session + Redis (a znalazłem coś takiego w Guglu) to powinno być dość prosto. Piszesz prostą apkę, wiec mniemam iż do mechanizmu zabezpieczeń nie masz jakichś niestandardowych wymagań.

Wybór rozwiązań po stronie serwera nie powinien mieć wpływu na rozwiązania po stronie klienta o ile protokół jest ciągle taki sam. Protokół w akcji możesz sobie podejrzeć odpalając konsolę programisty w przeglądarce i sprawdzając w zakładce sieć jakie dane lecą po kablu / socketach. Sam niewiele poradzę, bo o ile pisałem w Reactu to jednak tylko hobbystycznie, a lekko już przestarzały framework (Scalowy LiftWeb) na którym jest oparta dotychczasowa wersja naszej apki biznesowej używa klasycznych stanowych sesji.

0

Jeśli jesteś zielony we frontendzie, to polecam https://spring.io/guides/tutorials/spring-security-and-angular-js/ Wybór technologii na froncie, jak i storagu do sesji, to sprawa drugorzędna.

1 użytkowników online, w tym zalogowanych: 0, gości: 1