Re: [grails-user] JSecurity Saving POST data?

[Peter Ledbrook <pe...@cacoethes.co.uk>]

> I'm using JSecurity and the Grails plugin for the first time on a new
> project and I'm running into an issue where my user is filling out a long
> form and is timing out.  When they hit the submit button, they get
> redirected to the login page, but once they log back in they have lost
> everything they did.  Is there a way to configure JSecurity so that it is
> able to save this request and then complete it once they log back in?  I
> have used Acegi in the past and it does this, so I was expecting it to "just
> work."
> Any help would be greatly appreciated!

Ah yes, that old chestnut. I believe there is an outstanding issue for
this. It's a non-trivial problem, and I'd be interested to know how
Spring Security does it. One approach is to return an HTML page
containing the POST data in a form with a little bit of javascript to
auto-submit that form. Another approach would be to invoke the
corresponding action directly, but I'm not sure there is a clean way
to do this. It may be easy to do now with the new "forward()" method
that has been added to Grails 1.1, but I haven't looked into it.

JSecurity itself may have a solution, in which case you could use the
native interceptors rather than the plugin's filter-based system.

Cheers,

Peter

Re: [grails-user] JSecurity Saving POST data?

[Jeremy Haile <jh...@fastmail.fm>]

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 <peter@cacoethes.co.uk 
> > 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
>
>
>

Re: [grails-user] JSecurity Saving POST data?

[Jesse O'Neill-Oine <je...@refactr.com>]

That sounds like pretty much exactly what I want.  I just need to make sure
that my user never loses data that they've entered into the form; even if
they've been on it so long that the session has timed out.  The ping
solution would also work and I may well have to cross that bridge anyway
down the road because some form of auto save is also in my future. :)
I've opened up a JIRA request here:
https://issues.apache.org/jira/browse/JSEC-44

I'm very interested to hear any downsides to this approach, because it seems
that if it can be done securely it would be a very nice feature to have
available.

Jesse

On Tue, Jan 13, 2009 at 12:10 PM, Les Hazlewood <lh...@apache.org>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 <pe...@cacoethes.co.uk>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
>>
>>
>>
>


-- 
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Jesse O'Neill-Oine // jesse@refactr.com
Refactr LLC // http://refactr.com
mobile // 612-670-5037
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Re: [grails-user] JSecurity Saving POST data?

[Les Hazlewood <lh...@apache.org>]

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 <pe...@cacoethes.co.uk>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
>
>
>

Re: [grails-user] JSecurity Saving POST data?

[Peter Ledbrook <pe...@cacoethes.co.uk>]

> 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

Re: [grails-user] JSecurity Saving POST data?

[Les Hazlewood <lh...@apache.org>]

The mechanism that redirects if not logged in is found in
AccessControlFilter (
http://svn.apache.org/repos/asf/incubator/jsecurity/trunk/web/src/org/jsecurity/web/filter/AccessControlFilter.java).
 All of JSecurity's filter classes that do this
save-request-then-redirect extend from this class.

The AccessControlFilter saveRequest method implementation first creates a
SavedRequest (
http://svn.apache.org/repos/asf/incubator/jsecurity/trunk/web/src/org/jsecurity/web/SavedRequest.java)
object representing the incoming request, and contains just enough
information to perform a redirect later.  It then saves this SavedRequest
object to the session.

After the user logs in successfully, a similar mechanism checks if there is
a SavedRequest.  If so, it uses that to redirect to the specified URL in the
saved request.

You can see in the SavedRequest source code (linked above) that it supports
only GET requests at the moment by acquiring request.getRequestURI() and
request.getQueryString().

We did this initially as it didn't seem like a good idea to redirect POSTs,
for fear of unexpected results, especially if that POST represented secure
user data or financial information.

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.

Until then, you can easily take any of our filters that extend
AccessControlFilter, and override the saveRequest method to do what you need
in the mean time.

Cheers,

Les


On Tue, Jan 13, 2009 at 11:56 AM, Peter Ledbrook <pe...@cacoethes.co.uk>wrote:

> > I'm using JSecurity and the Grails plugin for the first time on a new
> > project and I'm running into an issue where my user is filling out a long
> > form and is timing out.  When they hit the submit button, they get
> > redirected to the login page, but once they log back in they have lost
> > everything they did.  Is there a way to configure JSecurity so that it is
> > able to save this request and then complete it once they log back in?  I
> > have used Acegi in the past and it does this, so I was expecting it to
> "just
> > work."
> > Any help would be greatly appreciated!
>
> Ah yes, that old chestnut. I believe there is an outstanding issue for
> this. It's a non-trivial problem, and I'd be interested to know how
> Spring Security does it. One approach is to return an HTML page
> containing the POST data in a form with a little bit of javascript to
> auto-submit that form. Another approach would be to invoke the
> corresponding action directly, but I'm not sure there is a clean way
> to do this. It may be easy to do now with the new "forward()" method
> that has been added to Grails 1.1, but I haven't looked into it.
>
> JSecurity itself may have a solution, in which case you could use the
> native interceptors rather than the plugin's filter-based system.
>
> Cheers,
>
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>