On Sun, 28 Dec 2008, André Warnier wrote:
> > > > 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().
No, that's not what I want. What if it's a PUT, or
something else? I want it to replace the body of the
authenticated request with the body of the request that was
saved from when they clicked but were not authenticated.
> 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 ?
Yeah, I don't want people to have to depend on Keep-Alive,
especially if it is running on a cluster or behind a load
balancer or something.
> 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.
It didn't seem to work correctly when I ran it as a
PerlAuthenHandler. I'll try that again though.
> To save in the meantime the original request, there are
> several possibilities
Yeah, the thing is that I want the mechanism to be agnostic
to the type of request. It doesn't have to depend on any
parseable parameters from a POST. I want it to replicate
the request body no matter what, for example, if the raw
request body is an XML entity being set with a PUT request,
the client should redirect through the auth server and
should not have to re-send the original request. "Magic."
So it's looking like this:
- user logs in, does stuff, goes to get coffee
- user comes back, clicks 'submit' on whatever form
- session is idle:
- reads and stores raw request body from bb's
- saves the method number
- redirects to openid server
- openid server redirects to GET return url
- original method number restored
- installs input filter to replace bb's with
contents of preserved request body
The question is, since the handler doing the preservation
and installing the input filter also instantiates an
Apache2::Request object, when it gets to the response phase
controller, will the response handler's Apache2::Request
instance read the replaced data or the cached data?
Sessions under the framework are required for the
authentication handler to work at all, so I just go ahead an
attach one anyway, prior to authentication. I guess this
might not be a good idea or would expose to DoS? Hrmm. I
don't really want to factor that out. I'll think about it.
Maybe the request body preservation should only happen by
default if they already had a session authenticated but only
timed out.
Mark
