Re: PerlAuthenHandler and ErrorDocument 401

[Torsten Foertsch]

On Tue 20 May 2008, fof wrote:
> 
> PerlAuthenHandler MyAuthenHandler
> AuthType Basic
> AuthName "REST Interface"
> Require valid-user
> 
>
>         ErrorDocument 401 /http/401.html

Try:


Satisfy any


Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]

Re: Initialize object permanently

[william]

On 5/20/08, Dodger <[EMAIL PROTECTED]> wrote:
> 2008/5/19 Michael Peters <[EMAIL PROTECTED]>:
>
> > william wrote:
>  >
>  >> Then I would need to modify the QueryData module then,
>  >
>  > No don't do that.
>  >
>  >> by modifying
>  >> the standard module would it make my future maintenance more
>  >> complicated ?
>  >
>  > Absolutely.
>  >
>  >> Do you have any tips for me ?
>  >
>  > Wrap the object in your own package. Let's call it My::QueryData.
>  >
>  > package My::QueryData;
>  > use QueryData;
>  >
>  > my $query_data;
>  > sub create {
>  >  $query_data = QueryData->new(...);
>  > }
>  >
>  > sub get {
>  >  return $query_data;
>  > }
>  >
>
>
> For extra syntactic sugar, you could always just do it singlet style.
>
>  package My::QueryData;
>  use base QueryData;
>  our $singlet;
>
>  sub new {
> return $singlet if $singlet;
> return $singlet = QueryData->new(@_);
>  }
>
>
>  Of course, if you want to allow different ones for different
>  invocations (i.e. Pkg->new(foo => 1) and Pkg->new(foo => 2), you can
>  make $singlet a hashref keyed by those options, instead, and check for
>  the appropriate one
>

Thanks, those solutions are nice.

Re: Initialize object permanently

[william]

On 5/20/08, william <[EMAIL PROTECTED]> wrote:
> On 5/20/08, Dodger <[EMAIL PROTECTED]> wrote:
>  > 2008/5/19 Michael Peters <[EMAIL PROTECTED]>:
>  >
>  > > william wrote:
>  >  >
>  >  >> Then I would need to modify the QueryData module then,
>  >  >
>  >  > No don't do that.
>  >  >
>  >  >> by modifying
>  >  >> the standard module would it make my future maintenance more
>  >  >> complicated ?
>  >  >
>  >  > Absolutely.
>  >  >
>  >  >> Do you have any tips for me ?
>  >  >
>  >  > Wrap the object in your own package. Let's call it My::QueryData.
>  >  >
>  >  > package My::QueryData;
>  >  > use QueryData;
>  >  >
>  >  > my $query_data;
>  >  > sub create {
>  >  >  $query_data = QueryData->new(...);
>  >  > }
>  >  >
>  >  > sub get {
>  >  >  return $query_data;
>  >  > }
>  >  >
>  >
>  >
>  > For extra syntactic sugar, you could always just do it singlet style.
>  >
>  >  package My::QueryData;
>  >  use base QueryData;
>  >  our $singlet;
>  >
>  >  sub new {
>  > return $singlet if $singlet;
>  > return $singlet = QueryData->new(@_);
>  >  }
>  >
>  >
>  >  Of course, if you want to allow different ones for different
>  >  invocations (i.e. Pkg->new(foo => 1) and Pkg->new(foo => 2), you can
>  >  make $singlet a hashref keyed by those options, instead, and check for
>  >  the appropriate one
>  >
>
>
> Thanks, those solutions are nice.
>

Btw, I just try out that solution, it is awsome, it only takes time
while server startup. But subsequent request. it is so fast. I am new
to mod_perl, now I am in love with it. lol

Re: segfault with perl 5.10 + MasonX::Request::WithApacheSession

[Louis-David Mitterrand]

On Mon, May 19, 2008 at 09:33:49PM +0300, Niko Tyni wrote:
> On Mon, May 19, 2008 at 11:12:08AM +0200, Louis-David Mitterrand wrote:
> 
> > Since I've upgraded to perl 5.10 on my debian unstable/sid box I get a 
> > segfault when using MasonX::Request::WithApacheSession:
> > 
> > [Sat May 17 16:14:55 2008] [notice] Apache/2.2.8 (Debian) 
> > mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 configured -- 
> > resuming normal operations
> > [Sat May 17 16:15:03 2008] [notice] child pid 25786 exit signal 
> > Segmentation fault (11)
> > [Sat May 17 16:15:11 2008] [notice] child pid 25788 exit signal 
> > Segmentation fault (11)
> > [Sat May 17 16:15:12 2008] [notice] child pid 25789 exit signal 
> > Segmentation fault (11)
> 
> > ## When commented out perl 5.10 works fine
> > request_class => 'MasonX::Request::WithApacheSession',
> 
> This looks very similar to , Cc'd as
> [EMAIL PROTECTED] . I just sent a stack backtrace there, no idea
> yet if the fault is with perl or mod_perl2.

Thanks for the pointer and fine investigative work on reducing the
problem to a perl one-liner!

Awaiting upstream now...

Cheers,

Re: Apache::DBI. Is it running?

[Perrin Harkins]

On Sat, May 17, 2008 at 5:28 PM, kropotkin <[EMAIL PROTECTED]> wrote:
> Despite using $Apache::DBI::DEBUG=1 #or 2
> in my startup.pl script I cannot see any output in my error_log. This is the
> test I've seen for seeing if it is working.

Make sure you set that AFTER you load Apache::DBI.

You can also look at the number of connections to your database.
There should be one for each apache child process.

If you can't tell from that, I suggest you just cut to the chase and
stick a couple of warnings into your Apache/DBI.pm.

- Perrin

Re: New to mod_perl

[Perrin Harkins]

Hi Roy,

> I'm setting up a proxy using Apache 2.2.8 with mod_proxy and I need to add a
> custom request header with information that is currently stored in our MySQL
> server. I was thinking of using Apache to get user's IP address and pass it
> to mod_perl where mod_perl script will query the database based on that IP
> address, but I'm not sure how to have mod_perl send the result back to
> Apache.

I think you're not getting responses to this because no one is sure
what you're trying to do.  Are you saying that you're building a proxy
server with mod_proxy and mod_perl in it and you want to add something
to the requests that you proxy before sending them on to the real
server?  Have you tried writing a mod_perl fixup handler?

> Just a note, I've been testing using mod_header to add a custom request
> header and it has been working. I've also tested using
> Apache2::Filter::HTTPHeadersFixup and for some reason it works fine if the
> destination website doesn't use any kind of cookies.

Ok, are you saying that it doesn't work when there are cookies?  How
does it fail?  What happens?

- Perrin

Re: [OT] Solaris + Apache 2.2 / PHP 5 cluster config help

[Perrin Harkins]

On Sun, May 18, 2008 at 8:05 AM, Issac Goldstand <[EMAIL PROTECTED]> wrote:
> Also, do people have concrete
> benchmarks of keeping a read-only replication mysql on the webservers vs a
> single read/write shared mysql server?

Any time you can spread the reads over multiple servers it will help.
This is particularly true for MyISAM tables where reads blocks
writers.  (InnoDB tables behave like Oracle and Postgres, with a MVCC
model.)

> I also thought to buffer common DB query results (like php's sessions) in
> memcached on reads

I suspect that caching on the level of db queries will get annoying if
you try to do it everywhere.  You'd be better off caching at a higher
"object" level if you can, or just caching specific high-value
queries.

- Perrin

Re: [OT] Solaris + Apache 2.2 / PHP 5 cluster config help

[Issac Goldstand]

Perrin Harkins wrote:

On Sun, May 18, 2008 at 8:05 AM, Issac Goldstand <[EMAIL PROTECTED]> wrote:

Also, do people have concrete
benchmarks of keeping a read-only replication mysql on the webservers vs a
single read/write shared mysql server?


Any time you can spread the reads over multiple servers it will help.
This is particularly true for MyISAM tables where reads blocks
writers.  (InnoDB tables behave like Oracle and Postgres, with a MVCC
model.)



Right - I know that in theory, but was worried about the disk/ram/cpu 
overhead of replicating the writes to all of the slave servers 
offsetting that benefit...



I also thought to buffer common DB query results (like php's sessions) in
memcached on reads


I suspect that caching on the level of db queries will get annoying if
you try to do it everywhere.  You'd be better off caching at a higher
"object" level if you can, or just caching specific high-value
queries.



Well, yes, I meant the objects or data structures that result from the 
DB query - not the query or the result itself (I'd use Mysql's query 
cache for that anyway, not memcached).


Thanks for your input Perrin.

  Issac


- Perrin

Re: [OT] Solaris + Apache 2.2 / PHP 5 cluster config help

[Perrin Harkins]

On Tue, May 20, 2008 at 4:00 PM, Issac Goldstand <[EMAIL PROTECTED]> wrote:
> Right - I know that in theory, but was worried about the disk/ram/cpu
> overhead of replicating the writes to all of the slave servers offsetting
> that benefit...

Good point.  I'd suggest you look at how much RAM you can spare and
see if you can fit the data you want to query (including indexes) into
that much space.  If you can't, you're probably better off adding a
separate read-only server instead of running it on your web server
machines.  The only real advantage to running MySQL on your web
servers is the use of local sockets for connecting, which does reduce
the overhead.

- Perrin

Re: PerlAuthenHandler and ErrorDocument 401

[fof]

Torsten Foertsch wrote:
> 
> On Tue 20 May 2008, fof wrote:
>> 
>> PerlAuthenHandler MyAuthenHandler
>> AuthType Basic
>> AuthName "REST Interface"
>> Require valid-user
>> 
>>
>> ErrorDocument 401 /http/401.html
> 
> Try:
> 
> 
>   Satisfy any
> 
> 
> Torsten
> 
> --
> Need professional mod_perl support?
> Just hire me: [EMAIL PROTECTED]
> 
> 

Hey Torsten thanks for the reply but no that does not work either. I think
the real problem I am facing revolves around the reasons why the directory
/REST/ from my document root cannot be secured with a PerlAuthenHandler on
its own. 

It does not matter if I set the Location as  or  in the VirtualHost configuration the PerlAuthenHandler still kicks in for
the root directory regardless. That is to say that
http://rest.mydomain.com/REST/abc.html and http://rest.mydomain.com/abc.html
are secured by the PerlAuthenHandler regardless of what I set the 
path to. 

This is the part that is puzzling me the most. I think if I solve that then
the other stuff will just work. I am going to try removing the
PerlAuthenHandler and simply secure the directory with a htpasswd thus
taking mod_perl out of the picture. This will tell me if some Apache setting
in the main server config is being inherited by my virtual host and stuffing
things up and if it is a mod_perl problem.

Any other suggestions would be appreciated :)

Let ya know how I go.

Geoff T
-- 
View this message in context: 
http://www.nabble.com/PerlAuthenHandler-and-ErrorDocument-401-tp17330888p17353562.html
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: Initialize object permanently

[Philip M. Gollucci]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André Warnier wrote:
| The first thing that happens, is that there are multiple Apache children
| processes started and running at the same time, and that you never know
| which one is going to execute your script.  And each one of these
| children processes, will have its own independent copy (or instance) of
| your "common" variable (or object).  So the variable will not really be
| common.
FWIW, things created before the PerlChildInit (before the httpd children are
spawned) in the parent httpd process are shared via COW (copy-on-write).

Now if you are talking about worker, event or other threaded mpm's instead of
prefork, this is different.



- --
- 
Philip M. Gollucci ([EMAIL PROTECTED])
o:703.549.2050x206
Senior System Admin - Riderway, Inc.
http://riderway.com / http://ridecharge.com
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70  3F8C 75B8 8FFB DB9B 8C1C

Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.8 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIM2/UdbiP+9ubjBwRAuvXAJ4t8kxvkl1FcmX/ckdf6GHjA3n+BgCfYCeG
J3lfKvZptduBfnZYQg0tKog=
=vr3A
-END PGP SIGNATURE-

Re: PerlAuthenHandler and ErrorDocument 401

[fof]

fof wrote:
>  I am going to try removing the PerlAuthenHandler and simply secure the
> directory with a htpasswd thus taking mod_perl out of the picture. This
> will tell me if some Apache setting in the main server config is being
> inherited by my virtual host and stuffing things up and if it is a
> mod_perl problem.
> 
> Any other suggestions would be appreciated :)
> 
> Let ya know how I go.
> 
> 

ok just to let you know I have tried my above experiment (taking mod_perl
authentication out of the equation) and everything works as one would
expect. So this means it is related to mod_perl's behavior or how I am using
it.

I have had problems before when mod_perl seems to override various behavior
in Apache. For example when using a PerlAuthenHandler it seemed to wipe out
the standard DirectoryIndex directive which the main webserver had set to
index.htm etc. This caused a problem when visiting the root directory as it
would not serve up the default index page. To fix this I had to add a
PerlFixUpHandler which restored some default settings.

Is this a similar problem/issue?

-- 
View this message in context: 
http://www.nabble.com/PerlAuthenHandler-and-ErrorDocument-401-tp17330888p17353912.html
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: PerlAuthenHandler and ErrorDocument 401

[Torsten Foertsch]

On Wed 21 May 2008, fof wrote:
> I have had problems before when mod_perl seems to override various behavior
> in Apache. For example when using a PerlAuthenHandler it seemed to wipe out
> the standard DirectoryIndex directive which the main webserver had set to
> index.htm etc. This caused a problem when visiting the root directory as it
> would not serve up the default index page. To fix this I had to add a
> PerlFixUpHandler which restored some default settings.

A Perl authentication handler if correctly designed does not interfere with a 
DirectoryIndex. It should also work smoothly inside a Location or Directory 
block or from a .htaccess file. So I suspect your problem lies in the code of 
your handler. (Are you fiddling with $r->filename or depending on 
$r->location?) But without insight in that code I think nobody can help.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]

Re: PerlAuthenHandler and ErrorDocument 401

[fof]

Torsten Foertsch wrote:
> 
> On Wed 21 May 2008, fof wrote:
>> I have had problems before when mod_perl seems to override various
>> behavior
>> in Apache. For example when using a PerlAuthenHandler it seemed to wipe
>> out
>> the standard DirectoryIndex directive which the main webserver had set to
>> index.htm etc. This caused a problem when visiting the root directory as
>> it
>> would not serve up the default index page. To fix this I had to add a
>> PerlFixUpHandler which restored some default settings.
> 
> A Perl authentication handler if correctly designed does not interfere
> with a 
> DirectoryIndex. It should also work smoothly inside a Location or
> Directory 
> block or from a .htaccess file. So I suspect your problem lies in the code
> of 
> your handler. (Are you fiddling with $r->filename or depending on 
> $r->location?) But without insight in that code I think nobody can help.
> 
> Torsten
> 
> 

Hi Torsten,

Thanks again for your reply. You might be right, I am probably not doing
things correctly although I don't believe I am doing anything fancy. I can't
see where I might be fiddling with the objects you mentioned. 

I have uploaded my MyAuthenHandler.pm and the modules it relies on for
configuration perhaps if you have time you could peruse the code and let me
know if I am doing anything wrong for this type of operation.

Thanks again for your help on this.

http://www.nabble.com/file/p17356582/MyAuthenHandler.pm MyAuthenHandler.pm 
http://www.nabble.com/file/p17356582/MyModPerlUtility.pm MyModPerlUtility.pm 
http://www.nabble.com/file/p17356582/MyModPerlDBUtility.pm
MyModPerlDBUtility.pm 
-- 
View this message in context: 
http://www.nabble.com/PerlAuthenHandler-and-ErrorDocument-401-tp17330888p17356582.html
Sent from the mod_perl - General mailing list archive at Nabble.com.