[mp2] 1.99_16 Test 'apache/util.t' falied with locale ru_RU.utf8

[Dmitry Tsigelnik]

>> t/TEST -verbose apache/util.t
SB> [...]
>> t/apache/util1..8
SB> [...]
>> # testing : Apache::Util::ht_time($pool)
>> # expected: (?-xism:^\w+, \d\d \w+ \d\d\d\d \d\d:\d\d:\d\d)
>> # received: A?A?A?A?A?A?, 25 A?A?A?A?A?A? 2004 09:09:26 GMT
>> not ok 1

SB> Dmitry, please take a look at t/response/TestApache/util.pm and see what's
SB> wrong.

SB> I think:

SB> $x = "A?A?A?A?A?A?, 25 A?A?A?A?A?A? 2004 09:09:26 GMT";
SB> print $x =~ /^\w+, \d\d \w+ \d\d\d\d \d\d:\d\d:\d\d/ ? "OK" : "NOT OK";

SB> the $x string should match that pattern. Unless something is wrong with
SB> perl's regex engine. It seems that this 'A?' char is not matching \w.

I see!!! test failed under locale ru_RU.utf8

Under locale "C" this test print next strings and test successful

# expected: (?-xism:^\w+, \d\d \w+ \d\d\d\d \d\d:\d\d:\d\d)
# received: Thu, 26 Aug 2004 07:05:12 GMT




-- 
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: Hosting provider disallows mod_perl - "memory hog / unstable"

[Jean-Michel Hiver]

Gossamer-Threads has a pretty cool mod_perl setup. You can get a 
dedicated server or a shared account. Each shared account has its own 
apache process, which means that you can log in and control (i.e. stop / 
start / restart) your own modperl httpd.

All the mod_perl processes are behind a small, minimal apache proxy + 
mod_gzip which manages the virtual hosting, slow connections and gzip 
compression. I was recently visiting them in Vancouver and their system 
is pretty clever IMHO.

http://www.gossamer-host.com/
--
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: mod_perl (1.99_16) fails to begin tests because of assertion "rv == APR_SUCCESS" failed in vhost.c -- More Information

[RenquistIsMe]

So, I ran the t/TEST -conf and t/TEST tests separately, replacing  "_default_" with 
the actual name of the 
host machine. LOTS of errors and ultimately a completely wedged  test script. I was 
also able to run
some tests after, as individual tests.

Here is the log of the tests with "ok" tests deleted:

% t/TEST

[warning] root mode: changing the files ownership to 'nobody' (60001:60001)

[warning] testing whether 'nobody' is able to -rwx /opt/local/pkg/mod_perl-1.99_16/t
"/opt/local/bin/perl" -Mlib=/opt/local/pkg/mod_perl-1.99_16/Apache-Test/lib 
-MApache::TestRun -e 'eval { Apache::TestRun::run_ro
ot_fs_test(60001, 60001, q[/opt/local/pkg/mod_perl-1.99_16/t]) }';


[warning] result: OK
[warning] the client side drops 'root' permissions and becomes 'nobody'
/var/apache/bin/httpd -d /opt/local/pkg/mod_perl-1.99_16/t -f 
/opt/local/pkg/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2
using Apache/2.0.50 (prefork MPM)

waiting 120 seconds for server to start: ..[Fri Aug 27 16:16:27 2004] [info] 26 
Apache:: modules loaded
[Fri Aug 27 16:16:27 2004] [info] 7 APR:: modules loaded
[Fri Aug 27 16:16:27 2004] [info] base server + 20 vhosts ready to run tests
...
waiting 120 seconds for server to start: ok (waited 8 secs) 
server localhost:8529 started 
server localhost:8530 listening (TestModperl::setupenv)
server localhost:8531 listening (TestModperl::merge)
server localhost:8532 listening (TestModperl::perl_options)
server localhost:8533 listening (TestVhost::config)
server localhost:8534 listening (TestProtocol::pseudo_http)
server localhost:8535 listening (TestProtocol::echo_filter)
server localhost:8536 listening (TestProtocol::echo_bbs2)
server localhost:8537 listening (TestProtocol::echo_bbs)
server localhost:8538 listening (TestProtocol::echo_timeout)
server localhost:8539 listening (TestProtocol::echo_block)
server localhost:8540 listening (TestPreConnection::note) 
server localhost:8541 listening (TestHooks::startup)
server localhost:8542 listening (TestHooks::stacked_handlers2)
server localhost:8543 listening (TestHooks::hookrun)
server localhost:8544 listening (TestFilter::in_bbs_msg)
server localhost:8545 listening (TestFilter::both_str_con_add)
server localhost:8546 listening (TestFilter::in_bbs_inject_header)
server localhost:8547 listening (TestFilter::in_str_msg)
server localhost:8548 listening (TestDirective::perlrequire)
server localhost:8549 listening (TestDirective::perlmodule)
server localhost:8550 listening (TestDirective::perlloadmodule4) 
server localhost:8551 listening (TestDirective::perlloadmodule5)
server localhost:8552 listening (TestDirective::perlloadmodule3)
server localhost:8553 listening (TestDirective::perlloadmodule6)
--ok tests deleted below

