[lukasj]

Siema mirki programiści! ( ͡° ͜ʖ ͡°)

Chciałbym się trochę podszkolić w pewnej rzeczy - aby zacząć robić bardziej modułowe aplikacje, a nie monolity. Zacząłbym od backendu. Czytałem trochę o architekturze mikroserwisów - wydaje się to ciekawę. Mógłbym np rozdzielić hipotetyczną aplikację dajmy na to - na 4 mniejsze serwisy: autoryzacja userów, produkty, zamówienia, płatności. I kilka pytań:

1) Jak wygląda sprawa autoryzacji? Np do mikroserwisu wysyłam żadanie z nazwą usera i hasłem - wtedy "loguje" mnie do aplikacji, ale dalej jak się komunikować? Do tej pory robiłem tak, że nadawany był unikalny token UUID i miałem abstrakcyjny kontroler w Javie z którego dziedziczyłem, który sprawdzał sobie zawsze w bazie danych, czy token jest poprawny i nie wygasł - minusem było oczywiście to, że trzeba było się odwoływać do bazy danych co chwila.

Słyszałem o tokenach JWT - jednak odradzają je jako mechanizm takiej "sesji". Więc w sumie po co ich używać? Tak to przekazałbym w nim dane typu: userID, username, userPermissions, expTime itd - wtedy wiem jakie user ma ID, jaką nazwę (gdyby było to potrzebne), jakie uprawnienia i kiedy token JWT wygasa. Jednak skoro odradzane są jako mechanizm sesji, to nie widzę chyba sensu w ich użyciu?

Mógłbym zamiast JWT wrócić do tego rozwiązania o którym pisałem - generuje sobie UUID w jakimś kontrolerze podczas logowania, i za każdym razem z innych serwisów odpytuje serwis autoryzacji sprawdzając poprawność tokena UUID. Tutaj można zastosować np cache, żeby zapamiętywało taki token na na przykład 5-10 minut - taka poprawa wydajności.

2. Skoro już jestesmy przy autoryzacji - w jaki sposób autoryzować zapytania między serwisami? Przesyłać jakiś nagłówek z kluczem? Czy może jakiś inny mechanizm, który dawałby radę? Może szyfrowanie RSA lub AES?

A może autoryzować je tokenem użytkownika? Czyli skoro serwis zamówień musi pobrać info z serwisu produktów, to może po prostu wysyłać token, który otrzymwał serwis zamówień od usera? I nim autoryzować zapytanie do serwisu produktów?

3. Gdzie mogę znaleźć jakieś materiały by coś sie nauczyć na temat budowy takich aplikacji które są mikroserwisami i jak to wszystko połączyć? Jakieś słowa kluczowe? Najlepiej Python, Java, a ostatecznie może być nawet PHP.

#programista15k #java #python #php #mikroserwisy #programowanie #webdev #serwery

[MirRAFal]

2. Nie autoryzować, mikroserwisy gadają ze sobą w zamkniętej sieci, utworzonej np. na poziomie dockera, dostęp z zewnątrz jest odcięty.

1. User z UI prawdopodobnie nie będzie uderzał do poszczególnych serwisów samodzielnie a bardziej przez API gateway, wtedy mając na API gateway listę endpointow możesz zapiąc autoryzację w jednym miejscu

[lukasj]

@MirRAFal: 1. wiem o tym api gateway - czyli po prostu autoryzować to w api gateway? I odrzucać zapytania gdy nie ma autoryzacji? Czyli ogólnie serwis autoryzacji + api gateway mógłby być najlepiej jednym serwisem?

2. W sumie fakt. Chociaż na sieciach się nie znam, to zapewne dałoby się zrobić taką sieć między różnymi VPS-ami? Tylko co wtedy z szyfrowaniem?

Tak BTW: Czego lepiej używam w pythonie? Flash czy Django? Bo

[LaylaTichy]

@lukasj: dosc ciekawy wpis: https://netflixtechblog.com/edge-authentication-and-token-agnostic-identity-propagation-514e47e0b602

