Jak dostać token z headersów w inny sposób?

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:

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ć.

Osobiście polecałbym Ci jednak to co zapodał Shalom. Masz wtedy czarno na białym co sie skąd bierze. W Twoim sposobie używasz magicznych statyków wyciągających coś z thread localów, bleh.

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.

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 RequestContextHolder to 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 zmieni bo 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