fix: configure 401 unauthorized response for endpoints

[platosha]

Fixes #924

[ZheSun88]

validation tests failed with Caused by: java.io.NotSerializableException: com.vaadin.flow.spring.security.VaadinWebSecurityConfigurerAdapter$Http401UnauthorizedAccessDeniedHandler

[haijian-vaadin]

seems it requires a page refresh after the fix? If so, since the InvalidSessionMiddleWare is mostly about redirecting to login view. Should we just refresh the page in the server-side AccessDeniedHandler? then InvalidSessionMiddleWare is no longer needed?

[platosha]

@haijian-vaadin the main concern in #924 is that InvalidSessionMiddleware was not invoked due to server response is a redirect instead of an expected 401. So the authentication expiration was hard to somehow address on the client side. Concerns both the session-based and stateless authentication.

Because with the session-based authentication Spring uses default session-based CSRF protection, when the session expires on the server we need to update the CSRF token on the client. In that case reloading the page is required, as it is currently the only way to obtain a fresh CSRF token.

Note that an anonymous session expires on the server, there will be invalid CSRF exceptions for anonymous endpoints too, which triggers InvalidSessionMiddleware. In that case prompting the user with the login screen is not appropriate, the user was not logged in previously, and the endpoint action does not require a login.

Should we just refresh the page in the server-side AccessDeniedHandler?

Redirect was the default behaviour of Spring Security before this change. But this does not fit endpoint requests: redirecting in AccessDeniedHandler for endpoint requests does not automatically refresh the page, but rather the endpoint client receives an unexpected HTML response which it cannot parse. The server is expected to respond with a JSON or an error here.

then InvalidSessionMiddleware is no longer needed?

I think it is still needed, or we need something else to cover a use case of handling expired CSRF and authentication on the client. Both sessions and JWT expire over time, so one API can cover both, I think. With stateless authentication, a non-reloading redirect on the client side to the login view should be a working way to deal with expired authentication, whereas with session-based CSRF you still have to reload the page.