I like the idea of supporting it, but think it should be
configurable. What if I'm in the middle of a wizard that depends on
session data? I don't think auto-resubmitting POST data is a good
idea. But if we have a flag that can be enabled with the appropriate
warnings, this could be useful to some folks.
Jeremy
On Jan 13, 2009, at 1:10 PM, Les Hazlewood wrote:
No, it wouldn't quite work like that. Its not usually a nice thing
to have POST parameters encoded as GET parameters, visible to the
end-user ;) Plus you're right, REST isn't so nice about that.
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.
In any event, if this is something that someone wants, please open a
Jira issue, otherwise we won't spend time on it ;)
Cheers,
Les
On Tue, Jan 13, 2009 at 12:51 PM, Peter Ledbrook <[email protected]
> wrote:
> If you'd like JSecurity to support this, please open a Jira issue
> (https://issues.apache.org/jira/browse/JSEC). It wouldn't be hard
to
> implement - we'd just have to add some state/behavior to the
SavedRequest
> object and the class that uses it for redirect.
So the POST would become a GET after the redirect? If so, I don't
think that's a great idea, and sure doesn't work with REST interfaces
:) That's the main reason the plugin doesn't do it.
Cheers,
Peter
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
