<br><br><div class="gmail_quote">On Sat, Oct 17, 2009 at 12:42 PM, Aristotle Pagaltzis <span dir="ltr"><<a href="mailto:pagaltzis@gmx.de">pagaltzis@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* Tomas Doran <<a href="mailto:bobtfish@bobtfish.net">bobtfish@bobtfish.net</a>> [2009-10-13 00:00]:<br>
<div class="im">> I'd very likely go with this myself.<br>
><br>
> You can apply it as a role, and then trivially remove it later,<br>
> it's wrapping one method and so low impact, and there are no<br>
> negative consequences if your session goes away for any<br>
> reason..<br>
><br>
> Just feels like less moving parts to me...<br>
<br>
</div>Less implicit state on the server = better HTTP style:<br></blockquote><div><br>I agree with you here. <br></div><div> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
• Easier to scale: at the app level, no session to replicate<br>
between web servers or communicate via the DB; above the app<br>
level, easier to use proxies to selectively route/cache stuff<br>
by inspecting URIs<br></blockquote><div><br>I wish that was possible, but in this case the session data structure is a beast.<br>I'm currently pulling data from the existing app's session and populating $c->session for the data<br>
that needs to be used.<br> <br></div><div> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
• Better user experience: allows multiple tabs with different<br>
interaction state in each<br></blockquote><div><br>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?<br><br><a href="http://en.wikipedia.org/wiki/Session_fixation#Do_not_accept_session_identifiers_from_GET_.2F_POST_variables">http://en.wikipedia.org/wiki/Session_fixation#Do_not_accept_session_identifiers_from_GET_.2F_POST_variables</a><br>
<br>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.<br>
</div><div><br> </div></div><br>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org">moseley@hank.org</a><br>