Re: PHP (and Perl) at Yahoo!

[Ovid]

Very interesting presentation. From what I could see, Perl may have been a serious contender were it not for two areas that they felt were problematic. Sandboxing and TIMTOWTDI.

The sandboxing issue stems from the fact that Perl is designed to Get Things Done and trusts the programmer to do the right thing in terms of security. Frankly, while I know quite a bit about Web programming security, I don't know as much about "sandboxing" per se. Does the Safe module help with that? At my company, we are developing tools to abstract out many of the dangerous aspects of Perl coding. For example, some of our database work is driven through a database module that forces the developer to use placeholders and automatically rolls back transactions that the developer does not explicitly commit (thus, if the program dies, we don't have "partial" data entered). Unfortunately, these tools are not as mature as they could be.

Another tool that I have just started using to deal with these issues is a "Web form filter/untainter". Essentially, to read in form data, I set up a list of fields and regex filters for each field. Only data that is passed through a filter (and simultaneously untainted) gets into my code (I hope to integrate something similar into CGI::Safe). This is just to point out that many dangerous aspects of programming can be mitigated with proper tools and standards. However, I am curious to know how this compares with PHP.

The TIMTOWTDI issue is problematic, though. With only three Perl programmers here, we've been bit by this problem. Perl is just so ridiculously flexible that even a small programming department can produce code that varies widely in style, even if it's all high quality.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[Aristotle]

Wouldn't untainter functionality belong to Data::FormValidator rather than CGI or a derivative thereof? That's where I'd put it, anyway.

Makeshifts last the longest.

[Ovid]

That sounds reasonable, but this is part of some slightly different functionality that is designed to work specifically with our current Template Toolkit setup here at work. Data::FormValidator appears nice, but I felt that a small, custom-designed tool that is a drop-in replacement for our code was the way to go. My first chance to use this took a 450 line program and reduced it down to 150 lines. No changes to our templates were required. Further, Data::FormValidator makes no reference to untainting the data.

Don't get me wrong, Data::FormValidator looks great, but it didn't appear to quite be what I need. Subclassing it might have been an option, but it makes internal function calls rather than method calls and that can make subclassing a pain because I would have to reimplement the functions rather than inherit them. The code below demonstrates the problem.

#!/usr/bin/perl -w
use strict;
use Data::Dumper;
package Foo;

sub new {
    my $class = shift;
    bless {}, $class;
}

sub foobared {
    my $self = shift;
    $self->{foo} = _test( 3 );
}

sub _test { shift }

package Bar;
@Bar::ISA = 'Foo';
sub foobared {
    my $self = shift;
    $self->{foo} = $self->_test( 3 );
}

package Main;
my $o = Foo->new;
$o->foobared;
print $o->{foo},$/;
my $o2 = Bar->new;
$o2->foobared;
print $o2->{foo};

As you can see, mixing regular functions with methods doesn't work. You can't inherit because you have an extra argument.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[Aristotle]

Oh, I meant that as in writing a patch to Data::FormValidator, not subclassing just for your own perusal. :-) I like that module a lot but I believe it needs this feature to be really complete.

Makeshifts last the longest.