There is no way to know if a custom logout success handler has been set

[heruan]

Expected Behavior

During HttpSecurity build process, a custom configurer might need to know if a custom logout success handler has been set for the LogoutConfigurer, for example:

class MyCustomDsl extends AbstractHttpConfigurer<MyCustomDsl, HttpSecurity> {

    @Override
    public void init(HttpSecurity http) throws Exception {
        var logout = http.getConfigurer(LogoutConfigurer.class);
        if (logout.isCustomLogoutSuccess()) { // <-- can't do this now
           // custom logout, preserve it
        } else {
           // no custom logout, customize it
        }
    }
}

would allow to preserve a custom handler set like this:

http.with(customDsl, withDefaults());
http.logout(logout -> logout.logoutSuccessHandler(customHandler));

Current Behavior

During the init phase of customDsl, it's not possible to know if logout.logoutSuccessHandler has ever been set, since:

• LogoutConfigurer does not set the custom handler as a shared object
• LogoutConfigurer#getLogoutSuccessHandler returns a new handler if not already set
• LogoutConfigurer#isCustomLogoutSuccess is not public

Context

This is affecting my custom handler's ability to set a logout success handler only if the user hasn't already set one. I couldn't find any alternative other than reflection, but I can't use reflection.

[jzheaux]

Thanks for reaching out, @heruan.

I wonder if you'd be able to set your configurer-specific settings before the application-specific settings.
In this way, I imagine you won't need to check if the application has something you don't want to override.

Have you already tried this approach, and if so, where is that proving difficult?
Can you tell me more about what determines the logout settings that your configurer sets so I can better see where I can help?

[heruan]

Thanks @jzheaux for the interest! How would I set my configurer-specific settings before the application-specific settings? The configurer will take action during the init lifecycle phase, that happens after the application might have customized logout already. For example:

http.with(customDsl, withDefaults());
http.logout(logout -> logout.logoutSuccessHandler(customHandler));

Even if the configurer is applied first, its init will happen after the custom logout handler is already set in the logout configurer.

[heruan]

To add more context: the scenario is the same as in #17011 where this custom configurer customizes other configurers during the init lifecycle phase. Such configurer does not have a chance to know if a custom logout success handler has already been set, since during initialization of the chain build process it's already too late.