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 > > >
