HttpStatusServerAccessDeniedHandler doesn't work as intended

[edeandrea]

Summary

I'm trying to convert my current servlet-based application over to reactive and it seems some of the Spring Security support for the reactive stack isn't yet complete.

1. The API documentation (class-method level documentation) seems to be missing in lots of places (ServerHttpSecurity and all its nested classes/methods, SecurityWebFilterChain, HttpStatusServerAccessDeniedHandler, plus there are probably others that I haven't yet come across)
2. HttpStatusServerAccessDeniedHandler in particular the documentation is not complete. It also reads in an HttpStatus to set, but then the handle method never uses it. Line 41 shows response.setStatusCode(HttpStatus.FORBIDDEN);

Expected Behavior

I would expect that whatever HttpStatus I construct the HttpStatusServerAccessDeniedHandler with would be the status code on the outgoing response.

Version

5.0.3.RELEASE

[rwinch]

Thanks for the report. I pushed a fix for the HttpStatus to master and 5.0.x. We have an on going issue to clean up Javadoc in the reactive bits. If you have specific classes that you need prioritized please create a separate issue for that

[edeandrea]

Thanks @rwinch

One thing I've noticed is it seems on the reactive side lots of the basic building-blocks that are there on the servlet side are missing.

Things like

• Alternate implementations of ServerLogoutSuccessHandler (like HttpStatusReturningLogoutSuccessHandler)
• Alternate implementations of ServerAuthenticationEntryPoint (like HttpStatusEntryPoint or Http403ForbiddenEntryPoint)
• Cookie-based implementation of ServerCsrfTokenRepository (like CookieCsrfTokenRepository with the ability to set the domain on the cookie)

Is this by design? Are these kinds of things not-needed in a reactive environment?

[rwinch]

@edeandrea Thanks for the report. We know that there is still a lot to do on the reactive side. It was impossible to replicate all of the code within the servlet world (which was nearly 15 years of work) within a single release. Please create tickets for specific things you would like to see and we will prioritize it. Please avoid a long list if items, but instead create individual tickets.

[edeandrea]

Great thanks @rwinch . I just wasn't sure if this was by design or because of what you just mentioned - that it just hasn't yet caught up.

I'll submit additional tickets.

[edeandrea]

I opened #5081, #5082, & #5083.

[rwinch]

Thanks @edeandrea! Any chance you would be willing to submit PRs for any of those tickets?

[edeandrea]

I would totally be open to it as I'm going to have to build them myself anyways (I've already built the cookie csrf token repository, but will have to check with my company's legal team to see if thats ok (I work for a big & old company.... :( )

[rwinch]

@edeandrea Thanks for looking into it! Let me know either way. If you can do it, that would be a great help. If you cannot do it I will be sure to prioritize it myself

[edeandrea]

I got approval from my company's legal team to contribute - I added PR 5245 for #5083