Słyszałem o tokenach JWT - jednak odradzają je jako mechanizm takiej "sesji"

gdzie odradzają? zdecydowana wiekszosc obecnie stoi na jwt bym powiedzial

[lukasj]

@LaylaTichy: czyli jeżeli byłaby jakaś autoryzacja do takich serwisów, to po prostu w tokenie JWT przesyłać dane: ID usera, jego nazwe, uprawnienia i date wygasniecia tokena. I wtedy taki mikroserwis ufa temu, jakby był zalogowany użytkownik o ID 1 i nie sprawdza tego nigdzie? W sensie, że np w JWT są dane, że jest to user o ID 1 - i wtedy mikroserwis operuje na danych użytkownika o ID 1, gdyż

[zibizz1]

@lukasj tak

[lukasj]

@LaylaTichy: @MirRAFal w sumie tak sobie teraz myślę - z dockera nigdy nie korzystałem, ale przy tej okazji może warto byłoby się tego nauczyć? Do tej pory jak coś stawiałem na VPS to zazwyczaj: apt install apache, apt install tomcat itd - i w ten sposób stawiałem aplikacje.

[blacktyg3r]

@lukasj: Dla prostych projektów FastAPI, dla bardziej rozbudowanych ninja-django (FastAPI + Django).

Myślę że odpowiedzi na pytania dostaniesz w dokumentacji tych 2 projektów, jeśli znasz Pythona to będzie raczej przyjemna nauka :).

[bmLq]

Mógłbym zamiast JWT wrócić do tego rozwiązania o którym pisałem - generuje sobie UUID w jakimś kontrolerze podczas logowania, i za każdym razem z innych serwisów odpytuje serwis autoryzacji sprawdzając poprawność tokena UUID. Tutaj można zastosować np cache, żeby zapamiętywało taki token na na przykład 5-10 minut - taka poprawa wydajności.

Właśnie tak korzysta się z JWT w mikroserwisach.

2. Użył bym tego z czego łatwiej się korzysta twój framework pewnie ma

[LuckyLuke_2776]

@lukasj:

1: Błędnym założeniem, jest robienie logowania i "wysyłanie żadania z nazwą usera i hasłem" do SSO, bo w takim układzie masz logowanie i po stronie aplikacji i SSO. gdy anonimowy user ląduje w aplikacji >> przekierowujesz go do sso wraz z przekazaniem adresu aplikacji, czyli na jaki ma zostać przekierowany spowrotem >> tam następuje logowanie z formularza podpisanego tokenem csrf >> po poprawnym logowaniu user zostaje przekierowany spowrotem do aplikacji

[lukasj]

@LuckyLuke_2776: @bmLq @bmLq @blacktyg3r @zibizz1 super, dzięki wielkie za odpowiedzi ( ͡° ͜ʖ ͡°)

Ogólnie to myslałem o mikroserwisach żeby rozdzielać projekt na mniejsze podprojekty. Np o ile dane o produktach lepiej mi trzymać w bazie relacyjnej, o tyle dla zamówień mógłby też być mysql, jednak tutaj lepiej spisałoby się trzymanie tego w JSON, więc albo pola JSON w bazie mysql xD albo jakaś baza no-sql.

[lukasj]

1: Błędnym założeniem, jest robienie logowania i "wysyłanie żadania z nazwą usera i hasłem" do SSO, bo w takim układzie masz logowanie i po stronie aplikacji i SSO. gdy anonimowy user ląduje w aplikacji >> przekierowujesz go do sso wraz z przekazaniem adresu aplikacji, czyli na jaki ma zostać przekierowany spowrotem >> tam następuje logowanie z formularza podpisanego tokenem csrf >> po poprawnym logowaniu user zostaje przekierowany spowrotem do aplikacji wraz z

[zibizz1]

@lukasj Mnie irytuje w pracy zbytnie komplikowanie wszystkiego niepotrzebnie, wrzucanie technologicznie rzeczy które nie są wcale wykorzystywane. Mikroserwisy też często są taką rzeczą. Warto czasem coś wyrzucić do osobnej aplikacji ale często jest to overengineering mocno. Co zwiększa jednie skomplikowanie i koszty a nie są wykorzystywane zalety podziału bo nie jest on potrzebny. Także trzeba wiedzieć jak to robić ale nie zawsze stosować.
plus taki że pracy więcej jest;)

