Cześć,
załóżmy, że mam apke, monolit, taki standardowy - wszystko generowane po stronie serwera. Informacje o logowaniu użytkownika są przechowywane w sesji. Mam potrzebę dorzucenia do tego mikroserwisu do wykonywania pewnej czynności. Pytanie, jak podejść do kwestii autoryzacji i autentykacji użytkowników przy czymś takim? Mógłbym wydzielić teoretycznie kolejny serwis do uwierzytelniania userów, ale nie do końca wiem jak można by podejść do tej kwestii. Literatura w internetach mówi o generowaniu JWT i wysyłaniu tego z każdym requestem, ale nie mam pomysłu jak to wysyłać przy normalnych formach będących interfejsem użytkownika. Jakieś pomysły jak to ogarnąć? Pakować token do ciasteczka i czytać go w samej aplikacji czy jakieś inne rozwiązanie jest bardziej poprawne? Nie mam możliwości stworzenia żadnego SPA ani pełnego API.
Hej,
Do tematu można podejść na wiele sposobów. Najpopularniejszy z nich to oAuth lub właśnie JWT.
Z tego co zrozumiałem posiadasz monolityczny projekt w którym autoryzacja użytkownika opiera się o domyślną sesję.
Zmiana na JWT jest dosyć bolesna ponieważ zupełnie inaczej to działa, a odpowiadając na Twoje pytanie jak wysyłać token to po prostu w headers dodaje się "Authorization: Bearer JAKIS_KOD_JWT" a po stronie aplikacji sprawdza się jego poprawność itp.
Trochę mało "widzę" Twoja aplikację, ale kiedyś w przypadku takich monolitów tworzyło się serwer pośredniczący np. z memcache(d) w którym byłą zapisywana sesja użytkownika, a każdy serwis aplikacji łączył się ze wspólnym serwerem sesji dla PHP (tak można zmienić domyślne miejsce zapisywania sesji użytkownika).
Dzięki za odpowiedź @PinguVanEx.
Moim problemem jest tutaj właśnie dodanie do headera tego tokenu. Zastanawiam się jak to zrobić w poprawny sposób skoro formularze to zwykły wygenerowany html (jak mówiłem, aplikacja to typowy monolit, coś jak projekt symfony generujący template i serwujący gotowy kod html). Czy tutaj wrzucenie tego właśnie do ciastka i odczytywanie tego ciastka przy przetwarzaniu requestu przez "główną" aplikację będzie ok czy jakoś inaczej powinienem do tego podejść?
W załączniku bardzo okrojony schemat o co mi chodzi. Interesuje mnie jak przekazać token userowi w pkt 1, a potem go odczytać w pkt 2 skoro nie wysyłam requestów jak typowego api, a jak normalne formularze.
Jeszcze mi brakuje tylko informacji, kto komunikuje się z mikroserwisem, aplikacja monolityczna czy użytkownik poprzez request?
Jeżeli aplikacja monolityczna to możesz po prostu na tej warstwie przesyłać tokeny lub inne rozwiązanie, niezależnie od formularza użytkownika. Wystraczy wtedy przechwycić formularz w monolicie (można go też wstępnie sprawdzić) i przekazać go dalej do mikroserwisu np. curl-em dodając do nagłówka token i response z mikroserwisu przekazać użytkownikowi.
Natomiast jak chcesz generować formularz jak wspomniałeś na warstwie aplikacji głównej a odczytywać go w mikroserwisie to niestety trzeba odpowiednio zaprojektować całą aplikację (też da się to zrobić) i współdzielić sesje (tokeny JWT również przechowują informację np. o użytkowniku).
Hm czyli można by do tego podejść tak, że weryfikacja usera działa jak działała (sesja), a dopiero na etapie komunikacji z mikroserwisem ogarniać temat tokenu? Teoretycznie by to zrobiło robotę, a ja i tak mógłbym weryfikować "w czyim imieniu" monolit odpytuje serwis. Pytanie tylko na ile takie podejście jest "zgodne ze sztuką".
Sorry, że zadaję takie pytania, ale w sumie pierwszy raz trafiło mi się coś takiego i chcę zrobić to po prostu poprawnie :)
Dokładnie, jeżeli to jest wystarczające funkcjonalnie to lepiej komunikować się monolit -> mikroserwis. Taką komunikację można zabezpieczyć na wiele różnych sposobów bez potrzeby wykorzystywania tokenów JWT.
Odnośnie zgodności ze sztuką, to nie ma czegoś takiego :D Całą sztuka polega na odnalezieniu najlepszego i najlatwiejszego rozwiązania do danego problemu. Istnieją jedynie dobre praktyki które bardziej podpowiadają jak podzielić odpowiedzialność lub architekturę systemu.