Re: [ANNOUNCE] mod_perl-2.0.11
On 10/16/19 5:55 AM, André Warnier (tomcat) wrote: > On 16.10.2019 05:57, Randolf Richardson wrote: > The change is drastic. The best perl documentation resource in that > respect may be > https://metacpan.org/pod/distribution/Apache-AuthCookie/README.apache-2.4.pod This keeps coming up. If someone wants to scrape those docs and include them in the mod_perl dist, you have my full blessing to do so. My time is somewhat limited due to family life and job at present, and I'm honestly not sure who to contact to get this done. Regards, Michael Schout (AuthCookie maintainer)
Re: Apache 2.4 Authentication/Authorization
On 5/15/19 8:42 AM, André Warnier (tomcat) wrote: > (In any case, it does /not/ call the perl AuthzProvider again). > (That is not really what I want; I'd like it to call authz_user() Apache doesn't work that way. Everything you've described is basically just how things work in 2.4. your authz_user() will be called (up to) two times. 1. Before authentication where $r->user is not set. The purpose of this is to allow you to handle *anonymous* authorization. You can return AUTHZ_GRANTED here and no authentication will happen at all I believe. 2. Or, you can return AUTHZ_DENIED_NO_USER, which will trigger authentication, and *only if that succeeds*, will your authz_user() be called a second time. > anyway, and let authz_user() decide what happens next). Yeah, Apache just doesn't work this way. The only way to hack this that I can think of is for you to set something in $r->user that indicates that the authentication failed and authz_user could figure out what went wrong in the second call based on the value of $r->user. That's all you have to go on. You might even be able to use pnotes() to stash away extra stuff you need, but this feels like a horrible hack IMO. It's not particularly clear to me what "let authz_user() decide what happens next" means in this context. If authorization fails, typically you would just return an error code such as Apache2::Const::SERVER_ERROR. If it was successful, and the user is valid, you'd return Apache2::Const::OK. Otherwise you would typically return Apache2::Const::UNAUTHORIZED. If you to customize what is displayed for those messages, typically you use $r->custom_response() (see Apache2::Response). In today's times, when compared to modern alternatives like Plack/PSGI, this all feels very cumbersome and antiquated IMO. Regards, Michael Schout
Re: Compile mod_perl 1.0 on ubuntu 12.04 or later
On 2/22/19 10:54 AM, Matthias Schmitt wrote:
> I doubt that you will be able to compile mod_perl 1.x with newer compilers
> and operating systems.
Hold my beer :).
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS"
$ which httpd
/home/mschout/perl5/perlbrew/perls/perl-5.10.1-apache-1.3/bin/httpd
$ httpd -v
Server version: Apache/1.3.41 (Unix)
Server built: Feb 24 2019 16:43:18
And, it passes the Apache::AuthCookie test suite (provided you install
Apache::Test and Test::More@0.94). It identifies in the log as:
[notice] Apache/1.3.41 (Unix) mod_perl/1.32-dev configured
I'm actually somewhat suprised that it compiled.
Its *possible* :). But given how long 1.3 has been EOL'd, I *STRONGLY*
discourage anyone from using it. At a minimum update to Apache 2.2,
which, although also EOL'd at this point, at least got security updates
within the past year or so. You really need to migrate to 2.4.
That being said, you can build it if you apply the attached patches, as
part of the perlbrew+mod_perl setup I made for testing various versions
of apache and mod_perl over the years. For the curious, the process I
used here was:
$ perlbrew install -Accflags=-fPIC -v --noman --notest -j9 \
--as perl-5.10.1-apache-1.3 5.10.1
I used 5.10 in order to avoid dealing with any incompatibilities with
newer perls against apache 1.3.
$ perlbrew use perl-5.10.1-apache-1.3
$ cpanm -q --notest LWP::UserAgent
Then extract apache and mod_perl dists (I'm using apache 1.3.41,
mod_perl 1.31) and apply the attached patches to apache+mod_perl.
For mod_perl, apply the mod_perl-1.32.patch, which IIRC, I pulled from
the mod_perl svn trunk years ago.
The other two patches need to be applied to apache (apache-getline.patch
and gcc-inline-fix.patch).
I built this way:
$ perl Makefile.PL \
APACHE_SRC=path/to/apache-src/src \
DO_HTTPD=1 \
USE_APACI=1 \
PREP_HTTPD=1 \
EVERYTHING=1
$ cd /path/to/apache-src
$ bash ./configure --prefix=$PERLBREW_ROOT/perls/$PERLBREW_PERL \
--with-layout=Apache \
--enable-module=all \
--disable-module=auth_db \
--disable-module=auth_dbm \
--enable-shared=max \
--activate-module=src/modules/perl/libperl.a \
--disable-shared=perl \
--disable-rule=EXPAT \
--disable-rule=WANTHSREGEX
$ cd /path/to/apache-src
$ make install
$ cd /path/to/modperl-src
$ make install
I have a Makefile that does all of this. I suppose I could publish it
on github or something, but given the age of apache 1.3, it seems
irresponsible to publish it at this point :).
Regards,
Michael Schout
diff --git a/src/support/htdigest.c b/src/support/htdigest.c
index 7afb033..6758d99 100644
--- a/src/support/htdigest.c
+++ b/src/support/htdigest.c
@@ -70,7 +70,7 @@ static void getword(char *word, char *line, char stop)
while ((line[y++] = line[x++]));
}
-static int getline(char *s, int n, FILE *f)
+static int _getline(char *s, int n, FILE *f)
{
register int i = 0;
@@ -157,7 +157,7 @@ static void copy_file(FILE *target, FILE *source)
{
static char line[MAX_STRING_LEN];
-while (!(getline(line, MAX_STRING_LEN, source))) {
+while (!(_getline(line, MAX_STRING_LEN, source))) {
putline(target, line);
}
}
@@ -215,7 +215,7 @@ int main(int argc, char *argv[])
ap_cpystrn(realm, argv[2], sizeof(realm));
found = 0;
-while (!(getline(line, MAX_STRING_LEN, f))) {
+while (!(_getline(line, MAX_STRING_LEN, f))) {
if (found || (line[0] == '#') || (!line[0])) {
putline(tfp, line);
continue;
diff --git a/src/support/htpasswd.c b/src/support/htpasswd.c
index d3ce569..5f0565e 100644
--- a/src/support/htpasswd.c
+++ b/src/support/htpasswd.c
@@ -97,7 +97,7 @@ static char *tname_buf = NULL;
* Get a line of input from the user, not including any terminating
* newline.
*/
-static int getline(char *s, int n, FILE *f)
+static int _getline(char *s, int n, FILE *f)
{
register int i = 0;
@@ -546,7 +546,7 @@ int main(int argc, char *argv[])
char scratch[MAX_STRING_LEN];
fpw = fopen(pwfilename, "r");
- while (! (getline(line, sizeof(line), fpw))) {
+ while (! (_getline(line, sizeof(line), fpw))) {
char *colon;
if ((line[0] == '#') || (line[0] == '\0')) {
diff --git a/src/support/logresolve.c b/src/support/logresolve.c
index be92165..110dd7c 100644
--- a/src/support/logresolve.c
+++ b/src/support/logresolve.c
@@ -70,7 +70,7 @@
#endif /* !MPE && !WIN32*/
static void cgethost(struct in_addr ipnum, char *string, int check);
-static int getline(char *s, int n);
+static int _getline(char *s, int n);
static void stats(FILE *output);
@@ -277,7 +277,7 @@ static void stats (FILE *output)
* gets a line from stdin
*/
-static int getline (char *s, int n)
+static int _getline (char *s, int n)
{
char *cp;
@@ -325,7 +325,7 @@ int main (int argc, char *argv[])
for (i = 0; i &
Re: [a bit OT] AuthCookieDBI and Apache 2.4
On 2/21/19 3:41 AM, André Warnier (tomcat) wrote: > 1) the "authz" function is now called *first* (before any authentication > module has been called - even non-perl add-on ones), > and > 2) it *can* be called 2 or more times during the same request cycle > and Yes, and this allows you to do "Anonymous" authorization. If you don't want to do that, you simply do return Apache2::Const::AUTHZ_DENIED_NO_USER unless defined $r->user at the top of your Authz provider. The second time the handler is called, $r->user will be set so that you can authorize "authenticated" users. But this is indeed one of the major things that confuses people when moving to 2.4. Another common thing I've seen people do is return an invalid Apache2::Const value from an Authz provider. You must return one of a very specific list of values from the provider (See the README.apache-2.4 in AuthCookie which discusses this). > 5) there seems to be no real mod_perl-level (or even Apache-httpd-level) > documentation available, which explains the above in a general context, > rather than for any specific perl module. > A good explanation is provided by Michael Schout in > https://metacpan.org/pod/distribution/Apache-AuthCookie/README.apache-2.4.pod, I pieced this together, if my memory is correct, from apache mailing list posts, as well as reading the source code of apache itself. I'm not sure I found any definitive guide on the changes when I did this, and it involved a good deal of research at the time. I had hoped to see all of this codified into some kind of general mod_perl migration guide for Apache 2.4, similar to what happened when we all had to migrate from Apache 1.3 to Apache 2. Something similar to what is on perl.apache.org [1]. But I am unsure if that site is even maintained any longer. Anyway, another example of an authz provider is in AuthCookie [2], where I re-implemented apache's core authz provider, before realizing it was not needed. 1: https://perl.apache.org/docs/2.0/user/porting/compat.html 2: https://github.com/mschout/apache-authcookie/blob/master/lib/Apache2_4/AuthCookie.pm#L18 Regards, Michael Schout
Re: AuthCookieDBI and Apache 2.4
On 2/12/19 1:25 PM, Edward J. Sabol wrote: > I know AuthCookie has been updated by the magnificient Michael Schout to Thanks for the kind compliments Ed :). As for AuthCookieDBI, you may not even need to change it to use Apache2_4::AuthCookie base, as eventually I managed to get all of the changes needed to work togehter in Apache2::AuthCookie. I left Apache2_4::AuthCookie for historical reasons, and in case further issues came up that would require more changes that were 2.4 exclusive. If you aren't doing anything fancy with `require` directives, you likely don't need to worry about creating an Authz provider, which is where most of the issues are when moving to 2.4. Looking at AuthCookieDBI, it does implement support for `require group`, so if you need that, you will need to create an Authz provider that implements it. But if not, you can probably not worry about it. Hope this helps. Regards, Michael Schout
Re: Upgrading a mod_perl application from Apache 2.2 to Apache 2.4
On 12/6/18 9:25 AM, Andrew Green wrote:
> As far as I can tell, I have to pre-declare the new Authz provider in my
> server config:
>
> PerlAddAuthzProvider myapp MyApp::Authz
Yes this is correct, authz providers must be declared globally under 2.4
I realize this thread is old by now, but for the record, there is a bit
of documentation about how things changed/work under 2.4 in my
Apache2::AuthCookie dist [1]. The way authentication and authorization
works under 2.4 is quite different.
> b. Wrapping the return value like this:
>
> sub authz_granted {
>
> my $self = shift;
>
> # So this compiles under old Apache
> no strict 'subs';
>
> if ($self->is_old_apache) {
> return Apache2::Const::OK;
> } else {
> return Apache2::Const::AUTHZ_GRANTED;
> }
>
> }
Note that under 2.4, your authz handler gets called twice per request.
The first time, no user will be set, and this is so you can handle
authorization of anonymous requests. You should return
AUTHZ_DENIED_NO_USER for these requests (unless of course you want to
authorize anonymous requests, in which case you can return AUTHZ_GRANTED
etc). So something like:
unless (defined $r->user) {
return Apache2::Const::AUTHZ_DENIED_NO_USER;
}
If $r->user *is* set, then you are expected to return one of:
AUTHZ_DENIED
AUTHZ_GRANTED
AUTHZ_GENERAL_ERROR
AUTHZ_NEUTRAL
Also of note, if all you are doing is "Require valid-user", or "Require
user foo" for example, Apache provides an authz provider that already
handles that (see mod_authz_user.c). So you only need to do this if you
are writing custom authz requirements.
1:
https://metacpan.org/pod/release/MSCHOUT/Apache-AuthCookie-3.27/README.apache-2.4.pod
Regards,
Michael Schout
[Slightly OT] Apache::AuthCookie and mod_perl version 1.x
Hi folks. Sorry for this slightly off topic thread, but in the past announcements about AuthCookie were typically made to this list. I'm the maintainer of Apache::AuthCookie (and Apache2::AuthCookie) and am wondering if there are any people out there still using Apache::AuthCookie under mod_perl version 1.x (and as such apache 1.x)? Given that apache 1.3.42 was the final release of Apache 1.3, which was way back in 2010, I am hoping that everyone has moved on to Apache 2.x long ago. As a result, I would like to formally drop support for Apache 1.3 from future versions of Apache::AuthCookie. This would allow me to clean up the dist a bit, and be able to publish a consistent set of dependencies in META.* in the dist. If you really require Apache::AuthCookie under apache 1.3 at this point, you can get a previous version of AuthCookie from backpan to address that. If you really do need AuthCookie and getting it from backpan is a problem for you, please let me know. Thanks! Regards, Michael Schout
Re: Where is the mod_perl development repo?
On 3/9/17 2:52 AM, André Warnier wrote: > If I understand the general idea correctly, it consists of no longer > running complicated and memory-hungry things directly in Apache through > mod_perl, but to use Apache as a front-end reverse proxy, and proxy such > calls to one or more back-end processes having their own persistent perl > (or other) interpreter. Is that correct ? Pretty much. Except its much more common to see something like nginx acting as the proxy than Apache due to nginx's lighter footprint and better handling of large numbers of concurrent connections. If you are writing a Perl (5) web app these days, you should probably write it using Plack/PSGI compatible framework (dancer, mojo, catalyst etc) and run it under something like starman behind nginx (or apache or any other http proxy that you prefer). If you do not wish to use a framework, then just write it in plain Plack/PSGI. Regards, Michael Schout
Re: [RELEASE CANDIDATE] mod_perl-2.0.10 RC1
On 9/30/16 8:53 AM, Michael Schout wrote: > On 9/30/16 8:13 AM, Steve Hay wrote: >> Please download, test, and report back on this mod_perl 2.0.10 release >> candidate. > > There is some kind of linker failure happening on OSX/Darwin. I'm on El > Capitan (10.11) using perl 5.20 and get all kinds of duplicate symbol > errors. I'll see if I can figure out where this broke. Ok this seems to be caused by putting MP_vtbl_env and MP_vtbl_envelem in the modperl_env.h header and removal of "static" qualifier for these structs. Presumably this was done to be threaded perl friendly? Anyway, I made the compiler happy by adding "extern" in the header: --- mod_perl-2.0.10-rc1/src/modules/perl/modperl_env.h 2016-09-30 07:45:25.0 -0500 +++ mod_perl-2.0.10-rc1.osx/src/modules/perl/modperl_env.h 2016-09-30 11:39:05.0 -0500 @@ -62,8 +62,8 @@ void modperl_env_unload(pTHX); -MGVTBL MP_vtbl_env; -MGVTBL MP_vtbl_envelem; +extern MGVTBL MP_vtbl_env; +extern MGVTBL MP_vtbl_envelem; #endif /* MODPERL_ENV_H */ I also need the "no APR_INLINE" patch on OS X, to get it to compile but that's nothing new: --- mod_perl-2.0.4.orig/src/modules/perl/modperl_common_util.h 2007-12-31 01:23:36.0 -0600 +++ mod_perl-2.0.4/src/modules/perl/modperl_common_util.h 2012-09-11 21:56:40.0 -0500 @@ -22,7 +22,7 @@ #ifdef MP_DEBUG #define MP_INLINE #else -#define MP_INLINE APR_INLINE +#define MP_INLINE #endif #ifdef CYGWIN I *do* get test failures on OS X, but to be fair 2.0.9 produces even MORE failures so 2.0.10 is actually an improvement in that regard :). Regards, Michael Schout
Re: [RELEASE CANDIDATE] mod_perl-2.0.10 RC1
On 9/30/16 8:13 AM, Steve Hay wrote: > Please download, test, and report back on this mod_perl 2.0.10 release > candidate. There is some kind of linker failure happening on OSX/Darwin. I'm on El Capitan (10.11) using perl 5.20 and get all kinds of duplicate symbol errors. I'll see if I can figure out where this broke. duplicate symbol _MP_vtbl_env in: mod_perl.lo modperl_interp.lo duplicate symbol _MP_vtbl_envelem in: mod_perl.lo modperl_interp.lo duplicate symbol _MP_vtbl_env in: mod_perl.lo modperl_tipool.lo duplicate symbol _MP_vtbl_envelem in: mod_perl.lo modperl_tipool.lo duplicate symbol _MP_vtbl_env in: mod_perl.lo modperl_config.lo duplicate symbol _MP_vtbl_envelem in: mod_perl.lo modperl_config.lo Regards, Michael Schout
Re: Looking for solution to Apache2::AuthCookieDBI authentication on Apache > 2.4
On 8/24/16 7:40 AM, Tosh Cooey wrote: > Hi, I've taken a stab at updating Apache2::AuthCookieDBI myself as per: > > http://search.cpan.org/~mschout/Apache-AuthCookie/README.apache-2.4.pod > > I've changed the parent of Apache2::AuthCookieDBI to > Apache2_4::AuthCookie but that doesn't seem to work, even with the > http.conf changes noted: Hard to know what exactly doesn't work from what you've given us. What is in the error log for example? > PerlAddAuthzProvider user Apache2::AuthCookieDBI->authz_handler You can remove this line. apache provides a "user" authz handler already. You only need PerlAddAuthzProvider if you have required something other than "user" or valid-user. There is a new version of Apache2::AuthCookie that will hit CPAN later today that addresses a few issues (notably, directory indexes were broken under Apache 2.4), but that doesn't sound like what you have been seeing. -- Regards, Michael Schout
Re: question on Apache2_4::AuthCookie
On 4/6/16 11:51 AM, A. Warnier wrote: > I could of course hack the values of these constants under 2.4, and use > their values directly in my module, but that is rather "inelegant". If you insist on using the same module/source for both 2.4 and 2.2 I do not see any other option. The AUTHZ_GRANTED (and friends) constants simply do not exist in previous versions of apache. Regards, Michael Schout
Re: $r->requires and register_auth_provider
On 12/23/15 11:16 AM, Sergei Gerasenko wrote: > On the other hand, if you have 'require user u1 u2', then the 'requires' > argument is not an array but the string "u1 u2", which needs to be split. For what its worth, I have released AuthCookie v3.24 with a fix to the (AuthCookie) built in authz provider that handles "Require user" directives that now behaves more like the one in apache core. That is, it splits the string on whitespace and processes each username in turn, returning AUTHZ_GRANTED at the first match. This is exactly what mod_authz_user does. It is worth noting that although previous versions of AuthCookie said you must use: PerlAddAuthzProvider user Your::AuthCookie::Handler->authz_handler This is not actually true. If you do not specify a "user" authz provider, then the one provided by mod_authz_user will be used instead (and is preferrable). One other thing to be aware of in terms of how AAA works in Apache 2.4 is that your authz provider methods will *always* be called twice. First your authz provider will be called before authentication has been processed ($r->user is not set). This is to provide the opportunity to allow anonymous access. If you return AUTHZ_DENIED_NO_USER, then authentication will proceed and your authz_provider will be called a second time with $r->user set to the authenticated username. I have fleshed out the documentation for this in README.apache-2.4.pod in the AuthCookie dist, as well as in the Apache2_4::AuthCookie POD documentation. The AuthCookie documentation probably could be better, and I think by the next release I'll absorb/copy most of what is in the README.apache-2.4 document into the module POD itself. Regards, Michael Schout
Re: panic: attempt to copy freed scalar caused by calling cgi->param with TryCatch since perl 5.19.7
On 9/17/15 9:00 AM, John Dunlap wrote:
> I'm not using the TryCatch module in my application. I use eval blocks
> for all of my transaction management. For me to be suffering from the
> same ailment, the bug would have to manifest itself in other ways.
I don't think TryCatch *itself* is the problem. I was seeing
segmentation faults from other sections of code that did not use
TryCatch that the op.c change apparently also causes.
There is some other underlying problem that is causing this. You can
put other chunks of code inside the try { } block and the panic does not
happen. For some reason $cgi->param() inside the try *does* trigger it,
but it also needs to be called from a subroutine (e.g.: moving the try
block inside the handler() sub does not cause the panic. This all sort
of makes sense based on what the change to op.c does to the optree that
causes the bug (skips over "return" ops that do nothing basically)
In addition I had other segfaults that DO NOT issue the "panic" warning.
But reversing the optimization to op.c in perl fixes that for me also.
I haven't had time to really try to get into the modperl code enough to
know what is going on, but the backtrace from panic is coming from
copying scalars that have flags or something to that effect when leaving
a subroutine. I'm pretty sure modperl messes with scalar flags and/or
scalar magic due to previous experience with the mod_perl codebase a
long time ago so that might explain why this ONLY happens under modperl
and not under vanilla perl.
Also, TryCatch is implemented using Devel::Declare, which is admittedly
sneaky because it screws with the perl optree during compilation. The
part that was changed in op.c that causes the problems this thread is
about essentially "skip over" a couple of unnecessary ops as an
optimization.
So this is a bit long winded, but I kind of doubt TryCatch is the
problem. TryCatch+CGI->param called from a soubroutine just happens to
be one of the shortest, sure fire ways to trigger the panic that I have
found when I needed to make a test case to demonstrate the bug.
I suspect Devel::Declare was getting away with something that it
shouldn't be able to do, or, something in modperl at this time.
Is Devel::Declare a dependency anywhere in your codebase? E.g.: if you
have Devel/Declare.pm in your perl library path, will you code still run
if you remove Devel/Declare.pm? If so then that either means the
problem is probably in modperl itself, or, you are seeing something
completely different.
Regards,
Michael Schout
Re: panic: attempt to copy freed scalar caused by calling cgi->param with TryCatch since perl 5.19.7
On 9/17/15 8:13 AM, Vincent Veyron wrote: > Sep 17 15:08:31 eeepc kernel: [ 7737.194398] traps: /usr/sbin/apach[8769] > general protection ip:7f1199d45d70 sp:7ffe7e3dc410 error:0 in > PPAddr.so[7f1199d45000+2000] I saw these first as well on debian jessie. I fixed it by switching from mpm-event to mpm-prefork. I will say that I find debian's packaging to makes it pretty difficult with Apache::Test. Apache::Test fails to generate a working config because it does not source the Include files in /etc/apache2/mods-enabled (among other things). I much prefer to just build apache from scratch, which also eliminates the possibility that a vendor applied patch is causing any problems. Here is how I produced the panic on jessie, using nothing but vendor packages if you *really* do want to reproduce this: In fresh debian 8/jessie do this (I used a vagrant box): sudo apt-get update sudo apt-get install apache2-mpm-prefork libapache2-request-perl \ libapache2-mod-perl2 libapache2-mod-apreq2 \ apache2-dev git libtrycatch-perl git clone git://github.com/mschout/modperl-trycatch-bug cd modperl-trycatch-bug # now we have to jump through several hoops to make Apache::Test work # make symlinks that apache2.conf needs *sigh* ln -s /etc/apache2/mods-enabled t/mods-enabled ln -s /etc/apache2/conf-enabled t/conf-enabled # disable mpm-event and use mpm-prefork instead cd /etc/apache2/mods-enabled/ sudo rm -f mpm_event.* sudo ln -s ../mods-available/mpm_prefork.conf mpm_prefork.conf sudo ln -s ../mods-available/mpm_prefork.load mpm_prefork.load cd - # change IncludeOptional to Include sudo sed -i 's/IncludeOptional/Include/' /etc/apache2/apache2.conf # need to source apache2 envvars source /etc/apache2/envvars # now actually run the test perl Makefile.PL -apxs /usr/bin/apxs2 \ -httpd_conf /etc/apache2/apache2.conf make test ... which fails ... t/logs/error_log contains: [Thu Sep 17 20:08:09.333854 2015] [perl:error] [pid 10319] [client 127.0.0.1:60632] panic: attempt to copy freed scalar 7f4e0971ec80 to 7f4e0971eb30 at /home/vagrant/modperl-trycatch-bug/blib/lib/Apache/TryCatch.pm line 20.\n Regards, Michael Schout
Re: panic: attempt to copy freed scalar caused by calling cgi->param with TryCatch since perl 5.19.7
On 9/16/15 7:08 AM, Vincent Veyron wrote: > I put your test handler on a machine running Debian 8 (jessie), it works just > fine. Fails for me on both CentOS 7 and Darwin (OS X 10.10.5). I see you are using Apache 2.4 (I was using 2.2). I tested with Apache 2.4.16 and it also fails for me on that as well Server version: Apache/2.4.16 (Unix) Server built: Sep 16 2015 09:21:11 I built perl myself to rule out vendor applied patches to the perl dist. I wonder if one of the many patches debian applies to perl works around this issue somehow. Debian also applies a bunch of patches (18 as of current dpkg src) to the mod_perl package. Maybe one of those works around the issue. I'll sift through those patches and see if any of those help. Are you using debian packages for the CPAN modules at all? Or did you install all CPAN packages using a CPAN client? Because I also wonder if they patched TryCatch, Devel::Declare, or one of its dependencies to work around this issue. Here is the failure on CentOS 7, apache 2.4, perl 5.20.3, mod_perl 2.0.9, all built from scratch, no vendor packages used: [mschout@centos7 modperl-trycatch-bug]$ make test /home/mschout/perlbug/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -clean [warning] setting ulimit to allow core files ulimit -c unlimited; /home/mschout/perlbug/bin/perl /home/mschout/modperl-trycatch-bug/t/TEST -clean APACHE_TEST_APXS= APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= \ /home/mschout/perlbug/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -bugreport -verbose=0 [warning] setting ulimit to allow core files ulimit -c unlimited; /home/mschout/perlbug/bin/perl /home/mschout/modperl-trycatch-bug/t/TEST -bugreport -verbose=0 /home/mschout/perlbug/bin/httpd -d /home/mschout/modperl-trycatch-bug/t -f /home/mschout/modperl-trycatch-bug/t/conf/httpd.conf -D APACHE2 -D APACHE2_4 -D PERL_USEITHREADS using Apache/2.4.16 (prefork MPM) waiting 60 seconds for server to start: .. waiting 60 seconds for server to start: ok (waited 1 secs) server localhost:8529 started t/crash.t .. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/2 subtests t/logs/error_log [Wed Sep 16 09:27:19.394249 2015] [mpm_prefork:notice] [pid 4129] AH00163: Apache/2.4.16 (Unix) mod_perl/2.0.9 Perl/v5.20.3 configured -- resuming normal operations [Wed Sep 16 09:27:19.394372 2015] [mpm_prefork:info] [pid 4129] AH00164: Server built: Sep 16 2015 09:21:11 [Wed Sep 16 09:27:19.394381 2015] [core:notice] [pid 4129] AH00094: Command line: '/home/mschout/perlbug/bin/httpd -d /home/mschout/modperl-trycatch-bug/t -f /home/mschout/modperl-trycatch-bug/t/conf/httpd.conf -D APACHE2 -D APACHE2_4 -D PERL_USEITHREADS' [Wed Sep 16 09:27:19.394386 2015] [mpm_prefork:debug] [pid 4129] prefork.c(995): AH00165: Accept mutex: sysvsem (default: sysvsem) [Wed Sep 16 09:27:20.246297 2015] [authz_core:debug] [pid 4130] mod_authz_core.c(835): [client 127.0.0.1:46738] AH01628: authorization result: granted (no directives) [Wed Sep 16 09:27:20.498088 2015] [authz_core:debug] [pid 4130] mod_authz_core.c(835): [client 127.0.0.1:46739] AH01628: authorization result: granted (no directives) [Wed Sep 16 09:27:20.500796 2015] [perl:error] [pid 4130] [client 127.0.0.1:46739] panic: attempt to copy freed scalar 34259c0 to 3425870 at /home/mschout/modperl-trycatch-bug/blib/lib/Apache/TryCatch.pm line 20.\n [Wed Sep 16 09:27:20.526382 2015] [core:info] [pid 4129] AH00096: removed PID file /home/mschout/modperl-trycatch-bug/t/logs/httpd.pid (pid=4129) [Wed Sep 16 09:27:20.526398 2015] [mpm_prefork:notice] [pid 4129] AH00169: caught SIGTERM, shutting down But you are likely not seeing it because one of: - vendor patches applied by debian packaging team - you are using Apache 2.4. I tested with Apache 2.2. Regards, Michael Schout
Re: panic: attempt to copy freed scalar caused by calling cgi->param with TryCatch since perl 5.19.7
On 9/16/15 9:22 AM, Vincent Veyron wrote: > apt-get install apache2-mpm-prefork libapache2-request-perl > libapache2-mod-perl2 libapache2-mod-apreq2 How did you install TryCatch (the only dependency my module uses)? Regards, Michael Schout
Re: panic: attempt to copy freed scalar caused by calling cgi->param with TryCatch since perl 5.19.7
On 9/16/15 12:26 PM, Vincent Veyron wrote: > Ha! It was not installed. I suppose that because your test module was also > named TryCatch, Probably. > Not sure what to do now? Rename the crash module as /home/lib/Apache/TryCatch.pm make sure the "package" line still reads "package Apache::TryCatch;" or, unless you are planning to debug perl internals, mod_perl internals, and/or TryCatch/Devel::Declare to try to trace down the root cause of this problem, just move on. The bug is definitely there on jessie as per my previous email showing how I reproduced it. If you do want to reproduce it, use the same apache2.conf additions from my last email. Regards, Michael Schout
Re: panic: attempt to copy freed scalar caused by calling cgi->param with TryCatch since perl 5.19.7
On 9/16/15 12:06 PM, Steve Hay wrote: > Thanks for the detective work, Michael. I've logged this on > rt.perl.org since it isn't yet clear whether the optimization has a > problem, or whether mod_perl (or maybe TryCatch / Devel::Declare) is > doing anything naughty: Thanks Steve. Wouldn't surprise me if it was any of the three. I will try to do more debugging as time allows. Regards, Michael Schout
panic: attempt to copy freed scalar caused by calling cgi->param with TryCatch since perl 5.19.7
As reported in other thread, I've seen mod_perl emit panic warnings such
as the following ever since 5.19.7:
panic: attempt to copy freed scalar 7fb2264ffde0 to 7fb2264ffd08 at
/Users/mschout/Sync/Apache-TryCatch/blib/lib/Apache/TryCatch.pm line 20.
I've also seen random segementation faults caused by innocent looking
"return" statements in a large code base.
I've created a test mod perl handler that demonstrates this behaviour:
--
package Apache::TryCatch;
use Apache2::Const -compile => qw(OK);
use TryCatch;
use CGI;
sub handler :method {
my ($self, $r) = @_;
$r->content_type('text/plain');
print $self->crash($r);
return Apache2::Const::OK;
}
sub crash {
my $cgi = CGI->new;
try { $cgi->param(x => 'x') }
return "Hello World!";
}
1;
--
configured in httpd.conf as:
PerlModule Apache::TryCatch
PerlSwitches -I@ServerRoot/../lib
SetHandler perl-script
PerlResponseHandler Apache::TryCatch
--
Simply accessing /crashme causes a 500 internal server error and the
panic warning in the httpd error log.
I bisected against perl git, using mod_perl 2.0.9 and apache 2.2.29 as
the mod_perl environment, and installing TryCatch from cpan, and
discovered that the following perl commit is the culprit:
> commit 437e3a7dac994ebace1195549170c81f474d9c20
> Author: Matthew Horsfall <wolfs...@gmail.com>
> Date: Wed Dec 11 18:28:21 2013 -0500
>
> Optimise out PUSHMARK/RETURN if return is the last statement in a sub.
>
> This makes:
>
> sub baz { return $cat; }
>
> Behave like:
>
> sub baz { $cat; }
>
> Which is notably faster.
>
> Unpatched:
>
> ./perl -Ilib/ ~/stuff/bench.pl
> Benchmark: timing 4000 iterations of normal, ret...
> normal: 3 wallclock secs ( 1.60 usr + 0.01 sys = 1.61 CPU) @
> 24844720.50/s (n=4000)
>ret: 3 wallclock secs ( 2.08 usr + 0.00 sys = 2.08 CPU) @
> 19230769.23/s (n=4000)
>
> Patched:
>
> ./perl -Ilib ~/stuff/bench.pl
> Benchmark: timing 4000 iterations of aret, normal...
> normal: 2 wallclock secs ( 1.72 usr + 0.00 sys = 1.72 CPU) @
> 23255813.95/s (n=4000)
>ret: 2 wallclock secs ( 1.72 usr + 0.00 sys = 1.72 CPU) @
> 23255813.95/s (n=4000)
>
> The difference in OP trees can be seen here:
>
> Unpatched:
>
> $ perl -MO=Concise,baz -e 'sub baz { return $cat }'
> main::baz:
> 5 <1> leavesub[1 ref] K/REFC,1 ->(end)
> - <@> lineseq KP ->5
> 1<;> nextstate(main 1 -e:1) v ->2
> 4<@> return K ->5
> 2 <0> pushmark s ->3
> - <1> ex-rv2sv sK/1 ->4
> 3 <#> gvsv[*cat] s ->4
> -e syntax OK
>
> Patched:
>
> $ ./perl -Ilib -MO=Concise,baz -e 'sub baz { return $cat }'
> main::baz:
> 3 <1> leavesub[1 ref] K/REFC,1 ->(end)
> - <@> lineseq KP ->3
> 1<;> nextstate(main 1 -e:1) v ->2
> -<@> return K ->-
> - <0> pushmark s ->2
> - <1> ex-rv2sv sK/1 ->-
> 2 <$> gvsv(*cat) s ->3
> -e syntax OK
>
> (Includes some modifications from Steffen)
>
> ext/B/t/optree_samples.t | 18 +-
> op.c | 31 +++
> op.h | 6 ++
> 3 files changed, 54 insertions(+), 1 deletion(-)
Reverting the change to op.c completely fixes the problem. I cannot
reproduce the panic after this change, and I do not get any segmentation
faults either in a large codebase that I am also testing against.
This problem seems to be mod_perl specific as the try { $cgi->param() }
does not cause a panic when run outside of mod_perl.
In addition, not all try { } blocks cause the panic. It seems that
calling CGI.pm's param() method to set a value *does* cause it however.
If anyone has any ideas on what might be causing behaviour in mod_perl,
I'm all ears. I may try to dig into this, but I'm not familiar with
mod_perl internals so that may take quite some time. Admittedly,
TryCatch depends on Devel::Declare, which as I understand it makes
changes to the optree at runtime. I'm guessing there is some
interaction with the optree in mod_perl that TryCatch along with perl's
optimization that removes the "return" ops that is causing this.
I have put the test case as a module up on github so that anyone can
clone it to reproduce the bug. The repository is here:
https://github.com/mschout/modperl-trycatch-bug.git
The readme explains how to run it, but essentially its install a perl >=
5.19.7, install mod_perl, install TryCatch, and then the usual
"perl Makefile.PL && make test"
Regards,
Michael Schout
Re: Random segmentation fault
Steve, John:
I did a bisect today against perl git, using mod_perl 2.0.9 and apache
2.2.29 to find out where my two issues were caused. It turns out that
both of my problems, which were:
- panic: attempt to copy freed scalar to
and also
- segmentation fault caused by a specific "return" statement
Are *BOTH* caused by the following commit made to perl between 5.19.6
and 5.19.7:
> commit 437e3a7dac994ebace1195549170c81f474d9c20
> Author: Matthew Horsfall <wolfs...@gmail.com>
> Date: Wed Dec 11 18:28:21 2013 -0500
>
> Optimise out PUSHMARK/RETURN if return is the last statement in a sub.
>
> This makes:
>
> sub baz { return $cat; }
>
> Behave like:
>
> sub baz { $cat; }
>
> Which is notably faster.
...
I created a patch that reverses this (at least the change to op.c.. the
other parts of the patch are just new macros, and a test case), then
both of my problems are fixed.
John: I'd be interested to know if your problem is related. If
possible, can you build perl with the attached patch applied and see if
that fixes your segfault also?
This seems to be mod_perl specific. I have a very
straightforward/minimal test case that causes the "panic" error under
mod_perl, but the same code runs fine under the command line outside of
mod_perl.
Regards,
Michael Schout
diff --git a/op.c b/op.c
index 7038526..dc42b56 100644
--- a/op.c
+++ b/op.c
@@ -11354,45 +11354,6 @@ Perl_rpeep(pTHX_ OP *o)
case OP_NEXTSTATE:
PL_curcop = ((COP*)o); /* for warnings */
- /* Optimise a "return ..." at the end of a sub to just be "...".
-* This saves 2 ops. Before:
-* 1 <;> nextstate(main 1 -e:1) v ->2
-* 4 <@> return K ->5
-* 2<0> pushmark s ->3
-* -<1> ex-rv2sv sK/1 ->4
-* 3 <#> gvsv[*cat] s ->4
-*
-* After:
-* - <@> return K ->-
-* -<0> pushmark s ->2
-* -<1> ex-rv2sv sK/1 ->-
-* 2 <$> gvsv(*cat) s ->3
-*/
- {
- OP *next = o->op_next;
- OP *sibling = o->op_sibling;
- if ( OP_TYPE_IS(next, OP_PUSHMARK)
- && OP_TYPE_IS(sibling, OP_RETURN)
- && OP_TYPE_IS(sibling->op_next, OP_LINESEQ)
- && OP_TYPE_IS(sibling->op_next->op_next, OP_LEAVESUB)
- && cUNOPx(sibling)->op_first == next
- && next->op_sibling && next->op_sibling->op_next
- && next->op_next
- ) {
- /* Look through the PUSHMARK's siblings for one that
-* points to the RETURN */
- OP *top = next->op_sibling;
- while (top && top->op_next) {
- if (top->op_next == sibling) {
- top->op_next = sibling->op_next;
- o->op_next = next->op_next;
- break;
- }
- top = top->op_sibling;
- }
- }
- }
-
/* Optimise 'my $x; my $y;' into 'my ($x, $y);'
*
* This latter form is then suitable for conversion into padrange
Re: Random segmentation fault
On 9/11/15 2:26 PM, John Dunlap wrote: > I found a lot of stuff like the following in my Apache logs. Is it > possible to get this kind of output from Apache when the server runs > out of memory? I wouldn't have expected so. It has all the hallmarks > of something more sinister. For whatever its worth, I started seen random segfaults starting between 5.18 and 5.20 somewhere. I actually have a bizarre way to reproduce the one I see reliably by moving a return in my code. I'm not sure if mine is related to the segfault you are seeing, but you might try downgrading to 5.18 if that is an option and see if the problem goes away. I'm stuck on 5.16 until I can figure this out because regexes have nasty bugs in 5.18 (see https://rt.perl.org/Public/Bug/Display.html?id=125491). I am planning to bisect against perl 5.19 git to figure out where this broke, but I just haven't had time yet. Regards, Michael Schout
Re: Random segmentation fault
On 9/14/15 12:12 PM, Steve Hay wrote:
> Have you tried 5.20.3? This has just been released and contains a
> number of crash fixes. (I wonder if #123398 might be relevant?)
I just tried 5.20.3.
For my issue (mentioned earlier in this thread), 5.20.3 does not help.
I'll post a followup message in anew thread when I have time, but
basically, I started seeing two different problems somewhere between
5.19.0 and and 5.20.0:
1) "panic: attempt to copy freed scalar to " reliably
reproduced when calling $cgi->param(x => ''); inside a TryCatch try { }
block. (and $cgi is CGI.pm here)
Test case I have works perfectly against perl, but produces the above
panic under mod_perl.
Seems to be something to do with TryCatch or Devel::Declare as the
problem goes away if I use eval { } instead of try { }. Unfortunately
this is a large client codebase heavly invested in TryCatch so moving
away from that is not going to be fun/easy.
2) repeatable segfault by a certain subroutine doing something as simple as:
sub foo {
my ($self, $field, $type) = @_;
if ($type = 'X') {
return $self->_bar($field);
}
}
The fun part of this one is that if I remove the "return" keyword, the
segfault goes away.
Regards,
Michael Schout
Re: Enquiry about mod_perl project state
On 8/14/15 9:59 AM, John Dunlap wrote: > mod_perl isn't the cool kid on the block anymore but there are a lot > of systems out there built on top of it and I doubt it's going away > any time soon. I'd have to agree with this sentiment largely. Yes, its not the cool kid on the block like it was 15 years ago, but its still alive and still gets the job done. Speaking from my own experience, I still have clients that have large legacy mod_perl apps and those apps are not going away any time soon. But personally I tend to go with a Plack/PSGI based solution for new projects. I suspect a lot of other people are doing the same thing. You can still run these projects under Apache/mod_perl. Or, you can run them under a pile of other systems (personally I like nginx in front of starman, but to each their own). As far as migration path, it depends how deeply the tentacles of your application have dug into the Apache API. I have migrated a few projects off of mod_perl that were very easy, and a few that required extensive changes in order to run under PSGI. But I have no problems/fears about the state of mod_perl at this point. The port to Apache 2.4 has taken a while, but that is understandable given the massive changes to the internal apache API. Simply upgrading your legacy apps to Apache 2.4+mod_perl alone is going to require some work because the API has changed. Cheers! Michael Schout
Re: Apache2::AuthCookie - semantics of WhatEverPath parameter?
On 7/27/15 12:30 PM, Jim Garrison wrote: Every example for Apache2::AuthCookie shows ... WhatEverPath / ... AuthCookie maintainer here. Its the path that will be sent in the HTTP Cookie. As already mentioned by others is the path component of the cookie. If you set a cookie with path=/foo for example, that cookie is only supposed to be sent by the client for urls that begin with /foo. For example if you have a directory called /secure, and you only require AuthCookie authentication to access urls under this directory, you might set the path to /secure Regards, Michael Schout
$r-user and UTF8 flag
Hi.
I've noticed that when setting $r-user($value) if $value is a string
with the UTF8 flag on, calling $r-user returns the string without the
UTF8 flag on again.
In other words, this code:
use Devel::Peek;
$r-user($user);
warn Dump($user);
warn Dump($r-user);
If I pass $user = úser
the Dump of $user outputs
SV = PV(0x7f8a48d850b0) at 0x7f8a4afc1438
REFCNT = 1
FLAGS = (PADMY,POK,pPOK,UTF8)
PV = 0x7f8a4bbf09d0 \303\272ser\0 [UTF8 \x{fa}ser]
CUR = 5
LEN = 16
Notice that the UTF8 flag is on.
But the dump of $r-user is:
SV = PV(0x7f8a42ba67c0) at 0x7f8a4afc17b0
REFCNT = 1
FLAGS = (PADTMP,POK,pPOK)
PV = 0x7f8a4bbfbb60 \303\272ser\0
CUR = 5
LEN = 16
Notice that the UTF8 flag is off on the value returned by r-user.
I'm guessing this is normal behavior due to the fact that $r-user calls
the Apache C API directly?
I'm wondering how others have dealt with situations like this. Is there
any way to get a scalar out of $r-user with the UTF8 flag turned on iff
it was set with a value that had the UTF8 flag turned on? I know the
following works:
$user = Encode::decode('UTF-8', $r-user)
But I really would have expected $r-user to return a value with the
UTF8 flag already on since the value that I used to set it did in fact
have the flag turned on.
FWIW, this is mod_perl 2.0.8, Apache 2.2.29
Regards,
Michael Schout
Re: Undefined symbol modperl_io_perlio_restore_stdout
On 9/14/14 1:08 PM, Bernard T. Higonnet wrote: -8-- Start Bug Report 8-- 1. Problem Description: 99% sure what happened is that you didn't patch libtool in the mod_perl dist. Libtool misidentifies FreeBSD 10 as FreeBSD 1.x, and therefore thinks it cannot create shared libraries. You have to patch libtool and all of the libtool associated files so that it does not recognize it as FreeBSD 1.x. You need to patch configure, ltconfig, and ltmain.sh to fix this. See the patch-libtool rule in your FreeBSD ports tree at: Mk/Uses/libtool.mk for an example of how to patch this. If you fail to patch libtool, the error below is exactly what you will see: /tmp/mod_perl-2.0.8/src/modules/perl/mod_perl.so: Undefined symbol modperl_io_perlio_restore_stdout I just ran into this myself a few weeks ago. Hope it helps. Its not really mod_perl specific. Many packages have this problem due to shipping with libtool that mis-identifies FreeBSD 10. Regards, Michael Schout
Re: Information on using Apache2::AuthCookie with httpd 2.4
Hi, AuthCookie maintainer here. Basically I wouldn't advise deploying mod_perl against httpd 2.4 at this time. There is still no official mod_perl release that supports apache 2.4. In addition, the authorization API has been completely rewritten in apache 2.4, which means that all of your authcookie subclasses will need to be updated as well. As Lathan has already mentioned, there is alpha support for this available in the git tree if you really want to try, but if I were you, I'd still with apache 2.2 at least until there is a stable mod_perl available for apache 2.4. Regards, Michael Schout
Re: mod_perl and utf8 and CGI-param
On 9/2/14, 4:19 PM, Randal L. Schwartz wrote: ## ensure utf8 CGI params: $CGI::PARAM_UTF8 = 1; Sorry to chime in late on this, but part of the problem with CGI.pm and UTF-8 is that PARAM_UTF8 gets clobbered by a cleanup handler that CGI.pm itself registers if its running under mod_perl. This caused major headaches for me at one time until I figured this out. You have to make sure to set $CGI::PARAM_UTF8 early, and FOR EVERY REQUEST, because if you just set it globally (e.g.: in a startup perl script), then it only works for the first request. Regards, Michael Schout
PATCH: add -DAPACHE24 support to Apache::Test - necessary for Auth with Apache 2.4
Hi.
I have submitted this issue a while back to rt.cpan.org, but I have not
gotten any response.
I am the maintainer of Apache::AuthCookie.
As most of us probably already know, Apache 2.4 has a very different
authentication API from previous Apache versions. As a result, in order
to release a version of Apache::AuthCookie that passes tests on Apache
2.4 and previous versions, it is necessary to have conditional config
sections that are only enabled for Apache 2.4 or later.
Currently Apache::Test defines APACHE2 if running under apache 2.0 or
later. The attached patch also defines APACHE24 if running under apache
2 with a minor version = 4.
I shipped a patch for AuthCookie to the debian folks that works under
Apache 2.4, but I also need this patch in Apache::Test in order to make
it so that the test suite will work on all Apache versions (2.4 as well
as 2.2 and earlier)
Example in AuthCookie t/conf/extra.conf.in:
IfDefine APACHE24
# Apache 2.4+ Auth API
PerlAddAuthzProvider user My::Auth-authz
/IfDefine
...
IfDefine APACHE2
...
IfDefine !APACHE24
# Pre Apache 2.4 Auth API.
PerlAuthzHandler
/IfDefine
/IfDefine
Hopefully this makes it clear why this is needed, and why I'd like to
see this in Apache::Test before mod_perl for apache 2.4 is finalized.
Regards,
Michael Schout
diff --git a/Apache-Test/lib/Apache/TestServer.pm
b/Apache-Test/lib/Apache/TestServer.pm
index 254aec6..a3bc3ab 100644
--- a/Apache-Test/lib/Apache/TestServer.pm
+++ b/Apache-Test/lib/Apache/TestServer.pm
@@ -85,6 +85,15 @@ sub post_config {
$self-{rev} = 0; # unknown
}
+($self-{revminor}) = $self-{version} =~ m|/\d\.(\d)|;
+
+if ($self-{revminor}) {
+debug Matched Apache revminor $self-{version} $self-{revminor};
+}
+else {
+$self-{revminor} = 0;
+}
+
$self;
}
@@ -126,7 +135,14 @@ sub pid_file {
sub dversion {
my $self = shift;
--D APACHE$self-{rev};
+
+my $dv = -D APACHE$self-{rev};
+
+if ($self-{rev} == 2 and $self-{revminor} = 4) {
+$dv .= -D APACHE24;
+}
+
+return $dv;
}
sub config_defines {
Re: PATCH: add -DAPACHE24 support to Apache::Test - necessary for Auth with Apache 2.4
On 3/17/14, 1:58 PM, André Warnier wrote: Not an answer to your question, but many thanks for that module, for keeping it up-to-date, and for pointing out the differences in Apache 2.4. Thanks! Incidentally, where can I find a description of the new Apache 2.4 API ? I'm not sure there is really a place that it is documented extensively anywhere in one place. I figured it out from reading these pages: http://httpd.apache.org/docs/current/developer/new_api_2_4.html https://httpd.apache.org/docs/trunk/upgrading.html https://httpd.apache.org/docs/trunk/howto/auth.html https://httpd.apache.org/docs/trunk/mod/mod_auth_basic.html#authbasicprovider as well as reading source code for the various apache modules in httpd 2.4 source (e.g.: mod_auth_basic.c, mod_authz_user.c etc) and the mod_perl patch for apache 2.4 to figure out how the new directives have been implemented in mod_perl. Basically it comes down to needing to do the following for Apache 2.4: declare your Authz handler with something like: PerlAddAuthzProvider user Sample::Apache2::AuthCookieHandler-authz_handler Assuming you want to send Forbidden response if Authz fails (which is what previous versions did): Location /docs AuthzSendForbiddenOnFailure On /Location And REMOVE any PerlAuthzHandler entries you have configured (this is what the PerlAddAuthzProvider does instead). Also Require defaults to satisfy Any now, so if you had: Require user foo Require user bar You have to wrap that in RequireAll now. Feel free to look at the httpd24 branch of AuthCookie on github to see how I implemented it. Regards, Michael Schout
Re: CGI and character encoding
On 02/24/2011 03:31 PM, André Warnier wrote: Hi. I wonder if someone here can give me a clue as to where to look... If you have a fairly recent CGI.pm, it will decode utf-8 properly for you (even avoiding double-decoding), but there are some caveats. In addition to what others have already said, If you are running under mod_perl (which obviously you are), CGI.pm adds a cleanup handler (via register_cleanup) which resets CGI.pm's global variables. One of the variables that gets reset is the PARAM_UTF8 variable (which the -utf8 import controls). Because of this, once the clenaup handler gets called, UTF-8 decoding gets turned off. You have to work around this by manually making sure $CGI::PARAM_UTF8 = 1 before calling CGI-new. Regards, Michael Schout
Re: a better way to recognize module changes
On 09/11/2009 04:26 PM, Jonathan Swartz wrote:
I'm thinking about an improved solution to recognizing module changes in
a running server, without restarting the server.
This thread is quite old, but it inspired me to implement a similar
strategy for dealing with module changes under mod_perl.
In my case, I was only really interested in restarting the server when
modules under a certain namespace changed (all of my app's modules are
under a single namespace, My for example).
My solution involved forking off a watcher process when the server
starts up. This watcher processes uses File::ChangeNotify to watch for
changes in the given modules. A nice benefit of using ::ChangeNotify,
is if you are on Linux, and have the Linux::Inotify2 modules installed,
then this happens with no cpu overhead, and changes are seen almost
instantaneous. Once a change happens, my watcher processes detaches
from apache, and reloads it (retrying some configured number of times in
case there is a syntax error on the first change).
To do this, I created a module My::Apache2::Reload. I register the
handler in httpd.conf as:
PerlPostConfigHandler My::Apache2::Reload
When apache starts up, it immediately restarts itself, so my handler has
to arrange to only start the watcher subprocess one time. I do this on
the second restart like this:
sub handler : method {
return Apache2::Const::OK unless Apache2::ServerUtil::restart_count() ==
2;
start_watcher();
return Apache2::Const::OK;
}
start_watcher is implemented as follows:
sub start_watcher {
unless (fork) { # child
require File::ChangeNotify;
my $module_dir = '/path/to/my/modules';
my $config_dir = '/path/to/my/configs';
my $watcher = File::ChangeNotify-instantiate_watcher(
directories = [$module_dir, $config_dir],
filter = qr/\.(?:pm|conf|yml)$/);
while (my @events = $watcher-wait_for_events) {
my @event_types = map { $_-type } @events;
if (any(@event_types) eq 'modify') {
restart_apache();
}
}
}
}
And restart_apache() is called when something that is watched changes:
sub restart_apache {
disconnect_from_apache();
require IPC::System::Simple;
for my $attempt (1 .. $MaxRestartTries) {
if ($attempt 1) {
sleep $RestartDelay;
}
eval {
IPC::System::Simple::system('apache restart command');
CORE::exit(0);
};
}
# give up.
CORE::exit(0);
}
The disconnect_from_apache() is necessary because the watcher gets
killed off if you do not close all open filehandles in the child when
the restart is attempted. Also we need to detach from the apache
process group. This is done as follows:
sub disconnect_from_apache {
POSIX::setsid();
# close all open fds.
my $max_fds = POSIX::sysconf(POSIX::_SC_OPEN_MAX) // 64;
for my $fd (0 .. $max_fds) {
POSIX::close($fd);
}
}
And thats it. This has worked wonderfully for me. Apache notices
changes in real time, and restarts happen quickly when developing.
If there is interest in a module like this, let me know and I will
package it up and put it on CPAN (obviously I wouldn't use the name
Apache2::Reload as that is taken already :)).
Regards,
Michael Schout
Re: a better way to recognize module changes
On 05/27/2010 03:04 PM, Perrin Harkins wrote: On Thu, May 27, 2010 at 11:11 AM, Michael Schout msch...@gkg.net wrote: My solution involved forking off a watcher process when the server starts up. Wouldn't it be simpler to start a separate daemon for this? The project this is for has apache's sandboxed for each developer. Every developer runs their own apache on a port number based on their UID. By having apache fork the watcher daemon, I don't have to worry about which apache the watcher is in charge of. Also, apache will kill the watcher when apache is killed, so I do not need to manage the watcher daemon at all. Apache takes care of starting and stopping it for me. Regards, Michael Schout
Re: Apache2::AuthCookie
On 05/10/2010 01:59 PM, André Warnier wrote: Michael, I am using that module a lot, and have used it as a base for many variations of Apache AAA. It may please you to know that derivates of that module are being used daily by thousands of people spread all over the world (although they do not always know this; the best things work quietly and reliably in the background). Thanks! AuthCookie has been around for a very long time (first released in 2000) so I suspect there are tons of sites that make use of it. Its hard to guage exactly how many though :). Michael Schout
Re: Apache2::AuthCookie
On 05/10/2010 10:31 AM, Michel Jansen wrote: Is it possible to connect AuthCookie to AuthDBI? I'm the Author of AuthCookie. AuthCookie is a framework for creating authentication modules. You either have to implement your own auth module, using AuthCookie as the base class, or use one of the many subclasses already on CPAN, as suggested in the AuthCookie documentation. I wrote Apache::AuthTicket which does ticket based auth using AuthCookie and a DBI database store. There are many others as well. Regards, Michael Schout
Re: GnuPG module producing empty files
Laurent MARTIN wrote: Has anyone on the list some experience with mod_perl and an alternative to GnuPG module (which is simply a wrapper around pgp binary). I use GnuPG::Interface, and it works fine. Regards, Michael Schout
ANNOUNCE: Apache::AuthCookie, Apache2::AuthCookie 3.11
The uploaded file Apache-AuthCookie-3.11.tar.gz has entered CPAN as file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthCookie-3.11.tar.gz size: 35827 bytes md5: 536ad77c61eaafe1ef152ccdfcdbdbd2 Changes: Version: 3.11 - Fix tiny pod doc error. - Escape CR and LF in 'destination' field to prevent possible XSS attack [Steffen Schwigon]
Re: [mp2] [bug?] %ENV changes not propagated to qx() and to C-library calls.
The docs seem to suggest that that changes to %ENV should work fine: http://perl.apache.org/docs/2.0/user/coding/coding.html mod_perl passes (exports) the following shell environment variables (if they are set) : * PATH - Executables search path. * TZ - Time Zone. Any of these environment variables can be accessed via %ENV You can *access* them, but if you change them, they will not be synchronized with the C environment. You have to use Env::C to work around that. MP2 unties the perl %ENV hash from the C environment during the request, so any changes you make to %ENV during the request will never be seen by anything written in C unless you manually copy it over with something like Env::C. IMO, it would be a lot easier if we could make the untie %ENV behavior optional with a PerlSwitches configuration directive or something. If you are running a non-threaded perl on a prefork MPM, I really do not see the harm in leaving %ENV tied to the C environment. Maybe I'll try to whip up a patch if I can figure it out :). Regards, Michael Schout
Re: BUG: MP_CODE_ATTRS() is broken under perl 5.10.0
Michael Schout wrote: MP_CODE_ATTRS() doesn't work under perl 5.10.0. Does anyone have any ideas on how to fix this? Regards, Michael Schout
Re: mod_perl, ENV{'TZ'}, and localtime
Kirk Noda wrote:
The thread seemed to die off. Still, is there a way to use $ENV{TZ} to
modify the behavior of localtime?
The reason this does not work under modperl version 2.0 is because under
handler perl-script, %ENV is untied from the C environment. The
localtime() function is implemented in C, and as a result, it will never
see the changes you made to $ENV{TZ} from mod_perl.
The way I got around this was to use Env::C, and override
CORE::localtime() with something like:
package MyLocaltime;
use Env::C;
sub import {
my $class = shift;
$class-export('CORE::GLOBAL', 'localtime');
}
sub localtime {
my $time = shift;
$time = time unless defined $time;
my $orig_tz = Env::C::getenv('TZ');
Env::C::setenv('TZ', $ENV{TZ}, 1);
my @ret = CORE::localtime($time);
Env::C::setenv('TZ', $orig_tz, 1);
return @ret;
}
The real problem is that this is only safe under a prefork MPM because
it is not thread safe. There really ought to be an option (IMO) where
you can make the untie of %ENV under perl-script to be optional. Maybe
something like PerlOptions +NoUntieEnv or something so that if you are
running under a prefork MPM, you do not need to resort to tactics like
the above.
Regards,
Michael Schout
Re: Perl 5.10
Andreas J. Koenig wrote: Modperl1 doesn't work, patch available. As for modperl2 I don't know. I've been running 5.10 in my modperl2/apache2.2 sandbox development environment since yesterday. Haven't run into any issues related to 5.10 yet, but its still early on for me :). Regards, Michael Schout
Re: Perl 5.10
Andreas J. Koenig wrote: On Thu, 20 Dec 2007 11:38:02 -0500, Colin Wetherbee [EMAIL PROTECTED] said: Have any of you used mod_perl with Perl 5.10 yet? Are there any gotchas to consider? Modperl1 doesn't work, patch available. As for modperl2 I don't know. I apparently should not have sent the last email. I have since found a problem for me. I'm having trouble getting my custom PerlOutputFilterHandler to fire. It works flawlessly under the same mod_perl 2.0.3/apache 2.2.6/perl 5.8.8.. but with 5.10, *usually* it refuses to run it and just says: [Fri Dec 21 10:57:47 2007] [error] an unknown filter was not added: Foo::Filter::StripWhiteSpace I thought it might be Attribute::Handlers related since ::StripWhiteSpace-handler is defined with the :method attr. But changing the config to specify the method name as well does not help either. I haven't had time to figure out what is going on yet. It could be something specific to my setup ;). Regards, Michael Schout
Re: Perl 5.10
Michael Schout wrote: [Fri Dec 21 10:57:47 2007] [error] an unknown filter was not added: Foo::Filter::StripWhiteSpace in addition, with PerlTrace enabled, I get: modperl_filter_add_request: a non-mod_perl OutputFilter handler Foo::Filter::StripWhiteSpace configured. Regards, Michael Schout
Re: Perl 5.10
Colin Wetherbee wrote: Have any of you used mod_perl with Perl 5.10 yet? Are there any gotchas to consider? Apparently so. I have found the cause of my sometimes-it-works sometimes-it-doesnt problem for PerlOutputFilterHandlers. I tracked the problem down to MP_CODE_ATTRS(), called from modperl_mgv.c on line 276: handler-attrs = (U32)MP_CODE_ATTRS(cv); I added some MP_TRACE()'s around this line and found out that MP_CODE_ATTRS(cv) returns some random looking data under 5.10. Looking at mod_perl.h, it says: /* betting on Perl*Handlers not using CvXSUBANY * mod_perl reuses this field for handler attributes */ #define MP_CODE_ATTRS(cv) (CvXSUBANY((CV*)cv).any_i32) This must not be a safe bet under perl 5.10.0. I have no idea what to do as an alternative. I don't know enough perl internals :). Here is what the MP_TRACE()'s before and after he MP_CODE_ATTRS() call looks like under 5.8.8: modperl_mgv_resolve: pre MP_CODE_ATTRS attrs: 0 modperl_mgv_resolve: post MP_CODE_ATTRS attrs: 0 Under 5.10.0 its a much different story: modperl_mgv_resolve: pre MP_CODE_ATTRS attrs: 0 modperl_mgv_resolve: post MP_CODE_ATTRS attrs: 9905fb8 The sometimes-it-works sometimes-it-doesnt behaviour depends on if the right bits end up getting set in the attrs from the random data coming out of MP_CODE_ATTRS(). Oh well, I'm going back to 5.8.8 for now I guess :). I'll file a bug report as well :). Regards, Michael Schout
BUG: MP_CODE_ATTRS() is broken under perl 5.10.0
-8-- Start Bug Report 8-- 1. Problem Description: MP_CODE_ATTRS() doesn't work under perl 5.10.0. I discovered this when trying to use a PerlOutputFilterHandler and upgraded from 5.8.8 to 5.10.0. Under 5.10.0, sometimes the filter would run, sometimes not. When the filter would not run, MP_TRACE messages showed that mod_perl thought it was not a perl filter handler. I tracked this problem down to the fact that the filter h-attrs were getting corrupted sometime after the filter was loaded, but before the request was run. The culprit appears to be in modperl_mgv.c, line 276: handler-attrs = (U32)MP_CODE_ATTRS(cv); I added MP_TRACE() lines before and after this call. When running under perl 5.8.8, the MP_TRACE()'s output: modperl_mgv_resolve: pre MP_CODE_ATTRS attrs: 0 modperl_mgv_resolve: post MP_CODE_ATTRS attrs: 0 However, when running under perl 5.10.0, the MP_TRACE()'s look like this: modperl_mgv_resolve: pre MP_CODE_ATTRS attrs: 0 modperl_mgv_resolve: post MP_CODE_ATTRS attrs: 9905fb8 The actual value returned by MP_CODE_ATTRS() varies. Looking at mod_perl.h, where MP_CODE_ATTRS() is defined: /* betting on Perl*Handlers not using CvXSUBANY * mod_perl reuses this field for handler attributes */ #define MP_CODE_ATTRS(cv) (CvXSUBANY((CV*)cv).any_i32) Apparently this is not a safe assumption for perl 5.10.0... 2. Used Components and their Configuration: *** mod_perl version 2.03 *** using /home/mschout/build/lib/perl5/site_perl/arch/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB = aprext MP_APXS= /home/mschout/core/src/mod_perl/../../build/bin/apxs MP_COMPAT_1X = 1 MP_GENERATE_XS = 1 MP_LIBNAME = mod_perl MP_TRACE = 1 MP_USE_DSO = 1 *** The httpd binary was not found *** (apr|apu)-config linking info -L/home/mschout/core/src/apache/../../build/lib -laprutil-1 -lpq -lexpat· -L/home/mschout/core/src/apache/../../build/lib -lapr-1 -luuid -lrt -lcrypt -lpthread -ldl· *** /home/mschout/core/src/perl/../../build/bin/perl -V Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Platform: osname=linux, osvers=2.4.21-53.elsmp, archname=i686-linux uname='linux testbed 2.4.21-53.elsmp #1 smp mon dec 3 13:34:41 est 2007 i686 i686 i386 gnulinux ' config_args='-Dprefix=/home/mschout/core/src/../build -Dprivlib=/home/mschout/core/src/../build/lib/perl5 -Darchlib=/home/mschout/core/src/../build/lib/perl5/arch -Dsitelib=/home/mschout/core/src/../build/lib/perl5/site_perl -Dsitearch=/home/mschout/core/src/../build/lib/perl5/site_perl/arch -Dman3dir=/home/mschout/core/src/../build/man/man3 -Ui_db -de' hint=previous, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2', cppflags='-fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm' ccversion='', gccversion='3.2.3 20030502 (Red Hat Linux 3.2.3-59)', 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 =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib' Characteristics of this binary (from libperl):· Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO Built under linux Compiled at Dec 19 2007 12:10:30 %ENV: PERL5LIB=/home/mschout/build/lib/perl5/arch:/home/mschout/build/lib/perl5:/home/mschout/build/lib/perl5/site_perl/arch:/home/mschout/build/lib/perl5/site_perl PERL_LWP_USE_HTTP_10=1 @INC: /home/mschout/build/lib/perl5/arch /home/mschout/build/lib/perl5 /home/mschout/build/lib/perl5/site_perl/arch /home/mschout/build/lib/perl5/site_perl . *** Packages of interest status: Apache2: - Apache2::Request : - CGI: 3.29, 3.29 ExtUtils::MakeMaker: 6.42, 6.42 LWP: 5.803, 5.803 mod_perl : - mod_perl2 : 2.03, 2.03 3. This is
register_cleanup and %ENV
Hi folks.
I'm in the midst of porting a fairly large application over from
mod_perl 1 to mod_perl 2.0. The app I am currently working on runs as a
perl-script handler using PerlResponseHandler My::Package::Name under
mod_perl 2.
One situation I have is that I sometimes have to do a long running
process that may take up to 1-2 minutes to complete. Under MP1, I
registered a cleanup handler to do this, and sent the user to a status
page that would refresh every 5 seconds until the cleanup handler
finished and spit out the results (which the cleanup handler saved in
the db). Getting the cleanup registered and getting it to fire under
mod_perl 2 was simply a matter of changing $r-post_connection(sub { ...
}) to $r-pool-cleanup_register(sub { ... }). So far so good.
The problem with this is I an %ENV variable called TEST_MODE, set at
startup time (from startup.pl) which enables certain behavior (e.g.:
allows fake credit card numbers, enables some extra logging statements
etc). mod_perl 2 unfortunately scrubs %ENV before my cleanup handler
gets called, so $ENV{TEST_MODE} is never set when the cleanup handler
runs. I don't really see any way to prevent this from happening from
what the docs say. If anyone has any ideas on how to prevent %ENV from
getting wiped before my cleanup handler fires, or has any suggestions
about how to do a long running process under mod_perl 2 while
preserving %ENV from the request, I'd love to hear them ;).
Thanks
Michael Schout
Re: register_cleanup and %ENV
Perrin Harkins wrote:
Have you considered using your own global instead? Or PerlSetVar in
httpd.conf?
Yeah. Unfortunately that really doesn't work for me. I can get
TEST_MODE that way, but there are other %ENV vars that I need also
(such as HTML_TEMPLATE_ROOT for example). I did manage to get it
working by registering the cleanup like this:
my %renv = %ENV;
my $sub = sub {
my %orig_env = %ENV;
%ENV = %renv; # copy request-time %ENV
$cleanup_func();
%ENV = %orig_env; # restore %ENV
};
$r-pool-cleanup_register($sub);
So I just cheated and reset the environment before the cleanup function
is called. I realize I shouldn't rely on %ENV under MP2 for thread
safety reasons, but this app is never going to run on anything other
than a prefork MPM and I can live with that :).
Regards,
Michael Schout
[ANNOUNCE] Apache-AuthCookie 3.10
The uploaded file Apache-AuthCookie-3.10.tar.gz has entered CPAN as file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthCookie-3.10.tar.gz size: 34993 bytes md5: 8dd9f4a3db329c378f5e5b394c05b5b3 Changes: Version: 3.10 - Bug Fix: when copying user from prev request, check that $r-prev is defined, not just that $r-is_initial_request is true.
Re: mod_proxy_add_forward
Issac Goldstand wrote: In Apache 2, it's built in to mod_proxy. In Apache 1 (as of a couple of years ago, at least) it wasn't - that's why mod_proxy_add_forward was originally written :) Apache 1.3.33 has it built in also. I am not sure when this became part of apache 1.3, but it is definitely in there now (confirmed in src/modules/proxy/proxy_http.c in 1.3.33 sources, and I make use of it in production :)). I'm not sure when this became part of standard mod_proxy, but its definitely there now in 1.3 and in Apache 2 :). Regards, Michael Schout
Re: mod_proxy_add_forward
David Romero wrote: Hi I need the client ip on a backend server. Plain old mod_proxy will pass along the ip in an X-Forwarded-For header. Regards, Michael Schout
ANNOUNCE: Apache::AuthCookie 3.09
The uploaded file
Apache-AuthCookie-3.09.tar.gz
has entered CPAN as
file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthCookie-3.09.tar.gz
size: 34908 bytes
md5: 8bfd8834d2b161f2e28c908c27eccf10
Please allow a few hours for the file to mirror across CPAN :).
Apache::AuthCookie allows you to intercept a user's first
unauthenticated access to a protected document. The user will be
presented with a custom form where they can enter authentication
credentials. The credentials are posted to the server where AuthCookie
verifies them and returns a session key.
The session key is returned to the user's browser as a cookie. As a
cookie, the browser will pass the session key on every subsequent
accesses. AuthCookie will verify the session key and re-authenticate the
user.
All you have to do is write a custom module that inherits from
AuthCookie. See the POD documentation for more details.
Changes since 3.08:
- POD doc fixes.
- MP2: remove _check_request_req() - this was only necessary when
running under both MP1 and MP2. Package name change eliminates the
need for this.
- test suite converted to Test::More style test suites.
- descriptive test descriptions added
- make login() stash credentials in $r-pnotes(${AuthName}Creds) so
that the login form can access the user-supplied credentials if the
login fails.
- bug fix: use of Apache2::URI::unescape_url() does not handle
'+' to ' ' conversion. This caused problems for credentials
that contain spaces.
- MP2: remove mod_perl features from use mod_perl2 line. This is
no longer supported by mod_perl2.
- MP2: _get_form_data() - switch to CGI.pm to handle form data (fixes
several form data handling bugs)
- In a subrequest, copy $r-prev-user to $r-user (or
r-connection-user for MP1).
- remove Apache2::AuthCookie::Util - no longer necessary
- multi-valued form fields are now handled properly in POST - GET
conversion
- MP2: require CGI.pm 3.12 or later
Re: Apache::AuthCookie Setup
Paul D. Kraus wrote: I installed apache::authcookie from apt on debian and I can not find any of the files that the docs mention under examples. real.t doesn't exist and the testing suite is also non-existent. Sounds like your package does not include these files from the official distribution. Download the official distribution from CPAN at: http://search.cpan.org/~mschout/Apache-AuthCookie-3.08/ The POD docs explain the httpd.conf settings, and there is a complete working system written for the test environment. See t/conf/extra.conf.in, t/lib/Sample/AuthCookieHandler.* Regards, Michael Schout (AuthCookie maintainer)
[ANNOUNCE] Apache::AuthTicket 0.40
The uploaded file Apache-AuthTicket-0.40.tar.gz has entered CPAN as file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthTicket-0.40.tar.gz size: 20346 bytes md5: a1d0a5650b9deae181effb977c8d71a8 No action is required on your part Request entered by: MSCHOUT (Michael Schout) Request entered on: Mon, 06 Jun 2005 20:14:12 GMT Request completed: Mon, 06 Jun 2005 20:14:39 GMT - Changes since 0.31: o update to use new Apache::Filter API (you need at least 1.012 now) o Create Apache2::AuthTicket from copy of Apache::AuthTicket and ported to mod_perl 2.0 API. This is the first release that supports mod_perl2 o MP2 - use SQL::Abstract to generate queries
Re: Apache::Session::Store::Postgres FOR UPDATE problems [OT]
Jeffrey W. Baker wrote: It is possible that the FOR UPDATE is spurious. It signals to the database system that this transaction intends to write that row. With PostgreSQL's MVCC transaction isolation system, it's probably not necessary and may be causing problems. It definately *is* necessary if you want to ensure that only one process has access to your session data at a time. MVCC will prevent a second client from WRITING to the same row, but it will not block it from reading the row. In other words, MVCC will not prevent the following scenario: client 1: SELECT * FROM sessions WHERE id='1'; client 2: SELECT * FROM sessions WHERE id='1'; # at this point, client 1 and client 2 both have copies of the session. suppose client 1 makes changes to the session data and saves it: client 1: UPDATE sessions SET data='...' WHERE id='1'; now suppose client 2 makes changes: client 2: UPDATE sessions SET data='...' WHERE id='1'; Whoops, you just wiped out the changes that client 1 made! FOR UPDATE prevents this because it tells the database that you intend to change the row. The database will not let anyone else select that row FOR UPDATE until you either issue a COMMIT or ROLLBACK. So in otherwords: client 1: SELECT * FROM sessions WHERE id='1' FOR UPDATE; client 2: SELECT * FROM sessions WHERE id='1' FOR UPDATE; at this point, client 2 will block until client 1 either does COMMIT or ROLLBACK. So if you want to ensure that only one client has the session data at a time, you need FOR UPDATE. Regards, Michael Schout
reading post data.
I am wondering what the best way is to read POST data under MP2. In MP1, I was using $r-content for this. In MP2, $r-content does not exist, so I used the version from an earlier copy of Apache::compat, which was using $r-get_client_block() instead. Now, get_client_block() is apparently deprecated, and I am left with the choice of: 1) using $r-read(). CGI.pm apparently does it this way. 2) Use APR::Brigade. Apache2::compat from 2.0.0 RC5 does provides content() this way. 3) some other way that I do not know about :). I am unclear what the advantages are for either approach. The APR::Brigade docs do not really clarify this for me. Does anyone know which of these methods is better and why? Regards, Michael Schout
Re: ticketing solutions
Dan Brian wrote: My point was that I don't need a CPAN module to verify hashes. Features could include a mechanism for rotating a key on the servers being accessed, IP verification ... and other features I can't think of. :-) Apache::AuthTicket does ip verification. Not sure what you mean by key rotation, but AuthTicket allows you to change the secret key in the database periodically. These are used to verify that the ticket has not been tampered with. You can have multiple secret keys active at the same time, allowing tickets just issued on the previous key to expire before you remove it from the database. So, for example, you can issue new secret keys every 2 hours, and delete all secret keys more than 6 hours old at the same time. AuthTicket will always issue new tickets using the most recent secret key. Not sure if this is the type of thing you are referring to, or if you are looking for something else :). Regards, Michael Schout
Re: ticketing solutions
Dan Brian wrote: What are people using to do authentication ticketing from mp? Nothing jumps out of CPAN at me, mostly because what I've seen just makes md5's out of username/password/expiration. Any recommendations? My Apache::AuthTicket module implements a ticketing system similar to that in the Eagle book. Unfortunatly it is MP1 only at this time. I am working hard to port it over to MP2 RC5. Hoping to have something released over the weekend if I get some free time :). If you are looking for a non-perl implementation, this may help you: http://www.openfusion.com.au/labs/mod_auth_tkt/ However, its only for apache 1.x apparently. Regards, Michael Schout
[ANNOUNCE] Apache-AuthCookie 3.07
The uploaded file
Apache-AuthCookie-3.07.tar.gz
has entered CPAN as
file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthCookie-3.07.tar.gz
size: 34483 bytes
md5: 38672d492c3281893872502f04b4f584
Changes since 3.06:
*** mod_perl2 users: THIS RELEASE IS INCOMPATIBLE WITH PAST RELEASES
*** If you are running mod_perl2, you must update to at least
*** mod_perl 2.0.0 RC5. The mod_perl2 version of AuthCookie has been
*** renamed to Apache2::AuthCookie
** MP2: RENAME AuthCookie.pm.mp2 to Apache2::AuthCookie.
- MP2: Update module, and tests for mod_perl 2.0.0 RC5.
mod_perl2 users MUST use Apache2::AuthCookie now.
- Require Apache::Test 1.22
- Add support for ${auth_name}SessionTimeout configuration paramter
which will re-issue the ticket with the expires parameter set to
the value of this configuration setting for each request. This is
useful for idle-timeout.
- POD fixes.
- MP2: fix uninitialized warnings if no POST/GET data (RT 11371)
- make sure recognize_user() returns an Apache constant in all cases.
Returns DECLINED in cases where we were returning undef before.
(Thanks Vivek)
- Add support for MS HttpOnly cookie property.
Please report any bugs to [EMAIL PROTECTED]
Re: Advice needed on custom webapp framework
On Wed, 17 Nov 2004, jonathan vanasco wrote:
Ideally, I would have the packages in Website and WebAppFramework
lookup the right DB for the Website
There are many ways to solve this problem. I'll show you 2 ways. I'll
focus just on the database part to keep this as short as possible, but
the same ideas apply to the user object...
One way is to put the databse in a separate package and access it
using static methods.
e.g.:
my $dbh = Website::Database-dbh;
You could even make this a method of WebAppFramework. Then you are
simply left with the problem of getting the right database handle for
each website. There are many ways to do that. One way would be to just
have a hash or something in WebAppFramework that stores the database
handles for each partuclar website, and then have your dbh() (or
whatever you decide to call it) method figure out which handle to
retrieve. The downside is that you have to modify WebAppFramework
everytime you create a new application (or, create methods for managing
the datbase hash, and call them from within your appliaction). If you
don't want to do it that way, another way would be to simply subclass
WebAppFramework for each site, and then have the individual appliactions
subclass it. e.g.:
package WebAppFrameWork::SomeSite;
use base 'WebAppFrameWork';
sub dbh {
# return database appropriate for SomeSite
}
...
__END__
package WebApp::SomeSite::SomeApp;
use base 'WebAppFrameWork::SomeSite';
# calling $self-dbh in here calls WebAppFrameWork::SomeSite-dbh
# plus you can call any methods provided by WebAppFrameWork
...
__END__
Regards,
Michael Schout
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[ANNOUNCE] Apache::AuthCookie 3.06
The uploaded file
Apache-AuthCookie-3.06.tar.gz
has entered CPAN as
file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthCookie-3.06.tar.gz
size: 32510 bytes
md5: 8d64e84fb8accd870b058e6b7b1634f9
Changes:
** BUG FIX: AuthNameSatisfy (Any|All) directives were broken. AuthCookie
was using AuthCookieSatisfy rather than ${auth_name}Satisfy. If you
used this feature and had an AuthCookieSatisfy directive in your
config file, you MUST change this to ${auth_name}Satisfy.
E.g.: WhateverSatisfy All
- created better test cases for AuthNameSatisfy directives.
- when redirecting, set Location with headers_out() not
err_headers_out().
apache prefers Location in headers_out, even if the status code is not
200.
- MP2: Apache::unescape_url() - Apache::URI::unescape_url()
- check for mod_perl 1.9913 or later for Apache::URI (Frederick
Moyer)
- Remove set status in login.pl which caused malformed custom error
document (Frederick Moyer)
- Add support for ${auth_name}CookieName to change the name of the
cookie
used for each auth name. Default remains ${auth_name}_${auth_type} if
not set.
- make some debug log_error() calls conditional on $debug
Regards,
Michael Schout
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [ANNOUNCE] Apache::AuthCookie 3.05
On Wed, 28 Jan 2004, Geoffrey Young wrote: so, the Location header really needs to special treatment to be included in redirect responses, which is typically why you put things in err_headers_out. Well, the report I got on it was that setting it in headers_out rather than err_headers_out causes Client-Warning: Redirection loop detected headers to be generated. I never was able to reproduce that and figured it must just be a configuration issue. The main reason I changed it was because I *thought* that err_headers_out was more appropritate because login returns REDIRECT. However, looking at http_protocol.c, I'm not so sure. At least looking at the apache 1.3 sources, ap_send_error_response() in http_protocol.c prefers to have Location in headers_out rather than err_headers_out (as you have already pointed out :)). So from that standpoint, its probably better to have the Location in headers_out. Given that, I think its best to change it back for the next release. So to answer your question, there was not really a specific bug involved here. I just assumed that err_headers_out was the appropriate place becuase of the REDIRECT. I didn't know that http_protocol.c was treating Location differently from other headers :). Thanks for pointing that out. Regards, Michael Schout GKG.NET, Inc. -- Hal 9000 - Put down those Windows disks Dave Dave? DAVE!! -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[ANNOUNCE] Apache::AuthCookie 3.05
The file Apache-AuthCookie-3.05.tar.gz has entered CPAN as file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthCookie-3.05.tar.gz size: 31025 bytes md5: 4288575a1eedb52b2fb774324cd63ec8 Changes: Version: 3.05 - Fix POD documentation bug (thanks Steve van der Burg) - login(): set Location header with err_headers_out rather than headers_out (Casey West) - put cookie removal code in remove_cookie() method, put cache handling code in handle_cache() (Mark A. Hershberger) - reorganized tree to support multiple mod_perl versions. - rewrote tests to use Apache::Test framework from CPAN. - fix POD errors in authorize() documentation. - initial support for mod_perl version 2 - mp2: check for Apache::RequestRec arg so that unported subclasses throw exceptions. mod_perl v2 subclass authors: the API has changed slightly for the mod_perl v2 version. See README.modperl2 for details. Regards, Michael Schout GKG.NET, Inc. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
