Spring i security - ręczna alternatywa

Czy u kogoś z Was jest security w Springu robione "ręcznie"?

Standardowy sposób to zdefiniowanie beana gdzie ustawiany które ścieżki są publiczne, które są prywatne, które endpointy wymagają jakich roli no i kontekst wywołania jest ustawiany w SecurityContextHolder. Zauważyłem, że przez to potem często w projektach jest tak, że w testach integracyjnych są porobione jakieś patologiczne mocki i w sumie to security nie jest w ogóle testowane xd.

Czy nie lepiej po prostu tego security zrobić w ten sposób:

@DeleteMapping("/{id}")
ResponseEntity<?> deleteProduct(HttpServerRequest request, @PathVariable UUID id) {
    return securityService.onlyAdmin(request, ctx -> productService.delete(id, ctx));
}

Gdzie ten SecurityService bierze sobie po ludzku request, wycuąga token, waliduje, wyciąga claimsy/payload, sprawdza role i buduje kontekst wywołania. Zwykły prosty dekorator zamiast beana.. u kogoś tak się to robi? Ewentualnie jakie to ma wady? Bo ja nie widzę.

Jak dla mnie oczywistą wadą jest to, że jak chcę zaimplementować usuwanie produktu, to muszę pamiętać o użyciu jakiegoś securityService.

Zauważyłem, że ludzie w większości dzielą się na tych co wolą pochować logikę gdzieś w adnotacjach, thread localach i potem po prostu pisać ficzery i na takich co wolą od razu widzieć co się dzieje w czystym kodzie.

Ja wybieram opcję 2. Od zawsze irytuje mnie przekopywanie adnotacji, aopów itd.

Deserializację też robisz ręcznie, czy używasz Jacksona? :P

Ok, są wyjątki, ale raczej nikt nie mockuje potem serializacji, a już jakieś dziwne haki z beanami od security widzialem i potem było 3h analizy przez 3 devów dlaczego autoryzacja nie jest sprawdzana w testach integracyjnych i kolejne 2h jak ją włączyć, żeby nie wysypać reszty testów xd

Zauważyłem, że przez to potem często w projektach jest tak, że w testach integracyjnych są porobione jakieś patologiczne mocki i w sumie to security nie jest w ogóle testowane xd.

No to problem macie w gównianych testach a nie w tym jak jest zaimplementowane security. Zapraszam: https://github.com/Pharisaeus/almost-s3

Ewentualnie jakie to ma wady?

Verbosity i ryzyko że ktoś kiedyś zapomni? Masz teraz 700 miejsc w kodzie z takim powielonym fragmentem i może być cieżko ogarnać które endpointy jak są chronione i np. nie zrobisz sobie wygodnie jednolinijkowca w konfigu który mówi np. że POSTy może robić tlyko ktoś z rolą X a GETy z rolą Y

Poruszasz dwa tematy:

1. Security bez adnotacji i Spring Security
   Fajnie, że chcesz pisać bez adnotacji, ale wywal wtedy Spring i pisz w jakimś Javalin etc. Jak uważasz, że REST w Spring jest fajny to dlaczego nie Security? To tak jakbyś pojechał do Włoch i chciał zjeść dobry bigos.

2. Security rozproszone po aplikacji czy w jednym centralnym miejscu.
   Tutaj zgadzam się z Shalom, że lepiej mieć wszystkie reguły per zasób REST w jednym miejscu i w dodatku domyślnie wszystko wymagające najwyższego dostępu (np. admin), żeby nic przez zapomnienie nie stało się dostępne, bo ktoś zapomniał coś dodać.