On Tue, 30 Dec 2008, David Ihnen wrote: > > in the meantime server 556 dublin suffered a network > connector air gap issue. A trouble ticket has been > created. These things happen. > > client -> GET <success bounceback url> -> load balancer -> > server 22 london -> looks up saved requestbody !!! > > This is the problem point. Your framework would be > depending on the request body save retrieve functionality > to be operational on all servers that might serve the > bounceback url request. Regardless of whether they're > even in the same physical proximity or data realm. They > must somehow share a backstored saved state, or depend on > the server that saved the state being available when it > needs it.
Yes. Normally any server application that depends on persistent session data would have to depend on consistently sharing that session data. This authentication method would require the application to implement persistent shared session data by hooking up Apache2::Controller::Session somehow. This uses some variant of Apache::Session. The man page for "Session" says "tie" is too slow for web apps? Do I help anything by tying first and giving you a clone of the hash, then only saving the clone back to the tied hash after the response phase is done? I'm doing this for apps that would require users to register and associate an openid_url with an account username on the local app. That requires some sort of server storage anyway. If any OpenID server will do, and unique users aren't required to register, other modules are available. > Here's a thought. what if you fully handled the post as > it came in - a short-time reprieve from having to do the > redirect - if you already know they WERE authenticated, > just accept their slightly expired ID, handle the form > submit appropriately, and then redirect when you're done. > Have the bounceback go to the proper result page. It > amounts to tri-state session, 'good', 're-auth', and > 'defunct'. Sort of defeats the purpose of session timeout, or how I think most people would think about that... but you could get this behavior by setting an infinite timeout. > I was seriously thinking you were in a situation where you > honestly could not tell - maybe you set the cookie with an > expiration date, and its gone, its not being sent, you > have no idea who this request is coming from. Its > different if you know. If you do know they are(were) > authenticated, not receiving the request is just being > stubborn and inflexible, isn't it? Well yes, but that's the point of saving it while they re-authenticate ... session timeouts are usually used to make sure people can't come up to an idle computer and fill out some form with bogus stuff. > > PUT to get redispatched to a GET request for an HTML > > login form. > > Heh, you have a point there. I'd be more interested in > getting an error response telling me that something had to > be done than in getting willy-nilly redirects that violate > the communication protocol established. if I'm doing some > kind of RPC, redirect to html is definitely unexpected. I guess Apache2::AuthenOpenID could be subclassed to spit out something other than html in set_custom_response(). Well, the same is true for my implementation, since it internally redispatches relative uri's or redirects absolute url's... in that kind of application it can send you to controller subroutines for 'login', 'register' etc. that spit out something meaningful to the client. So I don't think this is a big issue now that I think about it. Apache2::Controller:Auth::OpenID doesn't require you to spit out a web form. If you wrote an AJAX application and used A2C to implement the back-end, then your front end would get the browser code source from an un-authenticated url, and would control submission of credentials in whatever way you wanted - you have control over front and back ends so you can do it whichever way you want. > > Hrmm, if I passed the token as a separate cookie would > > that be an extra layer of security to "prove" they owned > > the session id? Not sure about this stuff. > > Prove they own the session ID? > > It took me awhile to figure out what you are suggesting. > > I assume this arises because you have a session key that rather than having > the > inherent session data in it, is a sequence number that could be mangled by an > end > user to try and step into an alternative session they don't own. > > Easy to fix that. Brief recipe. Make cookie value with a > simple signature. ... So as long as you make it > reasonable difficult to mangle their cookies, They have > your token. You've got to accept that they are who you > you authenticated that token for. Awesome, thanks for explaining that, thanks for the tips. I will try to implement that checksum recipe in Apache2::Controller::Session regardless of whether they're using OpenID. Mark
