Problem using PerlSection and global object in conf

--=-Usa6keftlF7qVLE5b/D1
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

I have an application I am in the process of upgrading to
Apache/mod_perl 2. While reading the docs, I came across this section:
http://perl.apache.org/docs/2.0/user/coding/coding.html#Meth od_Handlers

Which I was really excited to try! My application handles user
authentication and authorization, but was designed to work from many
points, not just for web pages (though that is its main function). The
core just underwent a major rewrite to a cleaner, inheritable OO
interface that I'm very happy with. The way the new version is designed,
a 'client' object will cache the user objects (relatively small, name,
email, phone etc) for users previously authenticated, using a session
token as a key. Reading the document above, it seemed I would be able to
create a client object at startup, which could cache 'currently'
authenticated users (cleanup on the configured timeout), saving a lot of
database accesses. As yet I have not been able to test the usefulness of
this approach however as I can't seem to get off the ground, getting
tangled with errors in configuration.

Here is the relevant part of the documentation I'm trying to work from:


use Bird::Eagle;
$Bird::Global::object = Bird::Eagle->new();

...
PerlResponseHandler $Bird::Global::object->handler


And here is the relevant portions of my configuration file (located in
conf.d/):


$Apache2::PerlSections::Save = 1;
use CAS::Apache::Auth;

# The default CAS client for the admin location
$CAS_admin_client = 1;
$Auth_admin = CAS::Apache::Auth->new({CLIENT_ID => $CAS_admin_client});



AuthName CAS
AuthType basic
PerlAuthenHandler $Auth_admin->authen
# PerlAuthzHandler $Auth_admin->authz
require valid-user
# Order deny,allow
# Deny from all



Which returns the following error on configtest:
Syntax error on line 20 of /etc/apache2/conf.d/CAS.conf:
Unknown type 'CAS::Apache::Auth' for directive Auth_admin
at /usr/lib/perl5/vendor_perl/5.8.8/i586-linux-thread-multi/Apa che2/PerlSections.pm line 187.\n

Commenting out the PerlAuthenHandler directive in location has no effect
on the error. I've spent a day searching docs and the mailing list,
trying all sorts of variations, with no luck (and some annoyance, with
repeated references to docs like eg/perl_sections.txt which I can't find
in the distribution!). My main thought was to move the entire
section under :


use CAS::Apache::Auth;

$CAS_admin_client = 1;
$Auth_admin = CAS::Apache::Auth->new({CLIENT_ID => $CAS_admin_client});

$Location{"/Cas"} = {
PerlAuthenHandler => $Auth_admin->authen,
AuthName => 'CAS',
AuthType => 'basic',
require => 'valid-user',
};



Which got me:
Syntax error on line 20 of /etc/apache2/conf.d/CAS.conf:
\t(in cleanup) Can't call method "get_basic_auth_pw" on an undefined
value at /usr/lib/perl5/site_perl/5.8.8/CAS/Apache/Auth.pm line 57.\n
\t(in cleanup) \t(in cleanup) Can't call method "get_basic_auth_pw" on
an undefined value at /usr/lib/perl5/site_perl/5.8.8/CAS/Apache/Auth.pm
line 57.\n

Ah! The authen method gets $self and then $r, then gets the status and
password with $r->get_basic_auth_pw. Oops, I'm calling the method
instead of setting it as a handler. Perhaps setting it as a coderef? So
I changed PerlAuthenHandler to:

PerlAuthenHandler => \$Auth_admin->authen,


But I still get:
Syntax error on line 20 of /etc/apache2/conf.d/CAS.conf:
\t(in cleanup) Can't call method "get_basic_auth_pw" on an undefined
value at /usr/lib/perl5/site_perl/5.8.8/CAS/Apache/Auth.pm line 57.\n
\t(in cleanup) \t(in cleanup) Can't call method "get_basic_auth_pw" on
an undefined value at /usr/lib/perl5/site_perl/5.8.8/CAS/Apache/Auth.pm
line 57.\n

Is what I am trying to do actually possible? Do I have a stupid typo or
such somewhere? The first error (Unknown type 'CAS::Apache::Auth' for
directive Auth_admin), and other PerlSection docs seem to indicate to me
that under sections, $Foo = 'bar'; is the equivalent of Foo bar
(Directive value), and does not create variables usable in other parts
of the conf. But I'm at a loss to understand why a code reference being
set as the target handler executes the code during configuration.

If in the handler I catch the call from conf and return harmlessly, will
calls while running work the way I think the docs indicate? Help solving
this to do what I want would be greatly appreciated!

====================================
Details, details:

SuSE 10.1 (net install)

