On 7.7.2009, at 5.47, MK wrote:
> On 07/05/2009 02:27:23 PM, hha...@gmail.com wrote:
>> I'd also appreciate a small graph of the database structure.
>
> The script that produced the db is there, which is pretty much all the
> information you could need.
Yep, I saw it, but it's still relatively hard to see the actual layout
from three CREATE TABLEs embedded in a perl script, and the sample
data that accompanies the tables.
>> Second, you only use <%perl> blocks. You should, at the very least,
>> introduce the <%init> block and the <%args> block.
>
> By my
> reading of that, the <%args> block is not a requirement but an
> *optional* convenience. [...] When passing single
> parameters, just using the %ARGS hash seems fine; perl programmers are
> used to not using function prototypes, which is a parallel to this.
The <%args> block offers a number of benefits:
- shorter variable names
- a single well-defined place to see all the arguments of your component
- default values
- mason errors out if all arguments are not given
Personally, I didn't even realise you could use the %ARGS hash that way.
I was suggesting using the <%init> block mostly because your code has
pretty obvious places for using it. For example, the whole <%perl>
block inside animal.comp
>> Your code is rife with SQL injection and cross-site scripting
>> vulnerabilities. Here's a quick refresher:
>>
>> Bad:
>> $db->do("insert into animals (name, class_id, cage_id) values
>> ('$ARGS{name}','$class','$ARGS{cage}')");
>> $sql = $db->prepare("update cages set species=species+1 where
>> id='$ARGS{cage}'");
>> $sql->execute;
>> <% $somevar %>
>>
>> Good:
>> $db->do("insert into animals (name, class_id, cage_id) values
>> (?,?,?)", $ARGS{name}, $class, $ARGS{cage});
>> $sql = $db->prepare("update cages set species=species+1 where id=?");
>> $sql->execute($ARGS{cage});
>> <% $somevar |h %>
>
> I'm almost as new to SQL as I am to Mason! If you could explain the
> significance of this difference to me, or at least point me to some
> explanation, I will bring the code up to par...
The first one uses simple string concatenation. Consider this: what if
the user's input contains an apostrophe? The end result will be
"VALUES ('Meller's Mongoose', [...]". Syntax error. The worst case is
a malicious user adding his own SQL statements to run a DROP DATABASE
command or similar.
The second example uses placeholders. The database driver essentially
keeps the actual statement and the arguments separated. There's no
risk of user input wrecking the statement. There's a lengthy
explanation with solutions of varying quality at
http://unixwiz.net/techtips/sql-injection.html
(oh, and my $db->do was supposed to have three parameters: $db-
>do($sql, %opts, @params). so please pass an empty hash or undef for
%opts)
The cross-site scripting problem is similar: HTML (and XML) has five
reserved characters, <>&'". If those are output without escaping,
something will break. A malicious user could source an external script
and it will run on a victim's browser. Mason has a substitution-
escaping feature, covered in chapter 2 of the mason book.
I tend to tag *every* <% %> with "| h" unless I am very sure that the
output is harmless.
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Mason-users mailing list
Mason-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mason-users
