Witam wszystkich !
Musiałem w pracy dostać token z headerów, znalazłem tylko podejście, opisane poniżej. Czy istnieje ładniejszy sposób na pobieranie tokena? Bo w tym przypadku jest trochę za duża komenda, która wykonuje 1 zadanie
((ServletRequestAttributes) Objects.requireNonNull(RequestContextHolder.getRequestAttributes()))
.getRequest()
.getHeader("Authorization");
o_O No ja bym w kontrolerze dodał argument @AuthenticationPrincipal Jwt principal i Spring Security sam ci wrzuci ten token, albo od biedy jak koniecznie chcesz goły header to dodajesz do metody kontrolera argument @RequestHeader(value = "Authorization", required = false) String authorization i też ci go tam wrzuci.
Tutaj: https://github.com/Pharisaeus/almost-s3/blob/master/server/src/main/java/net/forprogrammers/almosts3/server/api/DownloadController.java#L30 masz metodę kontrolera która akurat robi obie rzeczy na raz, bierze principala i jeszcze do tego bierze jakiś header
Zamknij to w metodzie i tyle:
Java 
Spring 
Spring Boot public class RequestUtils {
public static final String NO_AUTHORIZATION = "NO_AUTHORIZATION";
public static String getAuthorization() {
return Optional.ofNullable(RequestContextHolder.getRequestAttributes())
.map(e -> (ServletRequestAttributes) e)
.map(ServletRequestAttributes::getRequest)
.map(e -> e.getHeader("Authorization"))
.filter(Objects::nonNull)
.orElse(NO_AUTHORIZATION);
}
}
Trudno powiedzieć co ty dokładnie chcesz osiągnąć, ale często jednak robi się globalny konfig Spring Security który np. wpuszcza na niektóre endpointy ludzi z odpowiednią rolą, wtedy nie trzeba się bawić w żadne ręczne wyciągnie tokenów ani principali. To ma sens głównie kiedy chcesz coś więcej z tym robić.
Mi się bardziej podoba rozwiązanie @wartek01, z tego względu że jest mniej zależne od framework'u. W przypadku zmiany przekazywania headerów czy po prostu autoryzacji lub przy całkowiwym wywaleniu Springa, wystarczy przeorać jeden serwis / utila a nie kilkaset kontrolerów. Dodatkowo pewnie nie da się sensownie bez frameworka z którego pochodzą te adnotację tego przetestować - a taki serwis można w zwykłym unit'cie.
przy całkowiwym wywaleniu Springa czy ktokolwiek kiedykolwiek w historii w realnym, dużym projekcie zdecydował się na to mityczne całkowite wywalenie Springa?
mniej zależne od framework'u.
@pedegie: Co? xD A myślisz ze ten RequestContextHolder to co jest? Nie mówiąc już o tym że header o którym mowa czyli Authorization to się raczej nagle nie zmieni bo to standard od wielu lat.
Szansa że ten kod wyżej przestanie działać jest wysoka, bo są tam rzutowania na pewne wewnętrzne szczegóły implementacyjne.
Shalom napisał(a):
mniej zależne od framework'u.
@pedegie: Co? xD A myślisz ze ten
RequestContextHolderto co jest?
mniej zależne != niezależne
Nie mówiąc już o tym że header o którym mowa czyli Authorization to się raczej nagle nie
zmienibo to standard od wielu lat.
Jeszcze dwie migrację (Spring -> cos innego) temu bym się zgodził, nie chodzi o standard header'a ale o wywalenie frameworka / zmiana sposobu autoryzacji, np nie ma nic wspólnego z HTTP a my zostaliśmy z 300 adnotacjami @Header("Authorization")
Szansa że ten kod wyżej przestanie działać jest wysoka, bo są tam rzutowania na pewne wewnętrzne szczegóły implementacyjne.
Ofc, rzutowanie jest do poprawy, miałem na myśli samo podejście a nie szczegóły implementacyjne.
a my zostaliśmy z 300 adnotacjami @Header("Authorization")
Dlatego sugerowałem dać sobie tam Principala, którego dostarczy nam konfiguracja Spring Security. Zmiana sposobu autoryzacji będzie wtedy tylko i wyłącznie w konfiguracji security :)
wywalenie frameworka
To i tak trzeba będzie od nowa napisać te mapowania i kontrolery
Władyslaw ParchomenkoShalom