* Bill Moseley <mose...@hank.org> [2009-10-18 01:55]: > On Sat, Oct 17, 2009 at 12:42 PM, Aristotle Pagaltzis <pagalt...@gmx.de>wrote: > > • 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_identifiers_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.
No, I mean passing all the necessary state along in the URI explicitly – not a key to a bit of catch-all state on the server. If there is so much state as to make this impractical, then have the client POST the stuff and have the server create a resource to represent that specific collection of state. Eg. if a search query is too complex, have it POST the query and store it under a search ID that the client then uses to browse the results. The difference from putting a session token in the URI is that they can create several different queries and then browse the results of each in a different tab, at the same time, without the tabs wiping out each others’ state. The session is a sinle catch-all grab bag for all sorts of state, basically a big pile of global variables. It has all the same problems as functions that use global variables – you can’t call it with different values when other parts of the code are also using the same variable. In the same way putting state in the sessions mean you can have only one search query, only one shopping cart, only one of each other kind of state, at once, because there is only one session. If you create resources explicitly for each aspect of state, then you can have as many of that kind of state at the same time as you want, much like passing a parameter to a function instead of having it look at a global variable. Of course, if it’s feasible to just pass all the data via the URI you should still do it that way. That’s *always* the better solution when there is no specific reason against it, because it makes the interaction state identifiable by URI, just like creating resources does, but without the need to persist anything on the server. Note how in both of cases (URI parameters and resources), the interaction state is identified explicitly by the URI. That’s how different tabs can have different state – because each one has a different URI in the address bar. For the same reason it’s also possible for the user to bookmark any specific point in the interaction. If you hid the state in a grab bag session, then that wouldn’t be possible. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/