Kolejny raz przekonuję się, że Spring Security to kombajn, w którym teoretycznie każdy komponent można podmienić, ale są tak ze sobą powiązane, że chcąc coś zrobić inaczej, trzeba przepisać połowę komponentów.
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ę
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ę
@MethodSource
zmieniając cykl życia testu adnotacją -@TestInstance(PER_CLASS)
.Możliwe, że twoją weryfikację da się zrealizować jeszcze łatwiej (bez bazy danych). Z
MockMvc
mogłoby to wyglądać w następujący sposób:mockMvc.perform(get(...).with(SecurityMockMvcRequestPostProcessors.user().roles(Role.ADMIN))
więc
@MethodSource
mógłby parametryzowaćRole
albo całyRequestPostProcessor
. Tutaj będzie zwykły SpringowyUser
ale tychRequestPostProcessor
jest sporo (są też związane z OAuth2).Jeżeli chcesz
WebTestClient
to tam to się nazywa