[Catalyst] Announcement - New session plugins

[Wade.Stuart at fallon.com]

> Bill Moseley wrote:
> > Right.  And it varies by application when you need to know.  Some
> > applications need a session for every request, so the first request
> > without a valid session from the client would need to set the cookie,
> > redirect to a special cookie-checking url which would either report
> > cookies are required if not found, or do a second redirect back to the
> > original request if the cookie is found.  I don't really see a way
> > around the double redirect.
>
> The way I've seen it done is to use both cookies and URL rewriting on
> the first request, and then just turn off URL rewriting on the second
> request if a cookie is found.
>

Yes this is how I have done it in the past and it works well.  The only
issue that exists here is the general framework needs to know about
the next hit state and take the action.  This has been problematic in
some frameworks as they have taken ugly approaches to this 3 step
process (session init, session type verify, forward to next action).

All that I request is that you not double forward to verify the next step,
its ugly.

By that,  I mean when you init the session don't redirect to the app to
verify the session type (uri, cookie) specifically for that purpose
and then forward again to the real action.  Build in state that auto
verifies the session type on the next real request.



> Agreed about cookie expiration: you have to write your code with the
> assumption that no one will ever delete cookies, even if you tell them
> to.  Don't trust the client.
>
> > - I may expire sessions in two hours, but if there's 5 or 10 minutes
> > of inactivity then I require a re-login to access more secure parts
> > of the site (like an admin area).  So the session needs to track the
> > time between requests and set a flag when exceeds a setting.
>
> That one is a little painful, since it means updating the session on
> every request, rather than being able to lazy-load it and only save when
> changing something.  Applications that don't require that level of
> security would probably rather not take the hit.
>
> - Perrin
>

This can be done in user code very easily. In auto, just do a timestamp on
each
request stored in session. If the timestamp from the previous request
is > TIMEOUT then set a relogin flag in session and redirect to an auth
page
(that does not build session) -- on successful (re)login redirect to
requested action..

I do not think that this would fall into a general purpose auth plugin,
maybe
an extension to the auth/session plugins -- but in apps where this is a
requirement there are usually other very specific auth/session extensions
that must be made as well.  Maybe just a block of code or example is needed
here.


-Wade