On Wed, 31 Dec 2008, Foo JH wrote: > Mark Hedges wrote: > > http://search.cpan.org/~markle/Apache2-Controller-1.000.001/ > Very interesting. I have a controller which functions in a > slightly different way, but it's good to see alternative > approaches. I think yours makes life easier.
Thanks Foo! I've seen the idea implemented a number of ways, open source and not. Part of my point was proof of concept that a lot of the abstractions were useless hoops to jump through -- a lot of times people use references to other structures when they should subclass... these references function only to re-map arguments to other modules, which is ridiculous. On Tue, 30 Dec 2008, David Ihnen wrote: > Yes. But timtowdti on how that information is > distributed. In my opinion any *framework* must not > depend on the *application* having established a > persistent backstore of shared session data, so that it > can persist put/posts. You're *significantly* > constraining the parameters of the implementations > utilizing the framework by requiring this, which I > consider to be exactly what frameworks shouldn't do. We > may disagree. :) Oh no, the framework doesn't depend on using a session at all. Just this particular auth module depends on plugging in the session beforehand. > It requires server storage to know what usernames are > available in this situation *yes*. But that is merely at > authentication time - not during the lifetime of the > session. An auth service is not a session service. > > It does not require server session storage inherently to > associate a session cookie with a user - the cookie has > plenty of storage to do that itself. Hrmm. I'll think about that... maybe the only thing necessary is that a database handle is available from Apache2::Controller::DBI::Connector. > Your session times out when you say it times out. And > changes states when you say it changes states. You can > have two time periods - one being re-auth request time > period, another being true expiration time period. The > purpose of a session timeout is to stop large time delta > recycling of session data. The purpose of re-auth time > period is to nudge your flow into getting a new > authentication token without the interruption of actual > logout. Neither of these is an infinite state, and would > not be replicated by infinite timeout. That could work. Sort of want to avoid a proliferation of directives... but I guess that's a potential control that would be less complicated and wouldn't require a persistent session store on the server. And can set a flag in notes that this happened for the app to deal with it if it wants to, as you said. Data::UUID's are a good idea for the auth tracking cookie. For the backend-session plugin right now I'm just using the _session_id from Apache::Session as the cookie value.
