> As my original post demonstrated, that was not the issue at all. But I
> found the reason for the bug. It seems IF in the following expression:
>
> my $rsts = $c->model ('MintAppDB::TransSum')->find ({
> category => $c->req->param ('category'),
> sentto => $c->req->param ('sentto'),
> iso => $c->req->param ('iso')
> });
>
> if category and iso pointed to undefined values, the bug I struggled
> with was triggered. Making sure that they were defined took care of the
> problem. I guess the sql generating stuff didn't like being fed
> undefined values.
It's a kind of standard mistake when using perl hashes. $c->req->param
is called in list context and returns a list of values. If there were
no param passed in url, this list is empty and your hash turns into {
category => sentto => 'email:[EMAIL PROTECTED]', 'iso' } - which of
course equals to { category => 'sentto', 'email:[EMAIL PROTECTED]'
=> 'iso' }.
As may people noted, this is not only a bug, but a searious security
issue (you see, you may pass any sql to your database). If you are not
checking params before call to 'find', you may fix it easily by
chaging context to scalar:
my $rsts = $c->model ('MintAppDB::TransSum')->find ({
category => scalar($c->req->param ('category')),
sentto => scalar($c->req->param ('sentto')),
iso => scalar($c->req->param ('iso'))
});
Consult docs for details:
http://search.cpan.org/dist/Catalyst-Runtime/lib/Catalyst/Request.pm#$req-%3Eparam
--
С уважением, Сергей Мартынов.
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