[lukasj]

@zibizz1: no wlasnie też nie lubie niczego komplikowac, więc zastanawiam się co będzie prostsze. Jeden monolit czy 4 niezależne od siebie aplikacje w których będą różne dane. Tym bardziej, że na przykład aplikacje do zarządzania bazą produktową robię osobono i ona może mieć dane zapisywane w mysql, a druga aplikacja obsluguje zamówienia i zeby było to elastyczne, to np dane trzymane są w jakieś bazie no-sql (jeszcze nie wiem jakiej bo

[BreathDeath]

@lukasj: Ja robię to tak, ze mam api gateway, tam sprawdzam czy request z internetu jest poprawny. Używam do tego tokenów jwt. Jwt jest generowany i walidowany przez with service. Jak jest poprawny to wbijam sobie do nagłówka requestu id usera. Mikroserwisy między sobą rozmawiają bez autoryzacji. Mam network policy i izolowana sieć, wiec wiem, ze nic innego nie pójdzie bokiem. Do tego możesz zrobić tak, ze każdy request musi mieć

[zibizz1]

@lukasj firebase z firestore jest spoko jak chcesz coś zrobić szybko, przy dość małym ruchu jest też tanie. Zrobiłem jedna aplikacje na Fluter+Firebase z Firestore. I cały czas działa bez problemu, zero utrzymywania. Z 80% to bezpośrednie operacje na bazie prosto z klienta, reszta na cloud funkcjach w nodejs

[tylko_zerknalem]

no wlasnie też nie lubie niczego komplikowac, więc zastanawiam się co będzie prostsze. Jeden monolit czy 4 niezależne od siebie aplikacje w których będą różne dane.

@lukasj: Monolit będzie prostszy, pod warunkiem że będzie dobrze zmodularyzowany. Pojęcie którego szukasz to "modular monolith". Zamiast 4 mikroserwisów będziesz miał 4 moduły, które komunikują się za pomocą publicznego API każdego z nich (przy czym nie jest to komunikacja wymagająca sieci, a odbywająca się wewnątrz

[lukasj]

@tylko_zerknalem: ooo i to jest jakieś rozwiązanie, super, dzięki wielkie ( ͡° ͜ʖ ͡°)

PostgreSQL się bawiłem troche, ale lepiej znam MySQL. Jakie polecisz narzędzie do zarządzania PostgreSQL? Coś typu PHPMyAdmin?

[tylko_zerknalem]

@lukasj: Polecam DataGrip od JetBrains, przy czym on ma tylko 30-dniowy trial, a później jest płatny. Da się z niego korzystać bez płacenia, ale wtedy trzeba restartować aplikację co 30 minut. Z takich w pełni darmowych to wiele osób korzysta z DBeaver i chyba sobie chwalą.

[draxgar]

@lukasj:
Ad.1.
JWT jest szeroko wykorzystywany, ma jednak swoje wady. Protokół nie wymusza sprawdzenia integralności danych, zatem jak system jest kiepsko napisany, to wystarczy usunąć podpis i każdy może dowolnie zmienić treść komunikatu.
JWT ma też drugą bardzo istotną wadę: wystawca może go anulować/expirować i nikt o tym nie będzie wiedział. Przykład: admin wystawia JWT z wszelkimi prawami, odchodzi z firmy. Nie ma jak powiedzieć serwisom, że ten token nie jest

[draxgar]

@lukasj: Ad.2 mTLS, albo mTLS w połączeniu z JWT, ale jw.: za każdym razem taki token musi być walidowany u wystawcy. Inaczej może być expired/revoked i tego nie sprawdzisz po sygnaturze. Chyba że token ma kilka sekund życia i nie przeszkadza ci to. Wtedy wystarczy tylko sprawdzić integralność i nie przepuszczać JWT bez sygnatury.