[Catalyst] Re: Form validation in insert() and update()?

A. Pagaltzis pagaltzis at gmx.de
Tue May 22 04:22:08 GMT 2007


* Dave Rolsky <autarch at urth.org> [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/>



More information about the Catalyst mailing list