i love the new Customizer
approach but they dont declare checked exceptions. (Yes, I know Spring itself has Throwing*
variants...) and so when i want to use things like the new authorizationServer() DSL method, it requires a try / catch block.
my $0.02 is that its a config DSL. either fix the DSL so we can't configure ourselves into an invalid state OR report the error at startup time along with everything else. but the way it is, we have to deal with the error at design time AND wait till runtime to figure out what went wrong. only to then have to re-do the DSL, since there's no logical step we could take to compensate for the error. its simply an invalid config.
@Bean
Customizer<HttpSecurity> securityCustomizer() {
return httpSecurity -> {
try {
httpSecurity
.oauth2AuthorizationServer(x -> x.oidc(Customizer.withDefaults()))
.webAuthn(x -> x
.allowedOrigins("http://localhost:9090")
.rpId("localhost")
.rpName("bootiful")
)
.oneTimeTokenLogin(ott -> ott.tokenGenerationSuccessHandler(
new OneTimeTokenGenerationSuccessHandler() {
@Override
public void handle(HttpServletRequest request,
HttpServletResponse response,
OneTimeToken oneTimeToken) throws IOException, ServletException {
}
}
));
} catch (Exception e) {
throw new RuntimeException(e);
}
};
}
Comment From: jzheaux
@joshlong you make a good point here that I think is worth discussing.
In the meantime, are you able to use ThrowingCustomizer
? (This might be the Throwing
variant you were referring to, just checking):
@Bean
ThrowingCustomizer<HttpSecurity> securityCustomizer() {
return httpSecurity -> {
httpSecurity
.oauth2AuthorizationServer(x -> x.oidc(Customizer.withDefaults()))
.webAuthn(x -> x
.allowedOrigins("http://localhost:9090")
.rpId("localhost")
.rpName("bootiful")
)
.oneTimeTokenLogin(ott -> ott.tokenGenerationSuccessHandler(
new OneTimeTokenGenerationSuccessHandler() {
@Override
public void handle(HttpServletRequest request,
HttpServletResponse response,
OneTimeToken oneTimeToken) throws IOException, ServletException {
}
}
));
};
}
Comment From: rwinch
Thank you for your feedback @joshlong and for chiming in @jzheaux
Indeed ThrowingCustomizer
is a good workaround for scenarios where an Exception
is thrown, but I agree with the ticket that we shouldn't be throwing checked Exception
s in this case to begin with. I've pushed a fix out that should resolve it.