Fred Moyer wrote:
On Sun, Dec 28, 2008 at 12:08 AM, Mark Hedges <hed...@scriptdolphin.org> wrote:
On Sat, 27 Dec 2008, Mark Hedges wrote:
Hi, I'm trying to figure out how to preserve the request
body across an OpenID login redirect cycle.
...
But when they come back from the OpenID server, how do I put
the saved request body or post params into the new request?
In Apache2::AuthCookie, the author uses a trick : convert your POST to a
GET see the sub convert_to_get().
In fact, this is a bit of a misnomer, because what is really happening
is a conversion from having the arguments (parameters?) in the body of
the request, to having them in the saved URL. (enctype = url-encoded
instead of multipart/form-data).
This method will work, up to a certain request parameter size I guess
(probably not for a file upload POST, and also not if the parameters
need any specific character-encoding).
I don't think that using $r->connection->pnotes is a very safe bet in
this case, because with Keep-Alive you never know when the maximum
number of requests for this connection will be be exhausted, or do you ?
Regarding the avoidance of the browser's own login popup dialog :
This dialog pops up when the server sends back a 401 response
(unauthorised), with a header indicating that it needs a Basic or Digest
authentication.
Thus, if you arrange for your authentication method to send back a login
page instead (with a 200 OK code), the browser will show your login
form, and not its own dialog.
To save in the meantime the original request, there are several
possibilities :
1) as a hidden input field in the login form that you send back. When
the user fills in his id and password, and submits the form back to the
server, the hidden parameter will be sent back also, and can be used to
do a redirect in case of a succesful authentication.
<form name="login"...>
<input name="wanted_url" type ="hidden"
value="/protected/what_he_first_wanted.html">
<input name="id" value="">
...
</form>
2) as a pnote to the connection, with the same caveat as before.
3) as the content of a cookie, set at the same time as sending the login
form (probably the easiest way).
4) server-side, in some kind of session-linked structure. The point
there is to know whether before the user is authenticated, you have/have
not yet created a session structure.
