Shiro
  1. Shiro
  2. SHIRO-22

Enable POST redirects on session timeout

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      When a user is filling out a form for a long time and they don't submit (POST) within the session timeout limit they lose the newly entered data because after logging in they are redirected via GET to the target URI. This feature would enable redirecting a POST as a POST and therefore after successfully logging back in the user would see the result of their initial action.

      See email thread here: http://jsecurity.markmail.org/search/JSecurity+Saving+POST+data%3F?page=1

      Summary:
      The solution might work like this:

      since we have control over the Request/Response pair, we could do something snazzy where, if the SavedRequest in the session is a POST request, we can manually construct a Request object indicating a POST method and send that into the filter chain directly instead of the originating GET Request given to us by the Servlet container.

      So, in essence, a GET would be redirected as a GET, and a POST would be redirected as a POST. It would work in a REST scenario because the SavedRequest is stored in the session.

      But this again assumes that this is even desirable (POST redirect). We could make it configurable I suppose (enablePostRedirects = true/false) in the JSecurityFilter configuration if someone didn't like that idea.

        Issue Links

          Activity

          Hide
          Maria Jurcovicova added a comment -

          Redirect of POST request with all parameters is different than redirect of GET request. Status code can be used to redirect GET request because all parameters are part of url. The same thing is not possible with POST request, the parameters would be missing. Instead, the browser must be forced to recreate and resubmit similar post.

          The class PostRedirect will create and send html page with form that contains all original parameters:

          <form name="redirectform" id="redirectform" action="urlToRedirectTo" method="post">
          <input type="hidden" name="name_1" value="value_1">"
          <input type="hidden" name="name_2" value="value_2">"
          ...
          <input type="hidden" name="name_n" value="value_n">"
          <//form>

          And javascript to submit the form on page load:

          <script language="javaScript">
          function redirectpage ()

          { document.redirectform.submit(); }

          window.onload = redirectpage();
          <//script>

          CAREFULL: unless good sanitizer is used, generated HTML is vulnerable to an injection (SQL, XSS, ...) attack. Sanitizer must be supplied in constructor. As the post request redirect is dangerous, the feature is turned off by default.

          AuthenticationFilter Changes:
          What happens after successful login is delegated to an implementation of SuccessfulLoginStrategy interface. By default, RedirectOnlyGetStrategy is used. It calls WebUtils.redirectToSavedRequest.

          To redirect post request, user have to implement sanitizer and extend PostRedirectStrategy class:
          public class MyPostRedirectStrategy extends PostRedirectStrategy {

          @override
          public Sanitizer getSanitizer()

          { //create and return sanizer; }

          }

          PostRedirectStrategy calls PostRedirect class to perform actual redirect. It has to be enabled in configuration file:
          [main]
          redirect=org.someorg.someproject.somepackage.MyPostRedirectStrategy

          filter=org.apache.shiro.web.filter.authc.FormAuthenticationFilter
          filter.successfullLoginAction=$redirect

          [urls]
          /login.jsp = filter
          ...
          /** = filter

          Note: the method mentioned in other bug (https://issues.apache.org/jira/browse/SHIRO-132) would require major changes in filter and could break existing application (as far as I know).

          Show
          Maria Jurcovicova added a comment - Redirect of POST request with all parameters is different than redirect of GET request. Status code can be used to redirect GET request because all parameters are part of url. The same thing is not possible with POST request, the parameters would be missing. Instead, the browser must be forced to recreate and resubmit similar post. The class PostRedirect will create and send html page with form that contains all original parameters: <form name="redirectform" id="redirectform" action="urlToRedirectTo" method="post"> <input type="hidden" name="name_1" value="value_1">" <input type="hidden" name="name_2" value="value_2">" ... <input type="hidden" name="name_n" value="value_n">" <//form> And javascript to submit the form on page load: <script language="javaScript"> function redirectpage () { document.redirectform.submit(); } window.onload = redirectpage(); <//script> CAREFULL: unless good sanitizer is used, generated HTML is vulnerable to an injection (SQL, XSS, ...) attack. Sanitizer must be supplied in constructor. As the post request redirect is dangerous, the feature is turned off by default. AuthenticationFilter Changes: What happens after successful login is delegated to an implementation of SuccessfulLoginStrategy interface. By default, RedirectOnlyGetStrategy is used. It calls WebUtils.redirectToSavedRequest. To redirect post request, user have to implement sanitizer and extend PostRedirectStrategy class: public class MyPostRedirectStrategy extends PostRedirectStrategy { @override public Sanitizer getSanitizer() { //create and return sanizer; } } PostRedirectStrategy calls PostRedirect class to perform actual redirect. It has to be enabled in configuration file: [main] redirect=org.someorg.someproject.somepackage.MyPostRedirectStrategy filter=org.apache.shiro.web.filter.authc.FormAuthenticationFilter filter.successfullLoginAction=$redirect [urls] /login.jsp = filter ... /** = filter Note: the method mentioned in other bug ( https://issues.apache.org/jira/browse/SHIRO-132 ) would require major changes in filter and could break existing application (as far as I know).

            People

            • Assignee:
              Unassigned
              Reporter:
              Jesse O'Neill-Oine
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development