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:]]*)$/;
[download]

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

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.