redirect_to HTTP POST

[taryn]

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

any ideas?

Taryn

[Pat Allan]

My instinct was that HTTP Redirects have to be GETs... but going by
the RFC, it seems that's not the case:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3

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.

Sorry I couldn't be more of a help.

--
Pat

[taryn]

On Apr 24, 12:42 pm, Pat Allan <p...@freelancing-gods.com> wrote:
> Sorry I couldn't be more of a help.

thanks

at least you've confirmed that I haven't missed something bleedingly
obvious to everybody but me ;)

I'll keep hunting!

Cheers,
Taryn

[Matt Palmer]

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

[Andrew Snow]

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.

- Andrew

[taryn]

<much snippage>

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.

> Good luck. You'll need it.

Thanks ;)

[taryn]

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?

That makes quite a bit of sense too!

Cheers and thanks,
Taryn

[taryn]

I've put my referer-solution on my blogpost:
http://rubyglasses.blogspot.com/2008/04/redirectto-post.html

Cheers,
Taryn

[Ben Browning]

I've posted an example of simulating the POST redirect server-side by
here:
http://last10percent.com/2008/05/26/post-redirects-in-rails/