[MP2]: setting group for a request (require group ...)
Hello all,
I am writing a mod_perl authentication module (My::Auth).
This module sets the user using the Apache2::RequestRec::user method.
package My::Auth;
sub {
$r->user('getting the user in my module internal structure');
return OK;
}
In the Apache configuration file, I can use the configuration
PerlAuthHandler My::Auth
Require user user1
I would like to use my module in another configuration where group is
checked
PerlAuthHandler My::Auth
Require group group1
I can not find any mod_perl API method (Apache2::RequestRec::group ?) to set
the group. I only found Apache2::RequestRec::require method, but this method
only read the require configuration.
One way to solve the problem is the modify the My::Auth::handler method :
package My::Auth;
sub {
$r->user('getting the user in my module internal structure');
my $requires = $r->requires;
# here the code to verify authorization
return OK;
}
but I think this is a workaround:
. My::Auth::handler is an AUTHENTICATION handler
. the code to verify the AUTHORIZATION should have to be executed by the
httpd core.
How can I manage authorization in this case ?
Thanks
Re: [MP2]: setting group for a request (require group ...)
I would like to use my module in another configuration where group is
checked
PerlAuthHandler My::Auth
Require group group1
I can not find any mod_perl API method (Apache2::RequestRec::group ?) to set
the group.
that's right.
you have control over the user via the httpd (and thus mod_perl) API,
just as the user does via a dialogue box in their browser. but
mod_authz_owner maps that user to a group via standard unix gid methods.
I have no idea how this works on win32 ;)
I only found Apache2::RequestRec::require method, but this method
only read the require configuration.
One way to solve the problem is the modify the My::Auth::handler method :
package My::Auth;
sub {
$r->user('getting the user in my module internal structure');
my $requires = $r->requires;
# here the code to verify authorization
return OK;
}
but I think this is a workaround:
. My::Auth::handler is an AUTHENTICATION handler
yes - is the user who they say they are.
. the code to verify the AUTHORIZATION should have to be executed by the
httpd core.
exactly :)
your wanting to do something with group is an authz function, not an
authen function.
How can I manage authorization in this case ?
the 'Require group foo' directive explicity means you want unix user ->
unix group mapping done in the authz phase. if you want something from
this different write your own PerlAuthzHandler. see recipe 3.16 here
http://www.modperlcookbook.org/chapters/ch13.pdf
it's mod_perl 1.0 based, but the ideas are the same, and the techniques
and API nearly identical.
HTH
--Geoff
bug report: wrong line number if using built-in functions
-8<-- Start Bug Report 8<-- 1. Problem Description: Line numbers will be wrong if a bulit-in function's first parameter is not in the same line. Minimized example: 01: #!/usr/local/bin/perl 02: use strict; 03: use warnings; 04: 05: abs 06: 07:5; 08: 09: die __LINE__; 10: 11: __END__ Expected line is 9. Result is 11. -> Warnings and dies give wrong line numbers. Finding errors is difficult so. 2. Used Components and their Configuration: *** mod_perl version 2.02 *** using /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/Apache2/Bui ldConfig.pm *** Makefile.PL options: MP_APR_CONFIG => /usr/bin/apr-1-config MP_APR_LIB => aprext MP_APXS=> /usr/sbin/apxs MP_COMPAT_1X => 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_USE_DSO => 1 *** The httpd binary was not found *** (apr|apu)-config linking info -laprutil-1 -lldap -llber -ldb-4.3 -lexpat -lapr-1 -lpthread -ldl *** /usr/bin/perl -V Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=linux, osvers=2.6.18-53.1.4.el5, archname=x86_64-linux-thread-multi uname='linux dhcp6-189.pnq.redhat.com 2.6.18-53.1.4.el5 #1 smp wed nov 14 10:37:27 est 2007 x86_64 x86_64 x86_64 gnulinux ' config_args='-des -Doptimize=-O2 -g -Dversion=5.8.8 -Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Dprivlib=/usr/lib/perl5/5.8.8 -Dsitelib=/usr/lib/perl5/site_perl/5.8.8 -Dvendorlib=/usr/lib/perl5/vendor_perl/5.8.8 -Darchlib=/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi -Dsitearch=/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi -Dvendorarch=/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-mult i -Darchname=x86_64-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r _proto -Dinc_version_list=5.8.7 5.8.6 5.8.5 -Dscriptdir=/usr/bin' 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=define use64bitall=define uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2 -g', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='4.1.2 20070626 (Red Hat 4.1.2-14)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags ='' libpth=/usr/local/lib64 /lib64 /usr/lib64 libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.5.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.5' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -O2 -g' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under linux Compiled at Feb 22 2008 01:27:07 %ENV: PERL_LWP_USE_HTTP_10="1" @INC: /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /us
Re: bug report: wrong line number if using built-in functions
Christian Mehring wrote:
-8<-- Start Bug Report 8<--
1. Problem Description:
Line numbers will be wrong if a bulit-in function's first parameter is not
in the same line.
Minimized example:
01: #!/usr/local/bin/perl
02: use strict;
03: use warnings;
04:
05: abs
06:
07:5;
08:
09: die __LINE__;
10:
11: __END__
Expected line is 9. Result is 11.
-> Warnings and dies give wrong line numbers. Finding errors is difficult
so.
I've been able to reproduce this problem, and it smells like it might be caused
by the
optmizer rolling that statement into a single line...
I don't have time to look much into this, but I've attached a patch to the test
case that illustrates the problem, in case anybody else want to have a shot at
this.
--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/
Index: t/line.t
===
--- t/line.t(revision 0)
+++ t/line.t(revision 0)
@@ -0,0 +1,35 @@
+use strict;
+use warnings FATAL => 'all';
+
+use Apache::Test;
+use Apache::TestUtil qw(t_cmp t_catfile_apache t_client_log_error_is_expected);
+use Apache::TestRequest;
+use Apache::TestConfig ();
+
+my %modules = (
+registry=> 'ModPerl::Registry',
+registry_bb => 'ModPerl::RegistryBB',
+perlrun => 'ModPerl::PerlRun',
+);
+
+my @aliases = sort keys %modules;
+
+my $vars = Apache::Test::config()->{vars};
+my $script_file = t_catfile_apache $vars->{serverroot}, 'cgi-bin', 'line.pl';
+
+plan tests => @aliases * 1;
+
+# In some cases, looks like the optimizer throws off our line numbers
+# line nn filename doesn't seem to work all the time
+for my $alias (@aliases) {
+my $url = "/$alias/line.pl";
+
+( my $cmdline = `$^X $script_file` ) =~ /(LINE:\d+)/;
+my $line = $1;
+
+ok t_cmp(
+GET_BODY($url),
+$line,
+"$modules{$alias} basic cgi test",
+);
+}
Index: t/cgi-bin/line.pl
===
--- t/cgi-bin/line.pl (revision 0)
+++ t/cgi-bin/line.pl (revision 0)
@@ -0,0 +1,7 @@
+#!/usr/local/bin/perl
+print "Content-type: text/plain\n\n";
+my $abs = abs
+
+0; # Something funny happens to reported line numbers
+ # (optimizer playing with us here ?)
+print "LINE:" . __LINE__ ; # Should print '9'
signature.asc
Description: OpenPGP digital signature
wrote Authen module dealing with cookies : now POST requests get corrupted. Any advice ?
Hi everybody, I recently wrote an extension to Apache2::AuthenNTLM in order to store the NTLM authentified username in a cookie (module http://search.cpan.org/dist/Apache2-AuthenNTLM-Cookie/). Now I found out that this module has a critical bug : the content of POST requests gets corrupted (bug http://rt.cpan.org/Ticket/Display.html?id=36847). I don't really know where to start to fix the bug. My hypothesis is that perhaps this is because I'm using Apache2::Cookie, which itself uses libaprequest, and maybe these modules are not meant to be used in an early Apache phase, and leave the input stream in an buggy state. I looked at a couple of other authentication modules using cookies, but they don't seem to use the Apache2::Cookie API. Is that the hypothesis correct ? Does anybody have good advice on that problem ? Thanks in advance, Laurent Dami
