Spring Security
  1. Spring Security
  2. SEC-1468

Allow default-target-url override through form variable

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 3.1.0.M1
    • Component/s: Core
    • Labels:
      None

      Description

      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.

      <input type="hidden" name="j_default_target_url" value="http://xyz/something/">

      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.

        Activity

        Hide
        marc schipperheyn added a comment -

        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.

        Show
        marc schipperheyn added a comment - 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.
        Hide
        Luke Taylor added a comment -

        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.

        Show
        Luke Taylor added a comment - 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.
        Hide
        marc schipperheyn added a comment -

        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.

        Show
        marc schipperheyn added a comment - 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.
        Hide
        Luke Taylor added a comment -

        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.

        Show
        Luke Taylor added a comment - 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.
        Hide
        Batbayar Bazarragchaa added a comment -

        Where can I get the updated reference manual?

        Show
        Batbayar Bazarragchaa added a comment - Where can I get the updated reference manual?

          People

          • Assignee:
            Luke Taylor
            Reporter:
            marc schipperheyn
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: