Apache 2.1 for Apache::AuthenHook
Hi - I guess I haven't been paying attention, but the module Apache::AuthenHook requires Apache 2.1 - not 2.0, according to the documentation. What is Apache 2.1? Is it available? I can't find reference to it on apache.org. Aloha => Beau; -- 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: Apache 2.1 for Apache::AuthenHook
On Mon, Mar 29, 2004 at 11:27:34PM -1000, Beau E. Cox wrote: > What is Apache 2.1? Is it available? I can't find reference to it > on apache.org. > Apache 2.1 is cvs HEAD - while 2.0.x is BRANCH_2_0. There has been no releases in 2.1 yet (mostly waiting for apr 1.0 afaict). The whole auth system has been overhauled in 2.1 (a change that was also in the 2.0 brach around 2.0.43, but which was backed out and moved to 2.1) vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall -- 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: Apache 2.1 for Apache::AuthenHook
On Monday 29 March 2004 11:40 pm, Mads Toftum wrote: > On Mon, Mar 29, 2004 at 11:27:34PM -1000, Beau E. Cox wrote: > > What is Apache 2.1? Is it available? I can't find reference to it > > on apache.org. > > Apache 2.1 is cvs HEAD - while 2.0.x is BRANCH_2_0. There has been > no releases in 2.1 yet (mostly waiting for apr 1.0 afaict). The whole > auth system has been overhauled in 2.1 (a change that was also in the > 2.0 brach around 2.0.43, but which was backed out and moved to 2.1) > > vh > Thanks Mads - I missed it. Up and running! Aloha => Beau; -- 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-AuthenSmb-0.72
Tauber, Mathias HDP wrote:
Sorry for the late answer...
Hmm... My thought would have been that Apache::AuthenCache
would do the
trick... What are the exact symptoms when you use
AuthenCache? Are you
still hitting the Domain controller for every request?
Yes, still like DoS...
:(
Haven't tried this, but I was told to add this to the module:
(Version 0.6, Debian Release)
sub authen {
my @args = @_;
# Truncate everything to length 80 to avoid poor coding practices in the
# smbvalid.a (buffer overflows) PMK--fixme in smbvalid.a when possible.
for my $i ( 0..$#args ) {
$args[$i] = substr($args[$i], 0, 80);
}
my($username, $password, $server, $backup, $domain) = @args;
#new: open L, "> /tmp/AuthenSmb.lck" or die "Can't open /tmp/AuthenSmb.lck:
$!\n";
#new: flock L, LOCK_EX;
my $res = Valid_User($username, $password, $server, $backup, $domain);
#new: close L;
return $res
}
This changes work, but I don't know how secure this solution is.
How secure is 'return OK unless $r->is_initial_req;'? What's the
(technical) difference between the initial and the rest? Isn't
it easy to fake at this point?=
The excerpt from X, (sorry, I forgot their name :( ), uses a semaphore
to maintain the connection, where
'return OK unless $r->is_initial_req;'
uses a flag in the request object to bypass the authentication module if the flag is set. (It is set after the first successful pass through the module. Therefore, you have an increase in efficiency, (no I/O calls), and you are playing within Apache and mod_perl. (Plus, the username/password and server information are not left lying around in storage for someone to find ;) )
HTH,
--
Shannon Eric Peevey => "speeves"
Dyno-Mite! System Administrator => [EMAIL PROTECTED]
Central Web Support => (940) 369-8876
University of North Texas => http://web2.unt.edu
--
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-AuthenSmb-0.72
> The excerpt from X, (sorry, I forgot their name :( ), uses a > semaphore > to maintain the connection, where > > 'return OK unless $r->is_initial_req;' > > uses a flag in the request object to bypass the > authentication module if the flag is set. (It is set after > the first successful pass through the module. Therefore, you > have an increase in efficiency, (no I/O calls), and you are > playing within Apache and mod_perl. (Plus, the > username/password and server information are not left lying > around in storage for someone to find ;) ) How is the first request identified? Is there a http-session set, or is it IP-based? How is a client identified? - mathias - -- 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-AuthenSmb-0.72
How is the first request identified? Is there a http-session set, or is it IP-based? How is a client identified? Basically, this only deals with subrequests for each individual request. This doesn't set a session for the whole time the user is interfacing with your application. If you need something that does that, then you should look at programmatically creating a session through a cookie, (apache::authcookientlm comes to mind), or some other tool that is used to maintain state during the user's session. Apache-AuthenSmb only authenticates the user, it doesn't maintain state. (It is beyond the scope of the module) -- Shannon Eric Peevey => "speeves" Dyno-Mite! System Administrator => [EMAIL PROTECTED] Central Web Support => (940) 369-8876 University of North Texas => http://web2.unt.edu -- 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: Apache 2.1 for Apache::AuthenHook
Beau E. Cox wrote: > On Monday 29 March 2004 11:40 pm, Mads Toftum wrote: > >>On Mon, Mar 29, 2004 at 11:27:34PM -1000, Beau E. Cox wrote: >> >>>What is Apache 2.1? Is it available? I can't find reference to it >>>on apache.org. >> >>Apache 2.1 is cvs HEAD - while 2.0.x is BRANCH_2_0. There has been >>no releases in 2.1 yet (mostly waiting for apr 1.0 afaict). The whole >>auth system has been overhauled in 2.1 (a change that was also in the >>2.0 brach around 2.0.43, but which was backed out and moved to 2.1) >> >>vh >> > > Thanks Mads - I missed it. Up and running! cool, I'm glad it's working for you. and sorry about the lack of instructions - it was originally written for this article http://www.perl.com/pub/a/2003/07/08/mod_perl.html which includes links to how to get 2.1. I'll add the details to the module docs as well. thanks --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: [Apache-Test] ulimit on Solaris bash
That sounds about right. I would also recommend adding something to the README for Solaris 8 & 9 indicating that core files may not be generated, even if they normally would be, depending on the initial ulimit -c setting. I say 8 & 9 because I don't know if the ulimit restriction has always been there or if it changed at some point. Rob -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 5:04 PM To: Obitz, Toby Cc: Kinyon, Rob; [EMAIL PROTECTED] Subject: Re: [Apache-Test] ulimit on Solaris bash Obitz, Toby wrote: > Yes, I was successfully able to validate Rob's issue... > > Sorry about that. I'm working on a development box, so I typically use > root to avoid permission type issues. So the logic should be: skip running 'ulimit' if $^O eq 'solaris' and $user ne 'root'. it that correct? > Obitz, Toby wrote: > >>As root. Sorry, I think I may have misunderstood the question. > > > And as normal user? That's what Rob was saying: > > ... only superuser can set the ulimit -c up ... __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.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: Apache::Cookie not finding cookies ...
Nick Phillips wrote: On 30/03/2004, at 5:21 AM, Brian Clarkson wrote: I'm hoping that I'm doing something wrong ... I've tried the logout.pl that comes in the Apache::AuthCookie dist, but that didn't work. My code has an object that has an Apache::Request object stuffed into it, and: I don't have an object ... I'm firing off logout.pl ( ok, logout.cgi ) as a script. it's in a mod_perl configured directory ... SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI allow from all PerlSendHeader On I tried your code, tried the cookies, but I don't have anything in $authType or in the %cookies hash i tried earlier. my $r = Apache->request; my $authType = $r->auth_type(); and $authType is empty i just want to get this to work so i can move on ... --b-- -- 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
Exported methods don't reload under Apache::StatINC
I have a question about Apache::StatINC and reloading exported methods.
Apparently methods that are exported from a module do not get reloaded
when the module changes on disk (see the test script and test module
below).
To test this, I start my apache in single process mode via '-X' and
access the URL for my test script and note the result. I then edit the
module, changing the text it prints out, and access the URL again. The
text remains unchanged.
If I change the function call to include the full package name and
access the URL, then I see the changes I made to the module.
If I leave the function call unqualified, but use the option:
PerlSetVar StatINC_UndefOnReload On
then I see the changes I made in the module.
So, the solution to my problem seems to be that I use the
'StatINC_UndefOnReload' setting. However, the man page says this
setting is for eliminating Perl warnings about re-defined subroutines,
not making Apache::StatINC work with exported methods. I'm not a big
fan of changing things until they work without understanding why,
because there's a good chance the fix was just coincidence and I'll get
bitten later with broken code.
Has anyone experienced this or know why this might be happening? Can
anyone explain why/if I can feel safe using 'StatINC_UndefOnReload' to
get the behavior I want? Thanks!
Here is the test script:
#!/usr/local/bin/perl -w
use strict;
use TestINC;
print "Content-Type: text/plain\n\n";
print "Calling test function: ";
testit();
print "Done\n";
and this is the test module:
package TestINC;
BEGIN {
use Exporter ();
use vars qw(@ISA @EXPORT);
@ISA= qw(Exporter);
@EXPORT = qw(testit);
}
sub testit {
print "testing!!!\n";
}
1;
--
|- Garth Webb -|
|- [EMAIL PROTECTED] -|
signature.asc
Description: This is a digitally signed message part
[mp2] mod_perl (current cvs) and multiple Apache2s make problems
Hi -
I have 2 Apache2s on my test server:
Apache 2.0.50-dev(cvs) installed in /home/test/usr/apache2
and:
Apache 2.1 (cvs) installed in /home/test/usr/apache2.1
When generating mod perl with:
perl Makefile.PL MP_APXS=/home/test/use/apache2.1/sbin/apxs
the test httpd.conf file is generated based upon Apache2.0, i.e.:
looking at /home/test/usr/apache2.
I use this layout for Apache2.1:
# my test layout - Apache 2.1
prefix:/home/test/usr/apache2.1
exec_prefix: ${prefix}
bindir:${prefix}/bin
sbindir: ${prefix}/sbin
libdir:${prefix}/lib
libexecdir:${prefix}/lib/apache
mandir:${prefix}/share/man
sysconfdir:/home/test/httpd/conf
datadir: /home/test/httpd
installbuilddir: ${datadir}/build
errordir: ${datadir}/error
iconsdir: ${datadir}/icons
htdocsdir: ${datadir}/htdocs
manualdir: ${datadir}/manual2.1
cgidir:${datadir}/cgi-bin
includedir:${prefix}/include
localstatedir: /home/test/var/lib/httpd
runtimedir:/home/test/var/run
logfiledir:/home/test/var/log/httpd
proxycachedir: /home/test/var/cache/httpd
How do I control how t/config/httpd.conf is setup?
Aloha => Beau;
--
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: Exported methods don't reload under Apache::StatINC
Garth Webb wrote: I have a question about Apache::StatINC and reloading exported methods. Garth, Apache::StatINC is deprecated and no longer maintained. Please use Apache::Reload instead (mp1 version on CPAN, mp2 version is a part of the core). > Apparently methods that are exported from a module do not get reloaded > when the module changes on disk (see the test script and test module > below). That's right. Please read: http://perl.apache.org/docs/2.0/api/Apache/Reload.html#Problems_With_Reloading_Modules_Which_Do_Not_Declare_Their_Package_Name -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.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: [mp2] mod_perl (current cvs) and multiple Apache2s make problems
Beau E. Cox wrote: Hi - I have 2 Apache2s on my test server: Apache 2.0.50-dev(cvs) installed in /home/test/usr/apache2 and: Apache 2.1 (cvs) installed in /home/test/usr/apache2.1 Apache 2.1 is not officially supported at the moment. If you want to play with it you are on your own, Beau. Geoff might be interested, but I know he is very busy at the moment. > How do I control how t/config/httpd.conf is setup? What seems to be the problem? __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.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: [mp2] mod_perl (current cvs) and multiple Apache2s make problems
Beau E. Cox wrote:
> Hi -
>
> I have 2 Apache2s on my test server:
>
> Apache 2.0.50-dev(cvs) installed in /home/test/usr/apache2
>
> and:
>
> Apache 2.1 (cvs) installed in /home/test/usr/apache2.1
>
> When generating mod perl with:
>
> perl Makefile.PL MP_APXS=/home/test/use/apache2.1/sbin/apxs
>
> the test httpd.conf file is generated based upon Apache2.0, i.e.:
> looking at /home/test/usr/apache2.
> How do I control how t/config/httpd.conf is setup?
I run both 2.0 and 2.1 on my test box. as long as you 'make realclean'
between mod_perl builds you shouldn't run into problems. if you do run into
issues, try adjusting these lines to suit your build environment (which are
part of my nightly build script at the moment but might not be needed any more).
$ find /perl/ -name TestConfigData.pm -exec sudo rm -f {} \;
$ find /src/mod_perl-2.0 -name TestConfigData.pm -exec rm -f {} \;
$ rm -rf /home/geoff/.apache-test
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: [mp2] mod_perl (current cvs) and multiple Apache2s make problems
On Tuesday 30 March 2004 05:32 pm, Stas Bekman wrote: > Beau E. Cox wrote: > > Hi - > > > > I have 2 Apache2s on my test server: > > > > Apache 2.0.50-dev(cvs) installed in /home/test/usr/apache2 > > > > and: > > > > Apache 2.1 (cvs) installed in /home/test/usr/apache2.1 > > Apache 2.1 is not officially supported at the moment. If you want to play > with it you are on your own, Beau. Geoff might be interested, but I know he > is very busy at the moment. OK - I'll try not to pester you and Geoff. > > > How do I control how t/config/httpd.conf is setup? > > What seems to be the problem? Well, the t/config/httpd.conf generated somewhere in the mod_perl build - I couldn't find it on first glance - is based on the Apache 2.0 configuration, NOT the Apache 2.1 configuration. I am looking for a parameter (or patch) to Makefile.PL to force the generation from the Apache 2.1 httpd.conf. Aloha => Beau; -- 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: [mp2] mod_perl (current cvs) and multiple Apache2s make problems
Beau E. Cox wrote: > How do I control how t/config/httpd.conf is setup? What seems to be the problem? Well, the t/config/httpd.conf generated somewhere in the mod_perl build - I couldn't find it on first glance - is based on the Apache 2.0 configuration, NOT the Apache 2.1 configuration. I am looking for a parameter (or patch) to Makefile.PL to force the generation from the Apache 2.1 httpd.conf. That's only an issue if you are using a 3rd party module with Apache-Test and previously run tests with a different server. As Geoff has mentioned those configurations are sticky and saved, so in a typical user case you never need to type them more than once (actually you never need to type them at all if you installed Apache-Test when installing mod_perl 2.0. In the case you are switching server, you need to tell Apache-Test what are the new parameters, e.g.: APACHE_TEST_HTTPD=/PATH/TO/HTTPD make test or t/TEST -httpd=/path/to/httpd etc. please refer to the documentation for more options. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.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
