Yesterday I needed to add JSON support (both in the request and
response) to a few actions. I decided to try Catalyst::Action::REST.
Well, actually, I first tried using just C::A::Serialize and
C::A::Deserialize -- but was not sure if those could be used
separately. That didn't work so then I
Bill Moseley wrote:
Yesterday I needed to add JSON support (both in the request and
response) to a few actions. I decided to try Catalyst::Action::REST.
Well, actually, I first tried using just C::A::Serialize and
C::A::Deserialize -- but was not sure if those could be used
separately.
Hi,
I don't consider this a bug, it's just by way of feedback to the list
and module authors.
I just updated to the latest C::P::Authentication and now get errors
in my login code in some places. My code looks basically like this
(simplified a bit) :
sub login Chained('/') Args(0) : {
# first
I still had
-Authentication::Credential::Password
-Authentication::Store::DBIC
in the modules list, from the old setup. Removing these seems to have
fixed the problem.
___
List: Catalyst@lists.scsys.co.uk
Listinfo:
Anyone have some suggestions or references to good modules or best
practices in this regards? This is mainly in regards to using these
inputs in sql queries or other areas where common attacks against web
applications happen. I wonder in the catalyst world what best practices
are. Would it be a
--- Mesdaq, Ali [EMAIL PROTECTED] wrote:
Anyone have some suggestions or references to good
modules or best
practices in this regards? This is mainly in regards
to using these
inputs in sql queries or other areas where common
attacks against web
applications happen. I wonder in the
You might have a look at
http://www.perlfoundation.org/perl5/index.cgi?form_processing - you'll
find there the most popular parameter validation modules. By the way
if you use SQL queries with placeholders you don't need to fear SQL
injection attacks.
Cheers,
Zbyszek
On Dec 13, 2007 9:21 PM,
I use DBIC with catalyst and even in cases I don't use DBIC I always use
placeholders. However I still don't think thats a strong solution or at
least it doesnt help me sleep better. I have still seen cases when I
have used placeholders and the input variable still ended up escaping
something and
There is also input via url which is actually a little more worrisome
than form input. I wonder if there is possible way the Catalyst dispatch
internals can be exploited in this manner. Maybe thats an area thats
already been reviewed but just mentioning it to throw it out there.
Thanks,
I had exactly the same problem two days ago and found the same fix.
On Dec 13, 2007, at 1:06 PM, Daniel McBrearty wrote:
I still had
-Authentication::Credential::Password
-Authentication::Store::DBIC
in the modules list, from the old setup. Removing these seems to have
fixed the
On 13 Dec 2007, at 22:43, Jonathan Rockway wrote:
On Thu, 2007-12-13 at 21:53 +, Ash Berlin wrote:
2) avoiding SQL injection
This is simple. never interpolate *anything* from the user into SQL.
Use placeholders. Or better yet use an ORM such as DBIx::Class.
Be mindful of these cases,
On 12/13/07, Jonathan Rockway [EMAIL PROTECTED] wrote:
Be mindful of these cases, though:
# 2
my $user = $rs-create({
is_admin = 0,
username = $c-req-param('username'),
});
Are you sure about this one? I just tested this with DBI_TRACE, and it does
appear to use bind
Ashley Pond V wrote:
You have to enable fastcgi in their panel, not in the .htaccess. Did you
do that?
Also, I learned the hard way. Always name your app script dispatch.fcgi.
They are much more aggressive about killing long running processes with
other names.
Executables should be in 755
13 matches
Mail list logo
