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 o
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 or better. IIRC Drea
I run catalyst.pl TestApp
then vim .htaccess
AddHandler fastcgi-script .fcgi
Options +FollowSymLinks +ExecCGI
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/?TestApp/script/testapp_fastcgi.fcgi
RewriteRule ^(.*)$ TestApp/script/testapp_fastcgi.fcgi/$1 [PT,L]
~
I changed filename to fcgi and chm
On 13 Dec 2007, at 23:42, Jonathan Rockway wrote:
On Thu, 2007-12-13 at 23:02 +, Ash Berlin wrote:
# 2
my $user = $rs->create({
is_admin => 0,
username => $c->req->param('username'),
});
This comes under "never interpolate *anything* from the user into
SQL."
Well, you have t
On Thu, 2007-12-13 at 23:02 +, Ash Berlin wrote:
> > # 2
> > my $user = $rs->create({
> > is_admin => 0,
> > username => $c->req->param('username'),
> > });
>
> This comes under "never interpolate *anything* from the user into SQL."
Well, you have to get data into the database s
On 14 Dec 2007, at 10:14, Mesdaq, Ali wrote:
but there is
also user generated data that can be displayed on a site and you would
need to escape any javascript code or some html and css that users can
input. That maybe is even a bigger concern for me since thats what
I see
on a daily basis i
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
appe
Yes exactly my point in my earlier emails! I am kinda thinking that
wrapper would be used like
sub edit : Local
{
my ($self, $c, $id) = @_;
$id = $someobject->checkInput({escape_html => 0, escape_sql => 1,
notify => 0});
And you just pass various flags or have different methods and maybe
On a tangent; there is still a bug in C::E::CGI for path handling
that can crash an app and potentially expose debug info depending on
one's setup. I reported it first in September 2006 and tried sending
in a patch with test a few months ago. If it's okay, maybe I can have
the fix in for Ch
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, t
On 13 Dec 2007, at 22:36, Mesdaq, Ali wrote:
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 ment
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 probl
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, though:
# 1
my $col = $req->params->{col};
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 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 t
On 13 Dec 2007, at 21:21, Mesdaq, Ali 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 catalyst
everything seems to be running fine now after a few code updates. I
came across one oddity though that might be of interest.
In my old code, I had this construct in a few places, to get the user
object from the database:
my $user = $c->get_user( $username );
It seems that the get_user method was
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, Mes
--- "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
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 cat
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: http://lists.scsys.co.uk/cgi-
that said, I seem to have trouble setting up my new config and getting
user_class sorted out:
authentication:
default_realm: 'members'
realms:
members:
credential:
class: 'Password'
password_field: 'password'
password_type: 'crypted'
store:
class
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
Bill Moseley wrote:
> On Thu, Dec 13, 2007 at 10:09:39AM -0500, Christopher H. Laco wrote:
>> 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
On Thu, Dec 13, 2007 at 10:09:39AM -0500, Christopher H. Laco wrote:
> 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
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
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 ju
27 matches
Mail list logo
