Hey all,
So we're using acts_as_authenticated, and redirecting to the url they
asked for once they log back into a timed-out account.
The problem is that redirect_to doesn't seem to preserve the HTTP
method. This is ok for the faked-up methods eg using "_method=delete"
But if the URL a person asked for was a POST it fails miserably with a
routing error (eg:
no route found to match "/user/42/orders/23/clone" with
{:method=>:get}
These sorts of URLs are usually kept inside a button_to.
if the user, say, has their orders page open for a while, and comes
back after lunch and clicks "clone me order number 23", and s
redirected to the login page, when returning it spews as per above
error message rather than actually redirecting.
I've been trying to hunt around inside the code to find some way of
passing in the http method, but have so far come up blank. I've also
tried passing in the method via the "_method" parameter - but it
doesn't work, even for the delete/put buttons (I have a "delete order"
button, and it redirects to the show page for the order).
Putting some basic printf debugging into store_location shows that the
request method has been accurately populated with post/put/delete...
but I can't find a magic combination to actually pass that into
redirect_to... becuase it only seems to accept a uri (without request
headers).
The statement "The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD." implies that it can be something other than GET or HEAD.
As to how to structure a POST Redirect (if it's practically possible as opposed to theoretically possible), I've no idea - haven't found any clues from my googling.
> Hey all, > So we're using acts_as_authenticated, and redirecting to the url they > asked for once they log back into a timed-out account.
> The problem is that redirect_to doesn't seem to preserve the HTTP > method. This is ok for the faked-up methods eg using "_method=delete" > But if the URL a person asked for was a POST it fails miserably with a > routing error (eg: > no route found to match "/user/42/orders/23/clone" with > {:method=>:get}
> These sorts of URLs are usually kept inside a button_to. > if the user, say, has their orders page open for a while, and comes > back after lunch and clicks "clone me order number 23", and s > redirected to the login page, when returning it spews as per above > error message rather than actually redirecting.
> I've been trying to hunt around inside the code to find some way of > passing in the http method, but have so far come up blank. I've also > tried passing in the method via the "_method" parameter - but it > doesn't work, even for the delete/put buttons (I have a "delete order" > button, and it redirects to the show page for the order).
> Putting some basic printf debugging into store_location shows that the > request method has been accurately populated with post/put/delete... > but I can't find a magic combination to actually pass that into > redirect_to... becuase it only seems to accept a uri (without request > headers).
On Wed, Apr 23, 2008 at 06:53:33PM -0700, taryn wrote: > So we're using acts_as_authenticated, and redirecting to the url they > asked for once they log back into a timed-out account.
> The problem is that redirect_to doesn't seem to preserve the HTTP > method. This is ok for the faked-up methods eg using "_method=delete" > But if the URL a person asked for was a POST it fails miserably with a > routing error (eg: > no route found to match "/user/42/orders/23/clone" with > {:method=>:get}
> These sorts of URLs are usually kept inside a button_to. > if the user, say, has their orders page open for a while, and comes > back after lunch and clicks "clone me order number 23", and s > redirected to the login page, when returning it spews as per above > error message rather than actually redirecting.
> I've been trying to hunt around inside the code to find some way of > passing in the http method, but have so far come up blank. I've also > tried passing in the method via the "_method" parameter - but it > doesn't work, even for the delete/put buttons (I have a "delete order" > button, and it redirects to the show page for the order).
> Putting some basic printf debugging into store_location shows that the > request method has been accurately populated with post/put/delete... > but I can't find a magic combination to actually pass that into > redirect_to... becuase it only seems to accept a uri (without request > headers).
> any ideas?
Augh, the horror and nightmares of this... I was working on an app that had much the same problem, although in our case it was getting users to authenticate themselves initially as they performed an action for the first time that needed authentication.
The short answer to this is: you're boned. You can't redirect to a non-GET request (theoretical possibilities hinted at in RFCs notwithstanding -- kinda like trying to get a browser to make a non-GET/POST request without JavaScript).
Now, workarounds. I came up with a few. They all sucked.
* Store the request method/parameters/etc in the session when doing the login thingy, and attempt to re-inject the request into the system when you're done. The plumbing in Rails to make this work properly was just too hairy, and I gave up.
* Store the request method/parameters/etc in the session when doing the login thingy, and call out to an appropriate worker method when you're done logging in. This seemed feasible at first (since there were a limited number of non-GET places people could hit and need to re-auth) but DRY and future expansion killed this one, and quite rightly so.
* Make sure that authentication checks for non-GET actions is done via JS first, and do the auth via AJAX. This one almost kinda-sorta worked for us, although the HTTP/HTTPS shenanigans to make sure passwords weren't sent in the clear nearly killed me. (I've got a blog post on that floating around somewhere). Since the site I was working on was utterly useless without JavaScript, I could get away with it; if your site should be gracefully degradable, this is a non-starter.
* Re-architect the application to not need authentication on non-GET requests. This is, depressingly enough, what we had to resort to in the end, since the JS solution turned out to suck in some way I don't recall now. I suspect that this might not be such a winner for you, given the use case you've described, but you might have to resign yourself to the fact...
One insanely-irritating-but-nonetheless-possibly-feasible solution I've come across recently is a JS-based pop-up that arrives out of nowhere when your login has timed out, informing you that you've timed out and need to login again. You can then login in that popup, and then it goes away -- so you're re-authenticated by the time you press that 'delete' button. This falls foul of popup blockers and needs JS as well, but in certain situations I can imagine it might be the least-worst option.
Good luck. You'll need it.
- Matt
-- That's why I love VoIP. You don't get people phoning up to complain that the network is down. -- Peter Corlett, in the Monastery
Browser redirections are fussy and only absolute URLs with the GET method are supported.
Generally speaking a POST is something nice to reconfirm, so perhaps in the case of a POST, the login screen should store the referrer URL rather than the intended/clicked URL.
That way, after login the user will go back to the screen they were initially at and they can click the POST button again.
Wow, thanks - these seem to be most of the options I'd started
researching, with a few others thrown in to boot! Thank you for
sharing all your results - it's certainly cut down a lot of the time
I'd otherwise have taken trying to reinvent these broken wheels ;)
> * Re-architect the application to not need authentication on non-GET
> requests. This is, depressingly enough, what we had to resort to in the
> end, since the JS solution turned out to suck in some way I don't recall
> now. I suspect that this might not be such a winner for you, given the
> use case you've described, but you might have to resign yourself to the
> fact...
Ya - looks like it might be the easiest option. My current cop-out is
to just flash them a "sorry, please re-post" error after a redirect
back to their homepage. :P
Nasty, but better than the current route-failure nastiness and easier
to maintain than any of the other options.
On Apr 24, 3:33 pm, Andrew Snow <and...@modulus.org> wrote:
> Browser redirections are fussy and only absolute URLs with the GET
> method are supported.
Ya - the possible alternatives really don't get much in the way of
attention in the HTTP spec (which I've been poring over for way too
long now). The message seems pretty clear that this is not the way it
was intended to work :P
Which is a bit annoying - as it'd be nice in such cases as moved-
resources to be able to tell the browser to try again but over Here
instead :P
> Generally speaking a POST is something nice to reconfirm, so perhaps in
> the case of a POST, the login screen should store the referrer URL
> rather than the intended/clicked URL.
That's a good point, you don't want a user to click a delete on an old
screen... I guess I'm more worried about somebody that's half-filled
in a screenful of form and, for some weird reason leaves the room for
a while. when they get back to the screen and click submit... they
then lose that time spent. :(
I like the idea of svaing the data in the login screen - but am a bit
owrried about that being a security risk... can't think exactly how
it'd be for the moment - but it feels like a safety code-smell - feel
free to show me I'm wrong, if I am. ;)
> That way, after login the user will go back to the screen they were
> initially at and they can click the POST button again.
Hmm, so basically, store the referrer, rather than the request if the
request was non-get?
|
