[tapcZan-NW]

https://imgur.com/a/Jc8rr

Cześć! Pracuje nad aplikacja webowa (osobny front (angular) osobny back(springboot), komunikuja sie po REST-cie) i chcialbym zeby dostep do mojej aplikacji byl mozliwy tylko dla zalogowanych. Nie chce jednak robic osobnej rejestracji, chcialbym zeby uzytkownicy logowali sie swoim kontem z facebooka.

Mozliwe ze jeszcze nie do konca rozumiem jak dziala oauth, ale moim zdaniem w moim przypadku (jak na obrazku) wystepuja 3 strony:
- moje API, port 8080
- moj frontend na node.js, port 4200
- serwer autentykacji (facebook)

i teraz potrzebuje pomocy i porady, ktore z rozwiazan na obrazku jest prawidlowe? Ramka zielona czy ramka czerwona? Moze zadne? Widzieliscie moze gdzies tutoriale spring boot / angular + logowanie przez facebook?

#programowanie #angular #angularjs #angular2 #spring #springboot #java #facebookapi #naukaprogramowania

[adrianpawlik]

@tapcZan-NW: zielona ramka jest poprawna

[tapcZan-NW]

@adrianpawlik: dzieki!

[adrianpawlik]

W sumie, zeby to mialo rece i nogi to front powinien slac FB token do Backendu, ten powinien go weryfikowac - wiec odpytac FB o to - a nastepnie odeslac do frontu wlasny token. Zeby przy kazdej akcji nie odpytywac FB o weryfikacje. To tez oddziela Ci FB i inne O Authy od uwiwrzytelniania w API. Jak nagle bedziesz musial dodac standardowe logowanie przez haslo to lezysz. Co do tokenow zwracanych do

[tapcZan-NW]

@adrianpawlik: Wielkie dzieki!

https://raw.githubusercontent.com/iuliazidaru/springboot-angular-facebook-auth-demo/master/README-resources/AuthenticationWithFacebook.jpg

znalazlem taki przyklad na gicie, ktory chyba rozwiazuje problem (do backendu wysylany jest token), co o tym myslisz?

[ElTorino]

@adrianpawlik: @tapcZan-NW: Mam pytanko do JWT bo podobnie jak OP sklejam jakiegoś CRUDa. Jest sobie user zalogowany po JWT i wykonuje on sobie jakieś akcje, do których ma uprawnienia. A co jeśli nagle główny administrator zdecyduje, że tego użytkownika trzeba zablokować bo szkodzi? No to zmieniamy mu pole w encji 'blocked' na true. User dalej posługuje się tokenem i ma przecież wszystkie uprawnienia. Nie odpytujemy bazy, po to jest JWT.

[sokytsinolop]

@tapcZan-NW: może pomoże
https://github.com/cymruu/anonimoweproblemy/blob/master/admin.js#L26

[sokytsinolop]

@ElTorino: masz 2 wyjścia:
1. sprawdzać za każdym razie w bazie czy user jest 'blocked'
2. zapisywać tokeny i unieważniać je po zmianie w bazie interesującego pola

[robie_bota]

@tapcZan-NW: pisałem na priv, ale chyba masz zablokowany. Udostępniasz kod tej app gdzieś?

[Pesio]

@ElTorino: Jednym z wyjść jest zastosowanie JWT i refresh tokenów. JWT zapewniają dostęp do zasobów, są trzymane tylko po stronie użytkownika, ale mają krótki czas życia, powiedzmy 15 minut. Refresh tokeny mają długi czas życia (albo zupełnie go nie mają) i pozwalają na odświeżenie JWT, są trzymane przez użytkownika i na serwerze w jakiejś szybkiej bazie danych jak redis, nadawane tylko przy zalogowaniu. W requescie przesyła się JWT i refresh token,

[sokytsinolop]

@Pesio: Świetne wyjaśnione dzięki. No ale i tak wszystko sprowadza się do pobrania wartości z bazy danych więc w mniejszych projektach chyba rozwiązanie przekombinowane

[Pesio]

@sokytsinolop: W sumie tak, zaimplementowałem coś takiego w swoim side projekcie który robię gdzieś tam w tle i... wydaje mi się, że w takiej skali równie dobrze bym wyszedł na trzymaniu całych JWT w redisie bez refresh tokenów. No ale #scalability ᕙ(⇀‸↼‶)ᕗ

[saquas]

@adrianpawlik masz może gdzieś przykład tego rozwiązania?