On Mon, 29 Dec 2008, David Ihnen wrote: > > Say the application's session times out, but the user > > posts something by clicking submit. > > > > They are redirected to the OpenID server but it says > > they are still logged in and returns a positive > > response. > > But you can't know that they are authenticated without > redirecting them, because you dropped the session data > that held that information. > > I think the obvious answer here is to keep the session > data around as long as the authentication is valid for. > Or keep this piece of state in a cookie so that it doesn't > vanish when your server decides to drop session state.
I'm not sure I understand what you mean here David. They don't get redirected for every request to the server. The session data keeps a timestamp. They stay logged in (and do not need to redirect thru the OpenID server) as long as the timestamp is current. The whole point is to keep the session current with an abstract tracking mechanism (the default mechanism in the framework is a session ID cookie.) But if they time out, and click submit, but the independent OpenID server says they're still logged in, or they re-auth automatically with the server (e.g. VeriSign Seatbelt Firefox plugin), then it should act as if they never timed out, i.e. when they come back from the redirect cycle, it should continue to submit whatever they clicked. On Mon, 29 Dec 2008, Adam Prime wrote: > From what I understand, as soon as you try to use the body > of a request using Apache2::Request, it reads it all in. > Which might play havoc with the idea of using a Filter to > modify a request / inject a body to replay an old post > request. Ah - yes I may have to go to using only the methods of the Apache2::RequestRec family to get at the 'openid_url' param. Then an input filter could rewrite the buckets before the Response phase controller instantiates the Apache2::Request. I'll try it and see. On Mon, 29 Dec 2008, André Warnier wrote: > Not to discourage you, but to point out some additional > aspects.. Thanks André these are very good points. I had considered a size limit option where you could say that the request body would not be preserved if it was over 2k or something. But even that leaves the system open to DoS attacks unless the application developer runs some very active cleanup script. So I think the best plan is to preserve the request body only if they already have an authenticated session and the session timed out. Good to know about other methods and not being able to use cookies with Windows etc. But the session tracking mechanism in Apache2::Controller is abstracted, so a non-cookie mechanism could be used instead, like an output filter that rewrites links with a session id query argument, or something. Probably still would not work with DAV, but it's the general idea. > And as long as we are talking Windows (and since at least > 90% of corporations still use IE and Windows > authentication internally), what if one of your customers > insists that to authenticate external users, OpenID is OK, > but for internal users they would really like you to use > the integrated Windows authentication (NTLM), since the > user is already authenticated in the Domain anyway. NTLM > authentication would play havoc with your scheme, because > it already itself relies on a multi-step exchange between > browser and server. In this case I might create an internal OpenID server that interfaced to our Windows NTLM. :-) Or, I'd stack an NTLM auth handler above the OpenID handler, so if NTLM succeeds, then the session timestamp is updated, and the OpenID handler says OK without checking anything. The point of Apache2::Controller is to abstract different facets into stackable, subclassable object-oriented handlers and then dispatch into a nice MVC-style controller subroutine, but without all the overhead of something like Catalyst. I dislike Catalyst's plugin architecture. Why do I need a plugin layer above everything else on CPAN? I just want to use something and do it and get it done. Why do I need a model abstraction layer? I just want to use a DBIx::Class schema or maybe sometimes I want to feed straight out of DBI - the point is I don't want the framework to get in your way. Mark
