* Dave Rolsky <[EMAIL PROTECTED]> [2007-05-21 18:30]: > 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.
Yeah, you would have to make sure that whoever is requesting the prepopulated form is permitted to do so. But that’s easy – as I said, just continue to put the data in the session as you would have, just make sure to add a layer of indirection through a hash. Eg. # previously $c->session->{foo_form} = { name => $name, email => $email }; # better: my $form_state_id = get_appwide_unique_id(); $c->session->{foo_form}->{$form_state_id} = { name => $name, email => $email }; Then when the user asks for `/oder/form/7z32a`, you check if there’s a `$c->session->{foo_form}->{7z32a}` key. If not, spit out a 404. That’s it – it’s no harder than what you already do. All you need is to calculate an ID and to add the routing for `.../form/{id}` URIs. > 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. Actually, if you use the cookie purely as an authentication token, your app is still RESTful. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/