/apr/threadmutex...skipped
all skipped: Perl was not built with 'ithreads' enabled
  
t/directive/perlloadmodule3.NOK 2# Failed test 2 in 
t/directive/perlloadmodule3.t at line 69
  
t/directive/perlloadmodule3.NOK 3# Failed test 3 in 
t/directive/perlloadmodule3.t at line 97
t/directive/perlloadmodule3.FAILED tests 2-3
Failed 2/3 tests, 33.33% okay

t/directive/perlloadmodule4.FAILED tests 1-3
Failed 3/3 tests, 0.00% okay

t/directive/perlloadmodule5.FAILED tests 1-3
Failed 3/3 tests, 0.00% okay

t/directive/perlloadmodule6.FAILED tests 1-3
Failed 3/3 tests, 0.00% okay


t/filter/both_str_con_add...NOK 2# Failed test 2 in 
t/filter/both_str_con_add.t at line 22
#  t/filter/both_str_con_add.t line 22 is: ok t_cmp($reply, $str);
t/filter/both_str_con_add...NOK 3# Failed test 3 in 
t/filter/both_str_con_add.t at line 22 fail #2
t/filter/both_str_con_add...NOK 4# Failed test 4 in 
t/filter/both_str_con_add.t at line 22 fail #3
t/filter/both_str_con_add...FAILED tests 2-4
Failed 3/4 tests, 25.00% okay

t/filter/both_str_req_mix...skipped
all skipped: cannot find module 'deflate'

t/filter/both_str_req_proxy.skipped
all skipped: cannot find module 'proxy'

t/filter/in_bbs_inject_header...request has failed (the response code was: 404)
see t/logs/error_log for more details
t/filter/in_bbs_inject_header...dubious
Test returned status 29 (wstat 7424, 0x1d00)
DIED. FAILED tests 1-36
Failed 36/36 tests, 0.00% okay

t/filter/in_bbs_msg.request has failed (the response code was: 404)
see t/logs/error_log for more details
t/filter/in_bbs_msg.dubious
Test returned status 29 (wstat 7424, 0x1d00)


t/filter/in_str_msg.request has failed (the response code was: 404)
see t/logs/error_log for more details
t/filter/in_str_msg.dubious
Test returned status 29 (wstat 7424, 0x1d00)

t/hooks/hookrun.NOK 1# Failed test 1 in t/hooks/hookrun.t at 
line 19
req

Re: Trick PerlAuthzHandler into thinking Basic Auth occurred

[David Castro]

on 08/30/04 12:09 Geoffrey Young wrote:

  
Heh.  Yeah, maybe the point I needed to make more clear is this.  The
PerlAuthenHandler is NOT relying on basic auth to actually have ever
occured.  It is a handler that gets credentials via another service
altogether.  Suffice it to say that no basic auth ever happens, but my
PerlAuthenHandler gets a username.  Now, I want to fool the authz
module, which expects basic auth to have occurred, into thinking that
basic auth occurred.  So, somehow I need to setup the
environment/request object/etc. to accomplish this.

  
  
ah :)

then all you should need to do is set $r->user to the authenticated user and
you should be good to go.  for completeness, you might also want to set
$r->connection->auth_type to 'Basic', but that is most likely not required
to get things working.
  

Hrmm.  Yeah, this is what I had thought and tried at one point with no
luck.  When I use basic auth and let mod_authz_ldap do it's thing, I
get "...basic LDAP authentication of user 'test'...", but with my auth
module (using the code above) I get "...on user '(null)' failed..." in
my logs.  So, basic auth is doing something that I am not to get that
user set for the underlying authz module, I just can't figure out what
the heck it is.

  
for more discussions on hacking together your own authentication mechanism,
where both of these things are discussed, see recipes 13.7 and 13.8 in the
mod_perl developer's cookbook.  all of chapter 13 can be read online for free:

  http://www.modperlcookbook.org/chapters/ch13.pdf

HTH

--Geoff

  



-- 
David Castro
Software Architect
Azusa Pacific University

