Re: Any known gotchas with sending cookies?
This works fine for the first access. Subsequently, I wipe out the
backend database to see if a new session is correctly created. A new
session is created as expected, but the problem is that the new cookie
does not seem to stick to the browser. I've verified that this doesn't
...
Is there any known gotchas for this type of thing? Or am I missing
something?
Could this be a redirection problem? One gotcha that I learned was that:
my $method = ($is_redirection) ? 'err_headers_out' : 'headers_out';
$r-$method-add(Set-Cookie = $cookie-as_string);
I don't know if this is similar to what I did, but here you go anyhow:
sub hash_to_cookies {
my ($r, $hashref) = @_;
my $is_redirection = (@_) ? shift : undef;
my $method = ($is_redirection) ? 'err_headers_out' : 'headers_out';
# From Apache::Cookie documentation:
# $cookie-bake is same as $r-err_headers_out-add(Set-Cookie =
$cookie-as_string);
# Guide: You should use err_headers_out() and not headers_out()
# when you want to send cookies in the REDIRECT response.
my ($cookie);
foreach my $key (keys %{$hashref}) {
$cookie = Apache::Cookie-new( $r,
-name = $key,
-value = $hashref-{$key},
-path = '/');
$r-$method-add(Set-Cookie = $cookie-as_string);
}
}
sub hash_to_cookies_OK {hash_to_cookies(@_);}
sub hash_to_cookies_REDIRECT {hash_to_cookies(@_, 1);}
--
Kari Nurmela,
[EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547
Disabling Perl*Handlers in .htaccess?
Hello!
How to enable only PerlSetVar/PerlAddVar directives in .htaccess files?
More specific:
We are building an multiuser environment with mod_perl to our
campus. Mod_perl handlers contain especially PerlHandlers configured in
httpd.conf. The .htaccess files are used for authorization (require
user/group) and some tailoring (PerlSetVar/PerlAddVar) allowed for all
users at their home directories.
However, the security risks are quite obvious when .htaccess contains
directives like PerlHandler:
PerlHandler sub {`touch /tmp/xxx`}
How to enable only PerlSetVar/PerlAddVar directives in .htaccess files?
--
Kari Nurmela,
[EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547
SegFault report with backtrace
Hello! Here is a simple Test.pm handler that causes segfaults in our server. The Test.pm uses XS for creating configuration settings. The purpose is to set 'Testing' flag on or off in .htaccess files. I tried to make the module as simple as possible. The specifications are in the attachments files. sf_install.txt contains the information about the mod_perl compilation and the test module. sf_case1.txt contains the backtrace in Mandrake 8.1 with perl 5.6.1 while the sf_case2.txt contains the backtrace from Debian 2.2 with perl 5.005_3. To sum up the attachments, the error_log gives warnings like: [debug] mod_perl.c(1322): [warning] PerlFixupHandler stack is not an ARRAY! and the backtrace gives information like: ... type=0x81264d4 SERVER_CREATE) at perl_config.c:896 The segfault problems seems to haunt me whenever I try to create new configuration directives. In fact the different and unsolved segfaults have made me test many combinations with different versions of linux, perl, apache and mod_perl during the last year. Maybe better luck with solaris? Too bad that propably the fault lies with me. Of course, I'm more than happy to test/give more info about the segfault problem! Best wishes, -- Kari Nurmela, [EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547 University of Turku, Finland CASE 2 == Debian 2.2 (stable) Linux aura 2.2.19pre17-compact #1 Mon Apr 2 01:35:19 PDT 2001 i586 unknown perl -V: Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=linux, osvers=2.2.15pre14, archname=i386-linux uname='linux them 2.2.15pre14 #2 smp mon mar 13 14:29:00 est 2000 i686 unknown ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O2 ', gccversion=2.95.2 2313 (Debian GNU/Linux) cppflags='-Dbool=char -DHAS_BOOL -D_REENTRANT -DDEBIAN -I/usr/local/include' ccflags ='-Dbool=char -DHAS_BOOL -D_REENTRANT -DDEBIAN -I/usr/local/include' stdchar='char', d_stdstdio=undef, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldbm -ldb -ldl -lm -lc -lposix -lcrypt libc=, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Built under linux Compiled at Apr 30 2000 12:08:38 %ENV: PERLPREFIX=/usr/local/wm5/perl @INC: /usr/lib/perl5/5.005/i386-linux /usr/lib/perl5/5.005 /usr/local/lib/site_perl/i386-linux /usr/local/lib/site_perl /usr/lib/perl5 . BACKTRACE = [karnurme@sapphire apache]$ gdb /usr/local/wm5/apache/bin/httpd (gdb) run -X -f /usr/local/wm5/apache/conf/httpd.conf -d /usr/local/wm5/apache Starting program: /usr/local/wm5/apache/bin/httpd -X -f /usr/local/wm5/apache/conf/httpd.conf -d /usr/local/wm5/apache (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x807dad2 in perl_get_module_ptr () (gdb) bt #0 0x807dad2 in perl_get_module_ptr () #1 0x807ddb5 in perl_get_module_ptr () #2 0x807e132 in perl_cmd_perl_TAKE123 () #3 0x807da09 in perl_cmd_perl_FLAG () #4 0x8097e84 in ap_clear_module_list () #5 0x8098151 in ap_handle_command () #6 0x80981ed in ap_srm_command_loop () #7 0x8098a92 in ap_parse_htaccess () #8 0x80aa022 in ap_send_error_response () #9 0x80ab457 in ap_some_auth_required () #10 0x80ab916 in ap_process_request () #11 0x80a2880 in ap_child_terminate () #12 0x80a2a41 in ap_child_terminate () #13 0x80a2bbc in ap_child_terminate () #14 0x80a322c in ap_child_terminate () #15 0x80a3a5c in main () #16 0x400d4a42 in __libc_start_main () from /lib/libc.so.6 (gdb) karnurme@aura:~/wm5$ less apache/logs/error_log [Mon Nov 5 17:02:45 2001] [notice] Apache/1.3.20 (Unix) mod_perl/1.26 configured -- resuming normal operations [Mon Nov 5 17:03:22 2001] [notice] child pid 12686 exit signal Segmentation fault (11), possible coredump in /usr/local/wm5/apache BACKTRACE WITH NEW LIBPERL == cd apache_1.3.20/src/modules/perl rm *.[oa] make LIBPERL=libperld.a cp libperl.a /usr/lib/perl5/5.005/i386-linux/ cd mod_perl-1.26/ make install (gdb) run -X -f `pwd`/t/conf/httpd.conf
Segfault question and possible workaround
Hello!
Some help and ideas are once again needed...
I'm quite a newbie with mod_perl, so there may be a totally
reasonable explanation to segfaults that follow from a few reloads.
It seems to me that subrequest and/or stat do not work together as
I thought.
##
[Tue May 8 12:32:08 2001] [notice] child pid 1357 exit signal Segmentation fault (11)
##
package Apache::WorkMates::AutoIndex;
use strict;
use Apache::Constants qw(:common DIR_MAGIC_TYPE);
sub handler {
my $r = shift;
return DECLINED unless $r-content_type and $r-content_type eq DIR_MAGIC_TYPE;
$r-send_http_header('text/plain');
opendir DIR, $r-filename;
my @filelist = readdir DIR;
closedir DIR;
foreach my $file (@filelist) {
my $subr = $r-lookup_file($r-filename . '/' . $file);
my $fstat = [ stat $subr-finfo ];
}
$r-print(Kukkuu!);
return OK;
}
1;
##
A very quick check with the following seems to fix it,
but I haven't tested it that much.
foreach ... {
my $real_file = $r-filename . '/' . $file;
my $fstat = [ stat $real_file ];
}
The first code is used in Apache::AutoIndex also, because
my own autoindex owns a lot to Philippe M. Chiasson (Thanks Philippe!).
So maybe some Apache::AutoIndex users have got similar segfaults?
Now there is some information about configuration:
##
diff httpd.conf.default httpd.conf
950a951,954
PerlModuleApache::WorkMates::AutoIndex
PerlHandler Apache::WorkMates::AutoIndex
##
gdb /usr/local/wm5/apache/bin/httpd
(gdb) run -X -f /usr/local/wm5/apache/conf/httpd.conf
Starting program: /usr/local/wm5/apache/bin/httpd -X -f
/usr/local/wm5/apache/conf/httpd.conf
Program received signal SIGSEGV, Segmentation fault.
0x8112181 in Perl_dounwind ()
(gdb) bt
#0 0x8112181 in Perl_dounwind ()
#1 0x811249c in Perl_die_where ()
#2 0x80ef440 in Perl_croak ()
#3 0x80fcb93 in Perl_sv_upgrade ()
#4 0x80ce0ad in Perl_gv_init ()
#5 0x80cf184 in Perl_gv_fetchpv ()
#6 0x8091689 in XS_Apache_finfo ()
#7 0x80fba4b in Perl_pp_entersub ()
#8 0x81277b0 in Perl_runops_standard ()
#9 0x80cb7c9 in perl_call_sv ()
#10 0x8084430 in perl_call_handler ()
#11 0x8083bc2 in perl_run_stacked_handlers ()
#12 0x8081fb0 in perl_handler ()
#13 0x809f799 in ap_invoke_handler ()
#14 0x80b40df in process_request_internal ()
#15 0x80b4146 in ap_process_request ()
#16 0x80ab086 in child_main ()
#17 0x80ab241 in make_child ()
#18 0x80ab3bc in startup_children ()
#19 0x80aba2c in standalone_main ()
#20 0x80ac25c in main ()
#21 0x2ab91dcc in __libc_start_main () from /lib/libc.so.6
(gdb)
##
Same compiler for perl, apache and mod_perl.
mod_perl-1.25
=
$WM5DIR/perl/bin/perl Makefile.PL \
PERL_DEBUG=1 \
EVERYTHING=1 \
APACHE_SRC=../$APACHEDIR/src \
DO_HTTPD=1 \
USE_APACI=1 \
APACI_ARGS='--enable-module=rewrite,--enable-module=so'
make make test make install
(make test 100% successful)
apache_1.3.19
=
./configure --prefix=$WM5DIR/apache \
--activate-module=src/modules/perl/libperl.a \
--enable-module=rewrite \
--enable-module=so \
--disable-rule=EXPAT
make
make install
perl5.005_03
Compiled with -Dprefix=/usr/local/wm5/perl -des -Uusrbinperl
perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
Platform:
osname=linux, osvers=2.2.19, archname=i686-linux
uname='linux saphire.kas.utu.fi 2.2.19 #1 thu apr 5 15:18:02 est 2001 i686 unknown
'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='cc', optimize='-O2', gccversion=2.95.2 2220 (Debian GNU/Linux)
cppflags='-Dbool=char -DHAS_BOOL -I/usr/local/include'
ccflags ='-Dbool=char -DHAS_BOOL -I/usr/local/include'
stdchar='char', d_stdstdio=undef, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldbm -ldb -ldl -lm -lc -lcrypt
libc=, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Built under linux
Compiled at May 8 2001 03:04:44
@INC:
/usr/local/wm5/perl/lib/5.00503/i686-linux
/usr/local/wm5/perl/lib/5.00503
/usr/local/wm5/perl/lib/site_perl/5.005/i686-linux
/usr/local/wm5/perl/lib/site_perl/5.005
.
--
Kari Nurmela,
[EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547
Re: Child keeps seg faulting
Hi! I have had similar problems with Linux. I have tried with different combinations: * perl versions 5.005_3, 5.6.0, 5.6.1, ActivePerl 5.6.0 * apache versions from 1.3.9 - 1.3.19 * with and without dso * never with php The combination that seems to work now for us is apache_1.3.14, mod_perl-1.24_01, mod_ssl-2.7.1-1.3.14, openssl-0.9.6, ApacheJServ-1.1.2 and 5.005_03 built for i386-linux. All are compiled statically in RedHat 6.2 with updates. Now I have two candidates for the possible cause: * the order in which the modules are loaded * autoindex (I use Apache::AutoIndex 0.08) To test with the module order, I put ClearModuleList in the top of the httpd.conf and then add with 'AddModule' all the modules (by running 'httpd -l'). Make sure that the mod_perl is the last module to be loaded. Now (all?) the earlier segfaults are gone. Maybe the installation loads the modules in a different order? Maybe ClearModuleList clears things? ;-) To test the autoindex, I have used Apache::AutoIndex. When using it (without the earlier ClearModuleList thing!) I got child segfaults, but commenting the module helped to get dirlist working. I don't think there is something wrong with the Apache::AutoIndex. I just think that it may have something to do with the earlier module loading order. Maybe Apache::AutoIndex cannot get initialized because the wrong order? Anyway, there seem to be quite a lot discussion about this and one of the most interesting url was: http://groups.google.com/groups?hl=enlr=lang_ensafe=offic=1th=2f313f40da3371e1seekm=3A8D2990.ECF363B9%40zrz.TU-Berlin.de (from groups.google.com with 'segmentation AddModule mod_perl' you can find others) Best luck! -- Kari Nurmela, [EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547
HELP: testing access with different methods
Hello! This seems like a simple thing, but somehow I cannot make it work... In spite that this is propably a FAQ, I didn't find a solution. How to test access to the given url with the given method? For example, is the current user allowed to POST into /some/dir/file.document ? Sounds like a subrequest, but doesn't it need some method setting before $r-lookup_uri? Please, make my day! -- Kari Nurmela, [EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547
AuthCookie consulting Basic for AuthZ?
Hello! I' m using AuthCookie for authentication, but I would like to use all the normal authorization possibilities in .htaccess files (especially 'require group', Limit and LimitExecpt). Do I have to implement all the handling of .htaccess directives in my AuthCookie-derived module? Is it possible to ask the Apache's Basic auth to do the authorization? A subrequest with some special headers maybe? Am I totally lost with this one? In my case the cookie does not contain the password neiher there is any flat user file (nor group file). So maybe some kludge must be done to give the Basic auth headers all the information needed (for example base64 coded username:password)? Any help greatly appreciated!!! -- Kari Nurmela, [EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547