267: 4:07pm % uname -a
Linux xxxxxxxx 2.6.16.27-0.6-default #1 Wed Dec 13 09:34:50 UTC 2006
i686 athlon i386 GNU/Linux

268: 3:50pm % /usr/sbin/apache2ctl -V
Server version: Apache/2.2.0
Server built: Jul 27 2006 13:28:51
Server's Module Magic Number: 20051115:0
Architecture: 32-bit
Server MPM: Prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT="/srv/www"
-D SUEXEC_BIN="/usr/sbin/suexec2"
-D DEFAULT_PIDLOG="/var/run/httpd2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="/var/run/accept.lock"
-D DEFAULT_ERRORLOG="/var/log/apache2/error_log"
-D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types"
-D SERVER_CONFIG_FILE="/etc/apache2/httpd.conf"

269: 4:06pm % perl -V
Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
Platform:
osname=linux, osvers=2.6.16, archname=i586-linux-thread-multi
uname='linux tait 2.6.16 #1 smp tue mar 14 18:04:33 utc 2006 i686
i686 i386 gnulinux '
config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr
-Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm
-Duseshrplib=true -Doptimize=-O2 -march=i586 -mtune=i686
-fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -Wall -pipe'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -march=i586 -mtune=i686 -fmessage-length=0 -Wall
-D_FORTIFY_SOURCE=2 -g -Wall -pipe',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING
-fno-strict-aliasing -pipe -Wdeclaration-after-statement'
ccversion='', gccversion='4.1.0 (SUSE Linux)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =''
libpth=/lib /usr/lib /usr/local/lib
libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=/lib/libc-2.4.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.4'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E
-Wl,-rpath,/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE '
cccdlflags='-fPIC', lddlflags='-shared'


Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY PERL_IMPLICIT_CONTEXT
PERL_MALLOC_WRAP THREADS_HAVE_PIDS USE_ITHREADS
USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API
Built under linux
Compiled at Apr 23 2006 00:26:41
@INC:
/usr/lib/perl5/5.8.8/i586-linux-thread-multi
/usr/lib/perl5/5.8.8
/usr/lib/perl5/site_perl/5.8.8/i586-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.8
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.8/i586-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.8
/usr/lib/perl5/vendor_perl
.


--
Sean P Quinlan

--=-Usa6keftlF7qVLE5b/D1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit








I have an application I am in the process of upgrading to Apache/mod_perl 2. While reading the docs, I came across this section:





Which I was really excited to try! My application handles user authentication and authorization, but was designed to work from many points, not just for web pages (though that is its main  function). The core just underwent a major rewrite to a cleaner, inheritable OO interface that I'm very happy with. The way the new version is designed, a 'client' object will cache the user objects (relatively small, name, email, phone etc) for users previously authenticated, using a session token as a key. Reading the document above, it seemed I would be able to create a client object at startup, which could cache 'currently' authenticated users (cleanup on the configured timeout), saving a lot of database accesses. As yet I have not been able to test the usefulness of this approach however as I can't seem to get off the ground, getting tangled with errors in configuration.



Here is the relevant part of the documentation I'm trying to work from:

  <Perl>

      use Bird::Eagle;

      $Bird::Global::object = Bird::Eagle->new();

  </Perl>

  ...

  PerlResponseHandler $Bird::Global::object->handler

<Perl>

	$Apache2::PerlSections::Save = 1;

	use CAS::Apache::Auth;

	

	# The default CAS client for the admin location

	$CAS_admin_client = 1;

	$Auth_admin = CAS::Apache::Auth->new({CLIENT_ID => $CAS_admin_client});

</Perl>



<Location /CAS>

	AuthName CAS

	AuthType basic

	PerlAuthenHandler $Auth_admin->authen

#	PerlAuthzHandler $Auth_admin->authz

	require valid-user

#	Order deny,allow

#	Deny from all

</Location>

<Perl>

	use CAS::Apache::Auth;

	

	$CAS_admin_client = 1;

	$Auth_admin = CAS::Apache::Auth->new({CLIENT_ID => $CAS_admin_client});

	

	$Location{"/Cas"} = {

		PerlAuthenHandler => $Auth_admin->authen,

		AuthName => 'CAS',

		AuthType => 'basic',

		require => 'valid-user',

	};

</Perl>

		PerlAuthenHandler => \$Auth_admin->authen,

Re: Problem using PerlSection and global object in conf

On Jan 4, 2007, at 5:13 PM, Sean P Quinlan wrote:

> The way the new version is designed, a 'client' object will cache
> the user objects (relatively small, name, email, phone etc) for
> users previously authenticated, using a session token as a key.
> Reading the document above, it seemed I would be able to create a
> client object at startup, which could cache 'currently'
> authenticated users (cleanup on the configured timeout), saving a
> lot of database accesses. As yet I have not been able to test the
> usefulness of this approach however as I can't seem to get off the
> ground, getting tangled with errors in configuration.

