With a configuration that includes CSRF protection (even customized), LogoutConfigurer assumes that /logout will only match POST requests (code in question here as of the time of this writing). That's not a problem in general, but if /logout has been configured to NOT match CSRF protection, it causes confusion and violates the principal of least surprise.

For example, with a custom CsrfConfigurer like csrf.ignoringRequestMatchers("/logout"); it's very likely that the developer intends to allow GET requests for /logout (what other reason would there be for ignoring /logout in CSRF?). That was certainly my expectation in configuring it that way.

However the logic in LogoutConfigurer.createLogoutRequestMatcher(H) requires POST if any CsrfConfigurer is present, ignoring the fact that CSRF is ignored for /logout.

private RequestMatcher createLogoutRequestMatcher(H http) {
    RequestMatcher post = createLogoutRequestMatcher("POST");
    if (http.getConfigurer(CsrfConfigurer.class) != null) {
        return post;
    }
    ...
}

The workaround is to specify a request matcher for the LogoutConfigurer, but that's not obvious (I spent a couple of hours debugging through the Spring Security code to find what was happening and where it came from - a situation made more painful by the fact that you have to know which log categories to set to TRACE to get any info about why /logout isn't "available").

I'm not sure if this is considered a bug or if it was an intentional choice (and thus an enhancement request), but either way it seems like it would be easy to adjust the logic to look in the CSRF config to see if /logout (or whatever the configured logout URL is) is ignored and, if so, allow other HTTP methods for it. Alternatively, add something to the Logout DSL to make it simple to accomplish.

Comment From: sjohnr

Hi @erizzo, thanks for reaching out! I'm sorry you had issues and had to spend time figuring this out.

The workaround is to specify a request matcher for the LogoutConfigurer, but that's not obvious

Perhaps there are improvements to be made in the documentation. However, this is mentioned very clearly in the reference docs for CSRF protection under CSRF Considerations > Logging Out.

I'm not sure if this is considered a bug or if it was an intentional choice (and thus an enhancement request), but either way it seems like it would be easy to adjust the logic to look in the CSRF config to see if /logout (or whatever the configured logout URL is) is ignored and, if so, allow other HTTP methods for it.

I feel this is intentional and not a bug. Further, I don't see your enhancement request being viable because using string values specified in one configurer to automatically provide conditional configuration in another configurer is a somewhat brittle way to do this, and I feel it leads to far more surprises and a harder time for users to understand what's going on. Therefore, I don't think we should consider this proposal.

Alternatively, add something to the Logout DSL to make it simple to accomplish.

What do you have in mind? I think it best to consider what you feel would make it easier first before suggesting something.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: eric-creekside

Sorry, I moved on from my Spring Security configurations (it was almost 2 months since I posted the question) and then was away on vacation. I'll re-familiarize myself with the context and respond soon.