Re: Re: Re: Re: Re: Re: Re: Re: Re: "Correct" program style questions

[sauoq]

I hope I'll be forgiven for having one last try... :^)

Just this one last one... :-)

I don't consider it paranoid to validate user input.

Either do I. We aren't really talking about validating user input though. We are talking about the literal presence of parameters in the query. The presence of the parameters themselves is ostensibly controlled by the programmer and should be considered reliable. Take these three URLs for example:

1. http://example.com/some.cgi?name=foo
2. http://example.com/some.cgi?name=
3. http://example.com/some.cgi

In the first example, a call to param('name') returns the value. In the second, it would return an empty string. In the last it would return undef. The or-empty construct eliminates the ability to differentiate between cases two and three.

If the 'name' parameter is expected to be there but isn't, then someone is accessing the application in a way that it was not meant to be accessed. That's an exceptional condition. If you have determined that this situation is critical, then you should be checking the definedness of the value that param() returns and taking appropriate action unless it is defined. If you have determined that this situation is not critical, then you could choose to ignore it, with or without warnings.

Using the or-empty construct amounts to nothing more than a non-standard way of turning an 'unitialized value' warning off for one variable. That can't be good. Especially not without documenting that behavior.

Sounds like a possible DoS attack in the making.

That's unlikely though perhaps not impossible. In order to exploit it someone would have to be familiar with the fact that your program is logging warnings. You log information with each connection anyway, so what is a little more going to hurt? If you actually log a lot more with warnings, that's an argument to turn them off. Better yet, it would be a very good reason to check for undef on the original param() call and handle the condition properly. For instance, you might choose to email your pager that a possible DoS or hack attempt is taking place and log the IP.

Upon looking at the original code again, I'm convinced that the proper way to do it is to check for definedness first and to use a * rather than a + in the regex in order to ensure that the untainted value is never undef. Something similar to this:

error_out() unless defined( my $name = param('name') ); 
($name) = $name =~ /^([[:alpha:]]*)$/;

-sauoq
"My two cents aren't worth a dime.";