you might want to re-think this approach entirely.

your user object cache will be per-apache child. that means if you
startup with a cache, and have 5 children, they all clone from that
cache. but when you start updating / editing the information, the
memory gets unshared. new users will be authenticating against your
db for each child they use too.

in other words, you're working your ass off for something that will
get you - at best - a marginal improvement.

what you need is some sort of shared system that can support multiple
apache children (and possibly servers. you might actually want a
cluster at some point)

some ideas:
a- screw db access concerns. use mysql to handle that sort of
access. i use postgres, and often do stuff like sessions, etc in
mysql -- its really fast on selects and where stability doesn't count.
b- cache your users in a daemon. stash your authenticated user data
in something like memcached, then just query that. its faster than
even mysql select, and super easy to implement.

// Jonathan Vanasco

| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -

Re: Problem using PerlSection and global object in conf

On Thu, 2007-01-04 at 17:13 -0500, Sean P Quinlan wrote:
> And here is the relevant portions of my configuration file (located in
> conf.d/):
>
> $Apache2::PerlSections::Save = 1;
> use CAS::Apache::Auth;
>
> # The default CAS client for the admin location
> $CAS_admin_client = 1;
> $Auth_admin = CAS::Apache::Auth->new({CLIENT_ID => $CAS_admin_client});
>

Put that in a namespace so it won't get interpreted as a directive:
$My::Auth_admin = CAS::Apache::Auth->new({CLIENT_ID =>
$CAS_admin_client});

Then assign $My::Auth_admin instead of $Auth_admin.

I'm just guessing here, since I don't use PerlSections or method
handlers on instances, but that's what it looks like to me from the
docs.

> Oops, I'm calling the method instead of setting it as a handler.
> Perhaps setting it as a coderef? So I changed PerlAuthenHandler to:
> PerlAuthenHandler => \$Auth_admin->authen,

When you use it in a regular config directive, it gets treated as a
string. In a PerlSection, it is eval'ed as perl. In this context, I
think you'd need to change it to something like this:

PerlAuthenHandler => sub { $Auth_admin->authen },

or maybe even this:

PerlAuthenHandler => sub { CAS::Apache::Auth->authen($Auth_admin) },

- Perrin

Re: Problem using PerlSection and global object in conf

--=-FvfdYYC0TLNpcEOzDXRU
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

First off, let me apologize to everyone for not responding last night. I
got a bounce message back and I assumed (yeah yeah) that it had not made
it to the list. Not long after writing this email, I noticed a
difference in the example in the docs to my code. I was creating an
object in the current name space, while the example was stuffing it into
some apparently arbitrary name space (Bird::Global). For whatever
reason, Getting the variable out of the confs name space is _required_
for this to function, but that is not documented; or if it is, I hadn't
seen it anywhere yet, and certainly isn't stated in the example.

So, I got past that hurdle last night, but didn't come check the list
mailbox again until this morning. I'll respond to some other points made
below and in any other responses.

On Thu, 2007-01-04 at 17:47 -0500, Jonathan Vanasco wrote:

> On Jan 4, 2007, at 5:13 PM, Sean P Quinlan wrote:
>
> > The way the new version is designed, a 'client' object will cache
> > the user objects (relatively small, name, email, phone etc) for
> > users previously authenticated, using a session token as a key.
> > Reading the document above, it seemed I would be able to create a
> > client object at startup, which could cache 'currently'
> > authenticated users (cleanup on the configured timeout), saving a
> > lot of database accesses. As yet I have not been able to test the
> > usefulness of this approach however as I can't seem to get off the
> > ground, getting tangled with errors in configuration.
>
> you might want to re-think this approach entirely.
>


Well, the main reason I'm trying to do it this way in mod_perl is that
it would take advantage of the way the base class already works. Even
with no caching I would prefer this, as it allows my mod_perl modules to
work as relatively thin wrappers on the base code.


> your user object cache will be per-apache child. that means if you
> startup with a cache, and have 5 children, they all clone from that
> cache. but when you start updating / editing the information, the
> memory gets unshared. new users will be authenticating against your
> db for each child they use too.


True. While I hadn't really considered that, given that some processes
(like product QC) may have a user rapidly scanning over 100 pages in the
course of a few minutes (well, unless something was abnormal ;), even
this small gain is beneficial, if it isn't difficult to implement.


> in other words, you're working your ass off for something that will
> get you - at best - a marginal improvement.



Well, since in the end all I needed to solve this problem was to add
Foo::, most of the work was still in learning how to take advantage of
PerlSections anyway, so no loss.


