Actual Behavior
GET request to /logout produces generic error and 404 status.
Expected Behavior
There could be more clear error message and 405 status code returned instead.
Configuration
Default WebSecurityConfiguration with CSRF enabled.
Version
5.1.4
Comment From: rwinch
Since this is a breaking change, we should consider this for 6.0.x or close the issue
Comment From: jzheaux
When the default logout page is not in use, but all defaults are otherwise in place, LogoutFilter will only capture POST /logout, passing the responsibility to the servlet layer for servicing the request.
This is a very common pattern in Spring Security. Each filter that represents an endpoint only captures the requests that it can service and not the ones that it can't.
I like @zeratul021's idea of supporting HTTP semantics, but there are some tradeoffs.
If the LogoutFilter default changes to capture requests it cannot handle (e.g. GET /logout so it can return a 405), it will be trickier for applications to handle those requests themselves. It's quite reasonable, for example, to do the following for GET /logout:
@GetMapping("/logout")
public String showLogoutPage() {
return "logout";
}
to render a logout page. This pattern is also nice because it allows Spring MVC to handle the 405.
If the above pattern is common, I don't think we want to increase its complexity.
On the other hand, if it's uncommon, then there may be some value in adding details to MatchResult indicating why a match failed. For example, the MatchResult could contain an error or status code.
This extra information could be of potential use to LogoutFilter to deliver the requested experience.
In the event an application wants to handle non-POST /logout requests themselves, it can still use Spring MVC as above, but it would also need to define a custom request matcher that doesn't return that extra error information.
I'll reach out to the team for feedback before proceeding either way.
Comment From: jzheaux
@rwinch added offline that Spring Security handles GET /logout by default in another filter, adding additional complexity. That seems to tip the scales into the "common" category.
As such, I recommend leaving things as they are.
You can configure your application to return a 405 using Spring MVC like so:
@RequestMapping("/logout")
ResponseEntity logoutNotAllowed() {
return new ResponseEntity(HttpStatus.METHOD_NOT_ALLOWED);
}