On Mon, 21 May 2007, A. Pagaltzis wrote:
So if the blank form is `/order/form`, you’d stash the form data
away somewhere under ID `7z32a` (f.ex) and redirect them to
`/order/form/7z32a` (or `/order/form?populate=7z32a`). The data
could be in the session, as long as it’s keyed off of an ID that
shows up in the URI and the ID is unique across all
users/sessions. Stick the ID in a hidden field in the form so you
can garbage the data immediately if the submit goes through.
(Else you’ll have to expire the data after a while.)
This way, you don’t have a page whose content changes based on
implicit state on the server that isn’t contained in the client’s
request – the REST way.
I do like this, in theory. It's basically equivalent to puttint the
session key in the URI, though, which means it has some security issues.
If I were to do this, I'd probably associate each mini-session (for a form
or whatnot) with the user_id, and I'd still be checking the user_id
against the cookie.
I think that would be sufficiently secure.
I know that user cookies are not considered RESTful, but this is one
problem I have not been able to work around. If web browsers could be made
to handle HTTP auth with more flexibility (use forms, allow logout, etc)
then I think this solution could 100% RESTful.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
_______________________________________________
List: [email protected]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