> what you need is some sort of shared system that can support multiple
> apache children (and possibly servers. you might actually want a
> cluster at some point)



Shared across children could be useful. But I would be surprised if
sharing such small, transient objects across nodes would be worth the
trouble to code.


> some ideas:
> a- screw db access concerns. use mysql to handle that sort of
> access. i use postgres, and often do stuff like sessions, etc in
> mysql -- its really fast on selects and where stability doesn't count.
> b- cache your users in a daemon. stash your authenticated user data
> in something like memcached, then just query that. its faster than
> even mysql select, and super easy to implement.


Interesting! I'll go look into it.

Thanks!
--
Sean P Quinlan

--=-FvfdYYC0TLNpcEOzDXRU
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit








First off, let me apologize to everyone for not responding last night. I got a bounce message back and I assumed (yeah yeah) that it had not made it to the list. Not long after writing this email, I noticed a difference in the example in the docs to my code. I was creating an object in the current name space, while the example was stuffing it into some apparently arbitrary name space (Bird::Global). For whatever reason, Getting the variable out of the confs name space is _required_ for this to function, but that is not documented; or if it is, I hadn't seen it anywhere yet, and certainly isn't stated in the example.



So, I got past that hurdle last night, but didn't come check the list mailbox again until this morning. I'll respond to some other points made below and in any other responses.



On Thu, 2007-01-04 at 17:47 -0500, Jonathan Vanasco wrote:

On Jan 4, 2007, at 5:13 PM, Sean P Quinlan wrote:



> The way the new version is designed, a 'client' object will cache  

> the user objects (relatively small, name, email, phone etc) for  

> users previously authenticated, using a session token as a key.  

> Reading the document above, it seemed I would be able to create a  

> client object at startup, which could cache 'currently'  

> authenticated users (cleanup on the configured timeout), saving a  

> lot of database accesses. As yet I have not been able to test the  

> usefulness of this approach however as I can't seem to get off the  

> ground, getting tangled with errors in configuration.



you might want to re-think this approach entirely.

your user object cache will be per-apache child.  that means if you  

startup with a cache, and have 5 children, they all clone from that  

cache.  but when you start updating / editing the information, the  

memory gets unshared.   new users will be authenticating against your  

db for each child they use too.

in other words, you're working your ass off for something that will  

get you - at best - a marginal improvement.

what you need is some sort of shared system that can support multiple  

apache children (and possibly servers.  you might actually want a  

cluster at some point)

some ideas:

	a- screw db access concerns.  use mysql to handle that sort of  

access. i use postgres, and often do stuff like sessions, etc in  

mysql -- its really fast on selects and where stability doesn't count.

	b- cache your users in a daemon.  stash your authenticated user data  

in something like memcached, then just query that.  its faster than  

even mysql select, and super easy to implement.

Re: Problem using PerlSection and global object in conf

--=-MndBWXM8GUEvyIDMEQW2
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Thu, 2007-01-04 at 19:25 -0500, Perrin Harkins wrote:

> Put that in a namespace so it won't get interpreted as a directive:
> $My::Auth_admin = CAS::Apache::Auth->new({CLIENT_ID =>
> $CAS_admin_client});
>


*nodnod* Thanks!


> > Oops, I'm calling the method instead of setting it as a handler.
> > Perhaps setting it as a coderef? So I changed PerlAuthenHandler to:
> > PerlAuthenHandler => \$Auth_admin->authen,
>
> When you use it in a regular config directive, it gets treated as a
> string. In a PerlSection, it is eval'ed as perl. In this context, I
> think you'd need to change it to something like this:
>
> PerlAuthenHandler => sub { $Auth_admin->authen },
>
> or maybe even this:
>
> PerlAuthenHandler => sub { CAS::Apache::Auth->authen($Auth_admin) },


I'll try those variations, just to see what it takes for future
reference.

Thanks!!
--
Sean P Quinlan

--=-MndBWXM8GUEvyIDMEQW2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit








On Thu, 2007-01-04 at 19:25 -0500, Perrin Harkins wrote:

Put that in a namespace so it won't get interpreted as a directive:

$My::Auth_admin = CAS::Apache::Auth->new({CLIENT_ID =>

$CAS_admin_client});

> Oops, I'm calling the method instead of setting it as a handler.

> Perhaps setting it as a coderef? So I changed PerlAuthenHandler to: 

> 		PerlAuthenHandler => \$Auth_admin->authen,



When you use it in a regular config directive, it gets treated as a

string.  In a PerlSection, it is eval'ed as perl.  In this context, I

think you'd need to change it to something like this:



PerlAuthenHandler => sub { $Auth_admin->authen },



or maybe even this:



PerlAuthenHandler => sub { CAS::Apache::Auth->authen($Auth_admin) },