"My little children, let us not love in word or in tongue,
but in deed and in truth." -- 1 Jn 3:18 (NKJ) 

Re: Trick PerlAuthzHandler into thinking Basic Auth occurred

[Geoffrey Young]

>> then all you should need to do is set $r->user to the authenticated
>> user and
>> you should be good to go.  for completeness, you might also want to set
>> $r->connection->auth_type to 'Basic', but that is most likely not
>> required
>> to get things working.
>>  
>>
> Hrmm.  Yeah, this is what I had thought and tried at one point with no
> luck.  When I use basic auth and let mod_authz_ldap do it's thing, I get
> "...basic LDAP authentication of user 'test'...", but with my auth
> module (using the code above) I get "...on user '(null)' failed..." in
> my logs.  So, basic auth is doing something that I am not to get that
> user set for the underlying authz module, I just can't figure out what
> the heck it is.

well, I can't find either of those error messages in mod_auth_ldap from

  http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html

on in httpd-2.0, so I'm not sure exactly where the error is coming from.
one thing of interest is that in the former code they call
ap_get_basic_auth_pw() from the authz phase, which is clearly wrong and will
subvert the approach I outlined above.  but if you can't set the
Authorization header either (recipe 13.4) and have it work then I don't know.

anyway, if you give me a pointer to the mod_auth_ldap code you're using I
can look it over and see, but there are only a few different places where
the user information can come from - $r->user directly, or from the
Authorization header.

well, I guess there is a third - mod_auth_ldap could assume (or require)
that it is the authentication handler and instead of looking in those two
places it could rely on some internal cache.  in fact, this seems to be the
case, as the "AuthLDAPAuthoritative" directive seems to be designed exactly
for this purpose.  the docs indicate that you should set it to "no" if you
want to use something other than mod_auth_ldap for the authentication phase,
which is what you are trying to do.  so, have you set this directive and
tried a the other two approaches (setting the incoming header and/or just
$r->user)?

--Geoff

-- 
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 HTTP Server Request Library 2.04-dev Released

[joes]

Apache HTTP Server Request Library 2.04-dev Released

The Apache Software Foundation and The Apache HTTP Server Project
are pleased to announce the 2.04-dev release of libapreq2.  This
Announcement notes significant changes introduced by this release.

The package libapreq2-2.04_03-dev.tar.gz is released under the Apache License
version 2.0.  It is now available through the ASF mirrors

  http://httpd.apache.org/apreq/download.cgi
  http://httpd.apache.org/apreq/download.cgi

and has entered the CPAN as 

  file: $CPAN/authors/id/J/JO/JOESUF/libapreq2-2.04_03-dev.tar.gz
  size: 592748 bytes
   md5: 1f5dd762c877b716f3774d502f575196


libapreq2 is an APR-based shared library used for parsing HTTP cookies,
query-strings and POST data.  The package libapreq2-2.04_03-dev.tar.gz provides

1) version 2.0.20 of the libapreq2 library,

2) mod_apreq, a filter module necessary for using libapreq2
   within the Apache HTTP Server,

3) the Apache::Request, Apache::Cookie, and Apache::Upload
   perl modules for using libapreq2 with modperl-2.



Changes with libapreq2-2.04-dev (released August 30, 2004)


- Perl API [joes]
  Add TAINT checks, marking all parsed data as tainted.

- C API [joes]
  Add body_status attribute to apreq_request_t, to allow the both
  environment and the parser to report any errors encountered.

- C API [randyk, joes]
  Cookie parser was locking up on non-alphanumeric chars in cookie names.
  Also RFC Cookie attributes are always checked for quotes during bake(2),
  and the quotes are now stripped from incoming RFC cookies during parsing 
  (but they are never stripped from the actual cookie value).

- Perl API [joes]
  Apache::Cookie::Jar->new accepts a VALUE_CLASS argument, which effectively
  blesses all the jar's cookies into that class, which simplifies subclassing
  Apache::Cookie.   Accordingly Apache::Cookie->freeze($value) no longer accepts 
  a freeze()-able object in $value.

- C API [Markus Wichitill, randyk, joes]
  Drop APR_DELONCLOSE from apreq_file_mktemp implementation and install
  apreq_file_cleanup. When passed to apr_file_open on Win32, APR_DELONCLOSE 
  sets the FILE_SHARED_DELETE flag, which is, unfortunately, a property that
  is preserved across NTFS "hard" links.  This breaks apps that link() 
  the temp file to a permanent location, and subsequently expect to open it 
  without FILE_SHARED_DELETE before the original tempfile is closed+deleted. 
  In fact, even Apache::Upload does this, so it is a common enough event that
  the apreq_file_cleanup workaround is necessary.

