perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hedges <hed...@scriptdolphin.org>
Subject Re: preserving request body across redirects
Date Wed, 31 Dec 2008 20:44:28 GMT

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.
Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message