Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday April 07, 2006
05:31 PM

RFC: Class::CGI

[ #29255 ]

A long time ago, I mused about fetching objects directly from HTML forms instead of grabbing the ID, untainting it, validating it, and instantiating a new object. I finally wrote up a proof of concept. You can read about it at Perlmonks. Basically, it lets you do stuff like this:

use Class::CGI
  handlers => {
    customer => 'Class::CGI::Customer'
  };
my $cgi   = Class::CGI->new;
my $cust  = $cgi->param('customer');
my $email = $cgi->param('email');
# validate email
$cust->email($email);
$cust->save;

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • This reminds me very much of something I did a couple of years ago, so here's some advice on where you'll probably end up going. (because I fucked up twice before I got it right)

    First you'll want to auto-inflate a single param, so you'll do what you have now.

    Next, you're going to want to have more than one CGI param for each object. So you can do things like composite dropboxes and so on.

    Then you are going to want to define a whole group of these in one hit, so you can have something like Class::CGI::Form,
    • First you'll want to auto-inflate a single param, so you'll do what you have now.

      Yup. Got that.

      Next, you're going to want to have more than one CGI param for each object. So you can do things like composite dropboxes and so on.

      Yup. Added that a few hours ago. It was a simple matter of fixing an egregious design flaw in my original code.

      Then you are going to want to define a whole group of these in one hit, so you can have something like Class::CGI::Form, which would extract a whole bunch of

      • The one big trouble I see with having the form specification on the page itself is it violates the idea of everything that comes in from CGI being evil.

        What if you trust a Class::CGI-instantiated object to be something, and someone just changes the spec on the page...

        The other steps I missed after those, is that once you have a Class::CGI::Form-like thing, you'll want to automatically generate those based on things like Class::DBI classes.

        And that means to some degree the program itself needs to control wha
        • First, the __PROFILE__ would be strictly optional. You're always at liberty to declare the handlers in your code instead.

          Second, I agree with what you're saying about a security hole. I should add a signature check if profiles are listed in the HTML.

        • In thinking about this more, I see that the benefits of having forms declare which handlers they need are outweighed by the security issues. I'm pursuaded enough by your arguments that I think I'll abandon __PROFILE__ declarations in the HTML. Thanks for kicking me.

          • Ironically, there does exist an analogue of what you describe.

            It's called XForms :)

            But in the case of XForms, it's able to leverage Schema validation to deal with it's evil problem.