[
https://issues.apache.org/jira/browse/KI-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Cabrera moved JSEC-44 to KI-17:
------------------------------------
Fix Version/s: (was: 1.0)
Component/s: (was: Session Management)
Affects Version/s: (was: 1.0)
Key: KI-17 (was: JSEC-44)
Project: Ki (was: JSecurity)
> Enable POST redirects on session timeout
> ----------------------------------------
>
> Key: KI-17
> URL: https://issues.apache.org/jira/browse/KI-17
> Project: Ki
> Issue Type: New Feature
> Reporter: Jesse O'Neill-Oine
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
