Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SEC-1468: Allow default-target-url override through form variable #1707

Closed
spring-projects-issues opened this issue Apr 25, 2010 · 5 comments
Labels
in: core An issue in spring-security-core type: enhancement A general enhancement type: jira An issue that was migrated from JIRA
Milestone

Comments

@spring-projects-issues
Copy link

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.

@spring-projects-issues
Copy link
Author

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.

@spring-projects-issues
Copy link
Author

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.

@spring-projects-issues
Copy link
Author

marc schipperheyn said:

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.

@spring-projects-issues
Copy link
Author

Luke Taylor said:

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.

@spring-projects-issues
Copy link
Author

Batbayar Bazarragchaa said:

Where can I get the updated reference manual?

@spring-projects-issues spring-projects-issues added in: core An issue in spring-security-core Closed type: enhancement A general enhancement type: jira An issue that was migrated from JIRA labels Feb 5, 2016
@spring-projects-issues spring-projects-issues added this to the 3.1.0.M1 milestone Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core An issue in spring-security-core type: enhancement A general enhancement type: jira An issue that was migrated from JIRA
Projects
None yet
Development

No branches or pull requests

1 participant