[Catalyst] Re: Adding default query parameters to generated links.

Bill Moseley moseley at hank.org
Sat Oct 17 23:53:00 GMT 2009


On Sat, Oct 17, 2009 at 12:42 PM, Aristotle Pagaltzis <pagaltzis at gmx.de>wro=
te:

> * Tomas Doran <bobtfish at bobtfish.net> [2009-10-13 00:00]:
> > I'd very likely go with this myself.
> >
> > You can apply it as a role, and then trivially remove it later,
> > it's wrapping one method and so low impact, and there are no
> > negative consequences if your session goes away for any
> > reason..
> >
> > Just feels like less moving parts to me...
>
> Less implicit state on the server =3D better HTTP style:
>

I agree with you here.


> =95 Easier to scale: at the app level, no session to replicate
>  between web servers or communicate via the DB; above the app
>  level, easier to use proxies to selectively route/cache stuff
>  by inspecting URIs
>

I wish that was possible, but in this case the session data structure is a
beast.
I'm currently pulling data from the existing app's session and populating
$c->session for the data
that needs to be used.



> =95 Better user experience: allows multiple tabs with different
>  interaction state in each
>

This is something you have mentioned before, and I'm on board with this.  I
assume you mean a session id in the URL, right?

http://en.wikipedia.org/wiki/Session_fixation#Do_not_accept_session_identif=
iers_from_GET_.2F_POST_variables

recommends not having a session id in the URL.  One way to mitigate risks is
by changing session ids often (as recommended by the article).  But, assumes
web requests are serial in nature, which they are not.  So, it's not that
simple to just send back a new session id every request or ever few minutes.



-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20091017/e7da5=
3ac/attachment.htm


More information about the Catalyst mailing list