- C API [Ken Burcham, joes]
  Fix bug in url parser that occurs when a %XX-encoded sequence
  is split across multiple buckets.  Added apreq_decode_decodev
  to make this problem less inconvenient.

- Perl API [joes]
  Exception objects inherit from the object which raised it,
  which allows $@ to invoke its methods with impunity (exceptions 
  are disabled for objects which derive from an exception class).

- Perl API [joes]
  Implement HOOK_DATA and UPLOAD_HOOK.

- Perl API [joes]
  Add safe XS wrappers for $table->add, $table->set, $table->STORE,
  and $table_class->new.

- Perl API [joes]
  Add exceptions to $upload->link, $upload->tempname, $upload->slurp, 
  and $cookie->set_attr.  Return value of $upload->slurp is now the 
  upload length.  Also document new $upload->io.

- C API [joes]
  Restrict all apr_status_t codes to APR_SUCCESS, APR_INCOMPLETE,
  APR_EGENERAL, APR_EINIT, APR_ENOTIMPL, since any others will
  generate confusing error messages from apr_strerror.

- Perl API [joes]
  Added $upload->io with a TIEHANDLE API layered over APR::Brigade.   $upload->fh
  remains implemented as an APR::PerlIO object, which is seekable but less efficient 
  and currently suffers some portability issues associated with largefile support
  in perl and apr.

- Perl API [joes]
  Added apreq_xs_croak for throwing APR::Error exceptions and included
  error-checking on $req->param, $req->args, $req->body, $req->upload, 
  and $jar->get.

- Perl API [joes]
  Added $jar->status, $req->args_status and $req->body_status to report
  parsing errors. Also add $upload->tempname per user request.

- C API [joes]
  Dropped status attribute of apreq_value_t.  Added status field to
  apreq_jar_t and added args_status field to apreq_request_t. Parsers
  also must return their public status code when a NULL brigade is passed.
  apreq_hook_disable_uploads() is also added.
  .
  This is an ABI change affecting all versions of libapreq2 prior to 2.0.12.

- Perl API [joes]
  $upload->info returns a proper APR::Table object now. Also implemented
  $upload->size, $upload->fh, and $upload->type.

- C API [Jean-François Meesse]
  mfd parser fails to parse CRLF-terminated files when the terminating
  boundary string is at the start of a new bucket.  This is reportedly
  a common event for PDF files uploaded with Netscape 

Re: Trick PerlAuthzHandler into thinking Basic Auth occurred

[David Castro]

on 08/30/04 13:43 Geoffrey Young wrote:

  

  then all you should need to do is set $r->user to the authenticated
user and
you should be good to go.  for completeness, you might also want to set
$r->connection->auth_type to 'Basic', but that is most likely not
required
to get things working.
 

  

Hrmm.  Yeah, this is what I had thought and tried at one point with no
luck.  When I use basic auth and let mod_authz_ldap do it's thing, I get
"...basic LDAP authentication of user 'test'...", but with my auth
module (using the code above) I get "...on user '(null)' failed..." in
my logs.  So, basic auth is doing something that I am not to get that
user set for the underlying authz module, I just can't figure out what
the heck it is.

  
  
well, I can't find either of those error messages in mod_auth_ldap from

  http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html

  

Ooops, yeah.  A follow-up email corrected "mod_authz_ldap" to
"mod_auth_ldap".  Sorry 'bout that.  To give a bit more detail, I am
using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0.  Went looking
through the C code of the authz module and found the function it gets
the credentials from:

char    *authz_ldap_get_userdn(request_rec *r) {
    authz_ldap_config_rec   *sec;
    sec = ap_get_module_config(r->per_dir_config,
&authz_ldap_module);
    return sec->userdn;
}

Here is the debugging lines for mod_authz_ldap from my apache logs:

