Kenny MacLeod (Migrated from SEC-1153) said:
When it comes to form-based auth, the codebase has two different but similar mechanisms for redirecting to the login page.
On the one hand we have AuthenticationProcessingFilter, which uses RedirectUtils to redirect to the form following an unsuccessful attempt, and then we have AuthenticationProcessingFilterEntryPoint which has its own code for generating the redirect. They're similar, but do different things. For example, AuthenticationProcessingFilterEntryPoint always adds the context path to the redirect URL, and cannot be configured otherwise. RedirectUtils take account of cases where the context path should not be in the redirect URL.
I suggest that AuthenticationProcessingFilterEntryPoint be refactored to use Redirectutils to generate the URL and initiate the redirect.
Luke Taylor said:
SEC-1226 will introduce a general strategy for redirects which should also be used here. Closing as duplicate.
Note that there are configuration limitations on the use of the redirect strategy for the standard LoginUrlAuthenticationEntryPoint (formerly AuthenticationProcessingFilterEntryPoint). For example, if it is attempting to redirect to an HTTPS URL, and a context-relative redirect strategy is used, then you will lose the HTTPS part. If necessary the entry point code should be overridden or a custom strategy should be written to make sure you end up with URLs that make sense to your clients and which work the way you want.