Aktywne Wpisy
![NoLife_](https://wykop.pl/cdn/c3397992/NoLife__BW1s6fEOIW,q60.jpg)
NoLife_ +616
#chwalesie #noworodek
Mirik i mirabelki pijcie ze mną kompot mamy nowego #niebieskipasek niestety mały miał problemy z oddychaniem i trafił na neonatologie trzymajcie kciuki żeby wszystko było dobrze
Mirik i mirabelki pijcie ze mną kompot mamy nowego #niebieskipasek niestety mały miał problemy z oddychaniem i trafił na neonatologie trzymajcie kciuki żeby wszystko było dobrze
![NoLife_ - #chwalesie #noworodek
Mirik i mirabelki pijcie ze mną kompot mamy nowego #...](https://wykop.pl/cdn/c3201142/bf612b00852d29a9d94c22ed65eae89ec553995115fe67a32cc7fae9c5a7b466,w150.jpg?author=NoLife_&auth=0fd8278937d2c28ff389cceab90a5901)
źródło: temp_file2837836265969218616
Pobierz![lukija](https://wykop.pl/cdn/c3397992/lukija_qWfi2GxuAS,q60.jpg)
lukija +13
pani asia robi najlepsze pazy
![lukija - pani asia robi najlepsze pazy](https://wykop.pl/cdn/c3201142/8d5acbe8cd2ed0db00c9a759c574b089261c80400d203f3ebeaeb3d1da9718b2,w150.jpg)
źródło: Zdjęcie z biblioteki
Pobierz
Udało mi się nieco okiełznać klienta OAuth2:
1. Tworząc filtr, który na podstawie nagłówka X-USER-ID utworzy obiekt Authentication - otóż SS nie akceptuje anonimowych klas Authentication ani jak przekażemy #!$%@? w formie ciągu znaków przy ręcznym utworzeniu OAuth2AuthorizeRequest.
2. Dostosowując aplikację do Redirect URI (niestety jest on weryfikowany w usłudze, z którą się łączę i nie mogę zmienić) - otóż SS weryfikuje go w OAuth2AuthorizationCodeGrantFilter i jeśli się nie zgadza, to zamiast strzelić po token, to od nowa przekierowuje do serwera uwierzytelniania. No i jak tu robić testy na różnych środowiskach, w których adres będzie się trochę różnił? No ostatecznie można nadpisać OAuth2AuthorizationCodeGrantFilter i wyrzucić weryfikację Redirect URI.
3. Jeśli stworzę filtr, który podmieni Redirect URI w zapisanym w sesji requeście, to błędny Redirect URI pójdzie w strzale po token i zwróci błąd.
4. Można też podmienić HttpSessionOAuth2AuthorizationRequestRepository, żeby requesty trzymał w bazie, a nie w sesji (bo co w przypadku wielu instancji aplikacji, które będą mieć osobne sesje?)
5. Żeby spring użył Authorization Code with PKCE, to trzeba usunąć z konfiguracji client-secret i ustawić client-authentication-method: NONE
6. Aby przechowywać tokeny w bazie, to jest o tym sekcja w dokumentacji, więc nie będzie z tym dużego problemu - a może będzie, bo nie używam relacyjnej bazy, lecz NoSQL - do sprawdzenia, czy zadziała z taką bazą (wymóg klienta)
Czyli tak w skrócie z czym mam problem:
1. Weryfikacja Redirect URI w SS - można to obejść jak wyżej
2. Aplikacja może mieć wiele instancji i jedna może przekierować użytkownika, a druga strzelać po token - patrz pkt 4 wyżej
Nie wiem, czy dalej w to brnąć, czy pisać własną implementację OAuth. Nie jest to trudne, ale trzeba ręcznie dbać też o odświeżanie tokenów. Zamiast filtrów SS miałbym konkretny endpoint, w którym zawarłbym logikę i przynajmniej bym wiedział, co się dzieje.
#spring #springsecurity #java #programowanie
1. jaki jest sens walidacji redirect URI?
2. nie wiem co do końca chcesz osiągnąć taką implementacją, ale chyba idziesz w aplikację stateful zamiast stateless
Szanuję za wytrwałość, ale obawiam się, że większość rzeczy, o których piszesz SS od wersji 5.0 rozwiązuje out-of-the-box
Po co trzymać requesty i tokeny w bazie? Nie korzystasz z profili z odpowiednią konfiguracją pod środowisko, a w ogóle to musisz wadlidować redirect?
Jaki jest Use Case tego customowego headera? Jeżeli chcesz mieć dwa flow uwierzytelnienia - jeden OAuthowy (np. code grant), a drugi na podstawie Headera to brzmi to jak potrzeba dwóch AuthenticationManager / AuthenticationProvider (jeden dla flow z headerem, drugi dla oauth).
Generalnie brzmi jakbyś strasznie kombinował. Opisz bardziej architekturę i potrzeby. Generalnie Spring wyciąga Redirect URI na podstawie properties, czyli możesz to ustawić zmiennymi środowiskowymi, więc różne Client/Resource Servery mogą integrować się z jednym Authorization Serverem, a powrót do "dobrego" środowiska (nie koniecznie instancji, bo sesje można wspołdzielić) ogarnąć ENVem
@whoru: Integruję się z zewnętrzną usługą i tam stoi serwer uwierzytelniania IdentityServer, który weryfikuje Redirect URL. Musi być w żądaniu dokładnie taki, jaki określił administrator. A obecnie jest zupełnie z czapy i ma być dopiero później zmieniony na