[Catalyst] Re: flash with DBIC session storage

[A. Pagaltzis]

Hi Bill,

* Bill Moseley <moseley at hank.org> [2007-07-29 00:05]:
> On Sat, Jul 28, 2007 at 11:21:56PM +0200, A. Pagaltzis wrote:
> >> User visits page A.
> >> User visits page B in another tab.
> >> User submits form A.
> >> User submits form B.
> >> A updates the flash.
> >> B updates the flash.
> >> Page A2 loads with whatever flash won.
> >> Page B2 loads with whatever flash won.
> >
> >Keeping implicit state on the server blows. News at 11.
> >
> >(The right way: don’t use flash. Put the stuff somewhere where
> >you can give it a URI and send the user to that address.)
> 
> So simple case: client posts which updates a user "Foo".  You
> redirect after post and want to display 'User "Foo" was
> updated' (or something you need to store server-side between
> the post and the redirect).

Exactly.

> What's your approach? Always pass around a session id in the
> URL? On redirects pass an unique id to get at that
> request-specific message?

The latter – or neither.

If it’s just to show the user a canned message, I’d probably add
a query parameter to the URI and be done with it. For any small
predetermined data set (eg. a handful of flags), I’d simply
encode the state right into the URI.

Putting a unique ID in the URI is the right approach for anything
that you actually need to store on the server somewhere – eg. for
multi-page forms.

The only use I have for the session ID is as an auth token (and
then only because HTTP auth is *still* broken in browsers… argh!
sigh). I never store anything but credentials in the session.

A point regarding the URIs constructed by the server: I’d usually
include a timestamp-ish token and a hash value in the URI. The
hash is taken over the unique ID or query params or whatever
other state data is there, plus the timestamp, plus a server-side
secret.

The secret ensures that this hash can only be generated correctly
by the server, so the authenticity of a URI can be verified. The
timestamp, verified by the hash, allows any expiry testing to
happen by just looking at the URI, without ever hitting the
database (or other session storage backend) at all.

It has to be mentioned that the resulting URIs aren’t exactly
pretty. (A 128-bit hash takes 22 digits to encode in base 64 (10
digits + 26 uppercase letters + 26 lowercase + underscore +
hyphen = 64 symbols). That’s not a _huge_ amount of cruft,
fortunately, but enough to irritate a bit. However that should be
irrelevant if you use clean URIs for any pages that represent
non-ephemeral things (as well you should).

> If so, how do you manage orphans, say if the redirect never
> happens?

How do you manage orphaned sessions? :-)

With all approaches, there is transient state on the server that
needs to be managed as such, so implementation-wise there isn’t
much discrepancy. The difference is only in whether that state is
addressable.

When it is, the application fits better into HTTP and you get to
do things like end the request cycle with a 301 or 410 before you
do any I/O at all.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>