marc schipperheyn (Migrated from SEC-1468) said:
AFAIK it is currently not really easy to override the default-target-url. Sure, if you try to access a protected resource, after login, the application passes you to the requested page. But if you need to login just to get session info (imagine an AJAX scenario where certain functions can only work after getting a user session based on login), it is less easy. Of course you don't want users to return to the homepage. You can write a custom filter to prevent this, but why not make this a no-brainer? It is, after all, a very, very common use case.
By allowing users to add a spring security specific form variable with a targetUrl life would be much simpler.
When Spring Security encounters this value in the login form, it will take this value in stead of the configured default target url.
And life is simple again. Now, on to writing that filter for my current application.
marc schipperheyn said:
Ok, during implementation I ran into a little variable called "spring-security-redirect" which does as desired. However, I could not find documentation on it. So I guess this JIRA item can be considered a documentation task. It would be a nice one for the main documentation TOC.
Luke Taylor said:
The destination is entirely customizable through the use of an injected strategy, as explained in the section "Application Flow on Authentication Success and Failure" in the reference manual. This directs the user to the Javadoc for the strategy classes. You'll find the default logic explained in AbstractAuthenticationTargetUrlRequestHandler, which includes the option of using a parameter containing the destination. I guess we could be more explicit about the default name of the parameter, but I think it's reasonable to expect that people should combine reading the manual with consulting the Javadoc for more details when directed to.
I disagree. The manual should provide sufficient insight into the important use cases.
People tend to review javadoc when things don't go as expected or are unclear. In my case, I wrote a custom filter, fucked around with the configuration getting it to work, which means you really have to get into it. etc. 2,5 hours gone. I reviewed javadoc but, right or wrong, I didn't come across this. Google was also strangely quiet. The point is: a small paragraph in the manual can save a developer hours of work. Multiply this by all the users of spring security. It's a lot of hours saved for a 5 minute paragraph.
Cool, we disagree :). I don't think using a parameter as a login destination warrants special mention as a use case. Users have lots of different ways in which they want to determine the login destination, hence the use of an injected strategy. The section I mentioned above says explicitly "The destination following a successful authentication or an authentication failure is controlled by the AuthenticationSuccessHandler and AuthenticationFailureHandler strategy interfaces, respectively.", and then "Some standard implementations are supplied such as SimpleUrlAuthenticationSuccessHandler, SavedRequestAwareAuthenticationSuccessHandler, SimpleUrlAuthenticationFailureHandler and ExceptionMappingAuthenticationFailureHandler. Have a look at the Javadoc for these classes to see how they work." If people then choose not to look at the Javadoc to see what functionality is available then that's up to them.
This section should also probably be referenced from the namespace chapter, since custom strategies can also be injected via the form-login element, which would be more likely to lead users to that point in the docs before they go down another route. I've updated that chapter, added the default class information to the namespace appendix and added another mention of the parameter names to the Javadocfor the strategy class which implements that particular logic.
Batbayar Bazarragchaa said:
Where can I get the updated reference manual?