Thanks I really do appreciate your comments. On Mon, 29 Dec 2008, David Ihnen wrote: > Yes, I am aware of how OpenID works. And it works in-band > unless the application explicitly sidelines it - there is > no inherent side-band communication that the client and > server will use - otherwise, you wouldn't EVER do a main > state redirect.
It does? That would be great. How? Why does the consumer object return a check url? Why does it have the return_to parameter? From Net::OpenID::Consumer: # now your app has to send them at their identity server's endpoint # to get redirected to either a positive assertion that they own # that identity, or where they need to go to login/setup trust/etc. my $check_url = $claimed_identity->check_url( return_to => "http://example.com/openid-check.app?yourarg=val";, trust_root => "http://example.com/";, ); # so you send the user off there, and then they come back to # openid-check.app, then you see what the identity server said; Is that module supposed to work some other way than with redirects? I thought the point was that they log into the OpenID server and bounce back to my app. That way they never have to trust my app with their password or other credentials. > The moment you have to redirect to that openid server > page, you have sidelined the entire stream of > browser-server communication - and as you have found in > the problem you're trying to solve - the state inherent > therein, including the content of the original request. > Is the utilization of the stored form data going to be > through a different connection/request entirely after > authentication verification? Would require some tests to > see if the client behaves that way or not. I suspect its > not defined to be one way or the other, but I may be > wrong. Not following you there. > Is the controller framework going to require me to depend > my web system operations on some sort of semi-persistent > pan-server correlated session state system? Would that > not be requiring me to implement my web application in a > particular way? Okay, that may indeed be the role of a > framework though I'd no doubt chafe at the limitations > myself. If I have to write my web application a certain > way, is it so unusual to have my pages need to interact > with that application a certain way? They're almost > inevitably closely coupled. That's a good point. But no, it doesn't depend on the session, you don't have to have a session attached to use the controller framework. You do have to have a session attached to use the OpenID layer. > This is a fairly sticky issue - if you have run out of > local authentication token, its impolite to drop data they > were submitting. But on the other hand, there's no > particularly good way of *not* dropping it - you can't > really handle information if they're not authenticated for > it. And out of pure defensive network traffic handling, > we do the absolute minimum for people who aren't > authenticated - so they can't consume our system > resources, be that posts-to-sessions-that-don't-exist or > what. That's true, that's why I think it will not try to preserve the request body unless they already were authenticated once and just timed out. I think that's useful. > I can see programming the client side of the web > application to handle this kind of token-loss-recovery > automatically - the client has the form state and being > able to recover the session state is valuable, and > entirely independent from the framework utilized. But I'm > not convinced that the web server should be jumping > through hoops/proxies to make it happen. (not that you > have to convince me, I'm trying to present a perspective > that may be novel and generally be helpful in improving > your software, and we may just disagree on the role of the > software involved) That's probably what DAV clients expect to do, and probably what an AJAX client would do too. After thinking about it, it's not clear that my conception of this module would be useful to an AJAX application or really any other automated type of code interface -- it would not make sense for an XML PUT to get redispatched to a GET request for an HTML login form. I think that in those cases you would have to configure it with absolute URL's so that redirects to login/register/openidserver are used, instead of internal redispatching to login/register. An asynchronous component would then have to watch for redirects and deal with it. For those types of cases, it would make more sense to use a real Authen handler than returned DECLINED if they were not logged in, something in the style of Apache2::AuthenOpenID. Incidentally that uses redirects too, I don't see how you get around "side band" communication with OpenID. Hrmm, looking at danjou's module I'm not sure if I'm doing the token checking correctly... but maybe that is effectively done by keeping the session id current. 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. Mark
