pagaltzis at gmx
Oct 18, 2009, 7:06 AM
Post #5 of 5
(1014 views)
Permalink
|
|
Re: Adding default query parameters to generated links.
[In reply to]
|
|
* Bill Moseley <moseley [at] hank> [2009-10-18 01:55]:
> On Sat, Oct 17, 2009 at 12:42 PM, Aristotle Pagaltzis <pagaltzis [at] gmx>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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/
|
