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