[Mon Aug 30 14:21:07 2004] [debug] authz.c(412): [client 10.10.105.236]
[11032]
authz_ldap_authz called by user '(null)' for URI '/test/'
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(38): [client
10.10.105.236] [11032] initialize LDAP connection
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(60): [client
10.10.105.236] [11032] got ldap connection to *:389 at
0x08dc05d8
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(74): [client
10.10.105.236] [11032] protocol version set to 3
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(135): [client
10.10.105.236] [11032] bind to ldap server succeeded
[Mon Aug 30 14:21:07 2004] [debug] authz.c(423): [client 10.10.105.236]
[11032]
LDAP connection established
[Mon Aug 30 14:21:07 2004] [debug] authz.c(446): [client 10.10.105.236]
[11032]
starting with return code 0
[Mon Aug 30 14:21:07 2004] [debug] authz.c(460): [client 10.10.105.236]
[11032]
processing requirement role 507
[Mon Aug 30 14:21:07 2004] [debug] authz.c(513): [client 10.10.105.236]
[11032]
role(s) required: 507
[Mon Aug 30 14:21:07 2004] [debug] authz.c(199): [client 10.10.105.236]
[11032]
allocating 20 bytes for role filter
[Mon Aug 30 14:21:07 2004] [debug] authz.c(204): [client 10.10.105.236]
[11032]
role filter: (gidNumber=507)
[Mon Aug 30 14:21:07 2004] [debug] filterexpand.c(50): [client
10.10.105.236] performing substitutions in filter '(gidNumber=507)'
[Mon Aug 30 14:21:07 2004] [debug] filterexpand.c(102): [client
10.10.105.236] filter substitutions give new filter '(gidNumber=507)'
[Mon Aug 30 14:21:07 2004] [debug] authz.c(47): [client 10.10.105.236]
[11032] checking filter '(null)' for user '(gidNumber=507)'
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(174): [client
10.10.105.236] [11032] search from '(null)' for '(gidNumber=507)'
returns 32
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(191): [client
10.10.105.236] [11032] retry the search
[Mon Aug 30 14:21:07 2004] [error] [client 10.10.105.236] ldap [11032]
search for filter '(gidNumber=507)', scope = 0 on user '(null)' failed
[Mon Aug 30 14:21:07 2004] [debug] authz.c(209): [client 10.10.105.236]
[11032]
role requirement failed
[Mon Aug 30 14:21:07 2004] [debug] authz.c(585): [client 10.10.105.236]
authz_ldap_authz()[11032]: elapsed time: 37ms, cpu time: 0ms
[Mon Aug 30 14:21:07 2004] [debug] authz.c(587): [client 10.10.105.236]
[11032]
return code from authz_ldap_authz: NOK (403)


  on in httpd-2.0, so I'm not sure exactly where the error is coming from.
one thing of interest is that in the former code they call
ap_get_basic_auth_pw() from the authz phase, which is clearly wrong and will
subvert the approach I outlined above.  but if you can't set the
Authorization header either (recipe 13.4) and have it work then I don't know.

anyway, if you give me a pointer to the mod_auth_ldap code you're using I
can look it over and see, but there are only a few different places where
the user information can come from - $r->user directly, or from the
Authorization header.

well, I guess there is a third - mod_auth_ldap could assume (or require)
that it is the authentication handler and instead of looking in those two
places it could rely on some internal cache.  in fact, this seems to be the
case, as the "AuthLDAPAuthoritative" directive seems to be designed exactly
for this purpose.  the docs indicate that you should set it to "no" if you
want to use something other than mod_auth_ldap for the authentication phase,
which is what you are trying to do.  so, have you set this directive and
tried 

Re: Trick PerlAuthzHandler into thinking Basic Auth occurred

[Geoffrey Young]

> Ooops, yeah.  A follow-up email corrected "mod_authz_ldap" to
> "mod_auth_ldap".  Sorry 'bout that.  To give a bit more detail, I am
> using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0.  Went looking
> through the C code of the authz module and found the function it gets
> the credentials from:
> 
> char*authz_ldap_get_userdn(request_rec *r) {
>authz_ldap_config_rec   *sec;
>sec = ap_get_module_config(r->per_dir_config, &authz_ldap_module);
>return sec->userdn;
> }

well, close - I think it's authz_ldap_set_username but the problem is the
same...

basically, mod_authz_ldap is caching the given username in it's private
stash - r->per_dir_config is generally used to refer to the httpd.conf
configuration data that applies to the current request.  so, what I think is
going on here is one of the scenarios I posited before:
authz_ldap_set_username is only called in auth.c, so if you don't use
mod_authz_ldap to do your authentication then you are SOL, since it uses
it's cached version of the username instead of grabbing it from one of the
standard places after authentication.

my suggestion would be to play around with the mod_auth_ldap that ships with
httpd-2.0 - it is likely to be moved from experimental in the next release
IIRC and is much more well-behaved (judging from both the authors and
conversations I've been following).

another approach is to try to play around with this module's private data.
you can use this code as an example
  http://www.modperlcookbook.org/code/ch08/Cookbook-LanguagePriority-0.01.tar.gz

but I'm afraid the corresponding explanations are not online.  and I haven't
(yet) proven that this approach works with 2.0, so YMMV.

HTH

--Geoff

-- 
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: Trick PerlAuthzHandler into thinking Basic Auth occurred

[David Castro]

on 08/30/04 15:01 Geoffrey Young wrote:

  
Ooops, yeah.  A follow-up email corrected "mod_authz_ldap" to
"mod_auth_ldap".  Sorry 'bout that.  To give a bit more detail, I am
using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0.  Went looking
through the C code of the authz module and found the function it gets
the credentials from:

char*authz_ldap_get_userdn(request_rec *r) {
   authz_ldap_config_rec   *sec;
   sec = ap_get_module_config(r->per_dir_config, &authz_ldap_module);
   return sec->userdn;
}

  
  
well, close - I think it's authz_ldap_set_username but the problem is the
same...

basically, mod_authz_ldap is caching the given username in it's private
stash - r->per_dir_config is generally used to refer to the httpd.conf
configuration data that applies to the current request.  so, what I think is
going on here is one of the scenarios I posited before:
authz_ldap_set_username is only called in auth.c, so if you don't use
mod_authz_ldap to do your authentication then you are SOL, since it uses
it's cached version of the username instead of grabbing it from one of the
standard places after authentication.

my suggestion would be to play around with the mod_auth_ldap that ships with
httpd-2.0 - it is likely to be moved from experimental in the next release
IIRC and is much more well-behaved (judging from both the authors and
conversations I've been following).

another approach is to try to play around with this module's private data.
you can use this code as an example
  http://www.modperlcookbook.org/code/ch08/Cookbook-LanguagePriority-0.01.tar.gz

but I'm afraid the corresponding explanations are not online.  and I haven't
(yet) proven that this approach works with 2.0, so YMMV.
  

Yeah, I just found that in authz_ldap_set_username too.  Sigh.  

Well, thanks for your help.

  
HTH

--Geoff

  



-- 
David Castro
Software Architect
Azusa Pacific University

"My little children, let us not love in word or in tongue,
but in deed and in truth." -- 1 Jn 3:18 (NKJ) 

Re: Trick PerlAuthzHandler into thinking Basic Auth occurred

[David Castro]

Okay, a little more tracking down revealed that handler #5 ("check if
the user is ok _here_") is never getting called when my module is being
used, but is for Basic auth.  Happen to know under which circumstances
this occurs/doesn't occur?  Maybe there is something else I can set to
get that mechanism called in the first place.  This appears to be the
main problem I have right now, preventing me from moving forward.


on 08/30/04 15:12 David Castro wrote:

  
  
on 08/30/04 15:01 Geoffrey Young wrote:
  

  Ooops, yeah.  A follow-up email corrected "mod_authz_ldap" to
"mod_auth_ldap".  Sorry 'bout that.  To give a bit more detail, I am
using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0.  Went looking
through the C code of the authz module and found the function it gets
the credentials from:

char*authz_ldap_get_userdn(request_rec *r) {
   authz_ldap_config_rec   *sec;
   sec = ap_get_module_config(r->per_dir_config, &authz_ldap_module);
   return sec->userdn;
}



well, close - I think it's authz_ldap_set_username but the problem is the
same...

basically, mod_authz_ldap is caching the given username in it's private
stash - r->per_dir_config is generally used to refer to the httpd.conf
configuration data that applies to the current request.  so, what I think is
going on here is one of the scenarios I posited before:
authz_ldap_set_username is only called in auth.c, so if you don't use
mod_authz_ldap to do your authentication then you are SOL, since it uses
it's cached version of the username instead of grabbing it from one of the
standard places after authentication.

my suggestion would be to play around with the mod_auth_ldap that ships with
httpd-2.0 - it is likely to be moved from experimental in the next release
IIRC and is much more well-behaved (judging from both the authors and
conversations I've been following).

another approach is to try to play around with this module's private data.
you can use this code as an example
  http://www.modperlcookbook.org/code/ch08/Cookbook-LanguagePriority-0.01.tar.gz

but I'm afraid the corresponding explanations are not online.  and I haven't
(yet) proven that this approach works with 2.0, so YMMV.
  
  
Yeah, I just found that in authz_ldap_set_username too.  Sigh.  
  
Well, thanks for your help.
  
HTH

--Geoff

  
  
  
  
  -- 
David Castro
Software Architect
Azusa Pacific University

"My little children, let us not love in word or in tongue,
but in deed and in truth." -- 1 Jn 3:18 (NKJ) 
  



-- 
David Castro
Software Architect
Azusa Pacific University

"My little children, let us not love in word or in tongue,
but in deed and in truth." -- 1 Jn 3:18 (NKJ) 

Re: Trick PerlAuthzHandler into thinking Basic Auth occurred

[Geoffrey Young]

David Castro wrote:
> Okay, a little more tracking down revealed that handler #5 ("check if
> the user is ok _here_") is never getting called when my module is being
> used, but is for Basic auth.  Happen to know under which circumstances
> this occurs/doesn't occur?  Maybe there is something else I can set to
> get that mechanism called in the first place.  This appears to be the
> main problem I have right now, preventing me from moving forward.

I don't see anything funny in the code to short-circuit the request cycle,
so I would assume that things progress as they ordinarily would, which is
like this:

  o apache checks for a "Requires" directive, signaling that the authen and
authz phases should be run.

  o the authentication phase runs:

- apache calls mod_perl, which dispatches to your PerlAuthenHandler.

- your PerlAuthenHandler returns OK and ends the authen phase.  or your
handler returns 403 (or some other error) and immediately goes to the
logging phase.

  o the authorization phase runs

- apache calls mod_perl, which dispatches to your PerlAuthzHandler (if
any).  if that handler returns OK then thus ends the authz phase, and
mod_authz_ldap will _not_run.  if there are no PerlAuthzHandlers registered
then apache will dispatch to mod_authz_ldap.

basically, these parts are somewhat separated from eachother - apache will
call whatever handlers are registered (your #5 above) and those handlers
will run unless the handlers themselves take special steps to avoid being
run (and return DECLINED so other authentication can occur).  I don't see
any signs of that, so I don't know what to say.  that is, other than check
out the mod_auth_ldap that ships with httpd-2.0 and see if it is any better
behaved than this module.

HTH

--Geoff

-- 
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

[mp2] Perl Sections in .htaccess files leak memory

[Rici Lake]

In the course of trying to figure out why mod_info does not reveal 
directives added in PerlSections (see other email), I stumbled across 
the following problem:

I created a simple seven-line .htaccess file, and did 100,000 requests 
to a file in the corresponding directory with ab. All processes were 
perfectly stable in memory consumption. Then I do the same thing with a 
 section in the .htaccess file. 100,000 requests later my 12 
processes had grown from 6.5M to 25.5M

My analysis of this is that mod_perl's perl sections are *always* run 
in the pconf pool, rather than running in the request pool as would be 
normal for .htaccess files. Consequently, all directive parsing and 
config merging will use the pconf pool, effectively resulting in a 
permanent expansion of that pool.

--
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

[mp2] ANN: possibly useful debugging tool for Perl Sections

[Rici Lake]

While trying to debug an issue with a  section in mod_perl2, I 
noticed that these sections are not shown in mod_info's output. I also 
ran into some issues in mod_info itself.

In case these tools are useful to someone else, I have placed the new 
improved mod_info.c and a patch for mod_perl-1.99.16 at: 
 and 
.

The mod_info.c is plug-compatible with the existing mod_info; it fixes 
some issues with nested directives and adds an additional option: 
http://server/server-info?config will show the entire configuration (or 
at least, most of it -- exec-on-read directives may not show up) with 
filenames and line numbers. (Actually, all the listings have filenames 
and line numbers, so it is not 100% compatible with the old output, in 
case anyone has scripts which try to interpret the information.)

The patch enables mod_perl-generated sections to be included in the 
listing; it simply attaches the newly generated configtree as a child 
to the (inserted) Perl directive. The Perl directive itself is not 
displayed very well, unfortunately, but it's a start.

Use them with my blessing.
Rici
--
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

perl modules not running after 'minor' change

[Ben Hopkins]

I'm running RH 8, apache 1.3.23, mod_perl 1.29.  They wanted me to 
install a CMS (Plone) that uses Zope, which requires that I put 
mod_proxy into the apache setup.  So I redid the apache ./configure 
(forgetting about mod_perl for the moment).

Then I remembered about mod_perl, learned about APACI args and 
everything, and it make'd just fine all the way through the install. 
Except for one problem:  my mod_perl modules are not running.  I have a 
module defined as a PerlHandler for location "/" which inserts a bit of 
javascript into each outgoing html doc, and another PerlAuthenHandler 
for a directory they wanted protected.  Neither of those runs anymore. 
No error messages in the logs, either (except for a 500 error when the 
protected directory is accessed -- it says "configuration error:  
couldn't check user.  No user file?", which it wouldn't say if it had 
run my handler).

I configured it like this:
$ perl Makefile.PL `cat make_args`
--where make_args looks like this:
USE_APACI=1 \
EVERYTHING=1 \
DO_HTTPD=1 \
APACHE_SRC=../apache_1.3.23/src \
APACI_ARGS=--enable-module=proxy,--enable-module=rewrite,--enable-module=speling,--enable-module=so,--prefix=/usr/local/apache 

Here is the relevant parts of httpd.conf:
Towards the beginning is this line:
LoadModule perl_modulelibexec/libperl.so
Then, later is this section:
PerlRequire conf/startup.pl
PerlFreshRestart On
PerlModule Apache::AuthPwd

   SetHandler perl-script
   PerlHandler Apache::putInJava


   SetHandler perl-script
   PerlHandler Apache::HelloWorld


   AuthName  " -- Use your regular name in the User Name field -- "
   AuthType Basic
   PerlAuthenHandler Apache::AuthPwd
   require valid-user

(The /howdy location was thrown in at the last minute as a test -- it 
didn't work.)

Here is httpd -l output:
Compiled-in modules:
 http_core.c
 mod_env.c
 mod_log_config.c
 mod_mime.c
 mod_negotiation.c
 mod_status.c
 mod_include.c
 mod_autoindex.c
 mod_dir.c
 mod_cgi.c
 mod_asis.c
 mod_imap.c
 mod_actions.c
 mod_speling.c
 mod_userdir.c
 mod_alias.c
 mod_rewrite.c
 mod_access.c
 mod_auth.c
 mod_proxy.c
 mod_expires.c
 mod_so.c
 mod_setenvif.c
 mod_perl.c
And I wrote a little script to print the contents of Apache::MyConfig, 
which says,
APACHE_HEADER_INSTALL: 1
APACHE_PREFIX:
APACHE_SRC: ../apache_1.3.23/src
APACI_ARGS: 
--enable-module=proxy,--enable-module=rewrite,--enable-module=speling,--enable-module=so,--prefix=/usr/local/apache 

APXS:
Apache_Src: ../apache_1.3.23/src
DO_HTTPD: 1
NO_HTTPD: 0
PERL_ACCESS: 1
PERL_AUTHEN: 1
PERL_AUTHZ: 1
PERL_CHILD_EXIT: 1
PERL_CHILD_INIT: 1
PERL_CLEANUP: 1
PERL_CONNECTION_API: 1
PERL_DEBUG:
PERL_DIRECTIVE_HANDLERS: 1
PERL_DISPATCH: 1
PERL_FILE_API: 1
PERL_FIXUP: 1
PERL_HANDLER: 1
PERL_HEADER_PARSER: 1
PERL_INIT: 1
PERL_LOG: 1
PERL_LOG_API: 1
PERL_METHOD_HANDLERS: 1
PERL_POST_READ_REQUEST: 1
PERL_RESTART: 1
PERL_SECTIONS: 1
PERL_SERVER_API: 1
PERL_SSI: 1
PERL_STACKED_HANDLERS: 1
PERL_STATIC_EXTS:
PERL_TABLE_API: 1
PERL_TRACE: 0
PERL_TRANS: 1
PERL_TYPE: 1
PERL_URI_API: 1
PERL_USELARGEFILES: 1
PERL_UTIL_API: 1
PREP_HTTPD: 0
SSL_BASE:
USE_APACI: 1
USE_APXS: 0
What am I doing wrong?
--
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

handling multipart/form-data POSTed content in mod_perl 2.0

[Scott Fagg]

Can someone point me in the direction of a worked example of handling
multipart/form-data POSTed content in mod_perl 2.0 ? 

Closest i've come is a sample bit of code that just dumps the contents,
but not parses it and i haven't been able to find any modules that help
in parsing.



--
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: handling multipart/form-data POSTed content in mod_perl 2.0

[Markus Wichitill]

Scott Fagg wrote:
Can someone point me in the direction of a worked example of handling
multipart/form-data POSTed content in mod_perl 2.0 ? 

Closest i've come is a sample bit of code that just dumps the contents,
but not parses it and i haven't been able to find any modules that help
in parsing.
http://httpd.apache.org/apreq/
--
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: handling multipart/form-data POSTed content in mod_perl 2.0

[Scott Fagg]

> -Original Message-
> From: Markus Wichitill [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, 31 August 2004 4:16 PM
> To: Scott Fagg
> Cc: 
> Subject: Re: handling multipart/form-data POSTed content in 
> mod_perl 2.0
> 
> Scott Fagg wrote:
> > Can someone point me in the direction of a worked example 
> of handling 
> > multipart/form-data POSTed content in mod_perl 2.0 ?
> > 
> > Closest i've come is a sample bit of code that just dumps the 
> > contents, but not parses it and i haven't been able to find any 
> > modules that help in parsing.
> 
> http://httpd.apache.org/apreq/

many thanks.

> 
> 
> 

--
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