Re: Newbie: make test failure!
On Sat, 8 Jul 2000, Greg Leidreiter wrote: > Config: > mod_perl-1.24 > perl v5.6.0 > apache 1.3.12 > RedHat linux 6.1, kernel 2.2.12 > > Using: > > [/usr/local/apahce/build/mod_perl-1.24]# perl Makefile.PL \ > EVERYTHING=1 \ > APACHE_PREFIX=/usr/local/apache > > everything seems to look ok (to me) for both this and 'make' > but when I run 'make test' > > I get: > > ... > httpd listening on port 8529 > will write error_log to: t/logs/error_log > letting apache warm up...\c > done > /usr/bin/perl t/TEST 0 > still waiting for server to warm up.not ok > server failed to start! (please examine t/logs/error_log) at t/TEST line > 95. > make: *** [run_tests] Error 9 > I always get that error. I always ignore the error and everything seems to work fine. Did the same thing with the older perl and older versions of apache and mod-perl. Such is life :-)
Re: redirecting a domain
Sure, load the page in a frame that hides the second url request On Fri, 14 Jul 2000, Sam Carleton wrote: > I have an apache question and I have NO idea where to post it. Is there > a newsgroup or mailing list simply for apache? > > I have multipal domain names: domain.net & domain.org. I would like to > configure apache such that when someone goes to www.domain.org, they are > "redirect" to www.domain.net. They are both the exact same web site, I > simply want the domain name to show up as www.domain.net. Any thoughs > on how to do that? > > Sam >
Re: RFC: Apache::Reload
On Sat, 12 Aug 2000, Leslie Mikesell wrote:
> According to Matt Sergeant:
> >
> > package Apache::Reload;
>
> What I've always wanted along these lines is the ability
> to load something in the parent process that would take
> a list of directories where modules are always checked
> and reloaded (for your local frequently changed scripts)
> plus one filename that is checked every time and if it
I use this simple library module. It is called from the beginning of the
first script encountered in a set of scripts. This substitutes for a
require statement for the corresponding modules.
Call as:
unshift @INC, './lib';
require 'LibChk.pl';
&LibChk::Install (# check libraries for currency
'WhoisLib.pl',
'SocksLib.pl',
'DomRegLib.pl',
);
library:
#!/usr/bin/perl
#
# LibChk.pl
#
# version 1.01 6-16-00
# copyright Michael Robinton [EMAIL PROTECTED]
#
# WARNING!! httpd must be 'HUP'ed if this library is modified
#
# check for library changes and load if necessary or not present
#
package LibChk;
use vars qw ( %Modified ); # library modification times
# Input:list of libraries (path must be in @INC)
sub Install {
foreach my $i (@_) {
if ( ! exists $Modified{$i} || # if undefined time
! exists $INC{$i} || # missing
$Modified{$i} != (stat "./$INC{$i}" )[9] ) { # or changed
delete $INC{$i} if defined $INC{$i};
require $i;
$Modified{$i} = (stat "./$INC{$i}" )[9];
}
}
}
1;
Re: Apache::ASP #include file
> > Recently, I reinstalled mod_perl and Apache::ASP on my system in order to > > fix a problem I was having with ASP not using the new version of perl on > > my system. However, I'm having problem with some old code. > > > > That functionality was never intended to be supported, and > am surprised it ever worked! How painful would it be for > you to change your includes to be like > apache_ssl and mod_perl co-exist nicely together, try that instead. I've a couple of these in production environments that work very well. Michael
Re: Apache::ASP #include file
> On Sat, 26 Aug 2000, Michael Robinton wrote: > > > apache_ssl and mod_perl co-exist nicely together, try that instead. I've > > a couple of these in production environments that work very well. > > I don't understand... what does SSL have to do with this? > > -Philip Mak ([EMAIL PROTECTED]) > Oops, responded to the wrong thread ... gotta backup and take another look
Re: Dynamic Directory Protection - An authorization related question.
> > I am trying to implement a database driven solution for a small university > website (300+ users) and quite happy with Authentication and Authorization > packages provided by mod_perl. However, there doesn't seems to be a solution > to dynamically protect a directory without restarting Apache. > > What I will like to do: > Store the URI need to be protected in the database with the > permitted Groups. > You can do that by changing the user portion of that authenticates the credentials and returns the session key. Place the allowed directories in the encrypted key. In the auth- session key portion you can check all kinds of things like the allowed path, session expiration, specific files you want disallowed in various directories, etc...
Re: Shroud+ Perl obfuscator....
> And if they do have something to protect, they should put their > thinking caps on and realize that this sort of "security" is called > obfuscation for a reason: it does not accomplish anything except to > make the results hard to read. If you're giving away or selling the > perl source, obfuscating it doesn't have any significant effect. I beg to differ. Crypt::License turns the perl source into a non-text file that appears to be pure "binary" when you try to open it. There is less info readable than you would find in the average "C" object. That is what is distributed to the target machines for execution. Only the decrypt engine can decode the file in the presence of the necessary key ... and then, it goes directly into the perl intrepreter. Sure, a clever person could recover it at that point, but the point of most of these exercises is to make it not convenient or cost effective to do so. It works quiet nicely with mod_perl as well as autoloadable modules Michael
Re: Convert Cookies-->HTTP Request Headers?
>On Fri, Apr 04, 2003 at 04:10:03PM -0500, Kruse, Matt wrote: >> I have a unique need purely for testing purposes. I'm not very familiar >> (yet) with mod_perl handlers in Apache, so I've had a rough time >>getting >> anything going. >> Here is my goal: >> >> For every request to Apache: >> 1. Parse the cookie coming in via the request header >> 2. Pull out each value (ex: NAME=bob;TITLE=boss) >> 3. Convert them to HTTP Request Headers >> >Ok, I'm confused: the cookies are already in the request header, >and you want to 'convert' them into a request header? > > 4. Pass the request on to the requested resource (a script of some >sort) > >> So, if I have a cookie like: NAME=bob;TITLE=boss >> My program would then see the following headers in the request: >> HTTP_NAME=bob >> HTTP_TITLE=boss >If you're using an Apache handler, see Apache::Cookie for unpeeling >cookies. >If you're running a classic CGI program, see CGI::Cookie for unpeeling >cookies. >> This will help me simulate a Single-Sign-On situation where the >> authentication handler passes all authenticated user information to the >> resource via headers. > >When you say 'HTTP request headers', did you really mean to say 'CGI >parameters', as the CGI module uses the term? > >> Thanks! >> >> Matt Kruse Also see: Apache::FakeCookie on CPAN for testing cookies without having to load httpd. It replaces the httpd server for generating cookie responses during development and testing of Apache-perl modules Michael
Re: calling htpasswd from perl ...
you use the crypt lib and do a dual password entry. no confirmation is needed if the two passwords match. Everything is handled by the perl script, you don use htpasswd. Crypting is very straightforward. [EMAIL PROTECTED] (in palo alto) On Thu, 9 Dec 1999, dave_dunstan wrote: > Hi gang, I hope this isn't too off-topic, I figure someone will know the > answer right away. I (my client) wants to manage user permissions at a > shared-hosting server. I'd certainly use .htaccess, except this particular > client wants a gui to do this sort of thing (a little form, a little cgi, > boom bing). > > Here's my question - since I can't use an Auth module and a database, can I > write up a widget that will write .htaccess and .htpasswd files ...? I'm > thinking I can call htpasswd from perl, but I'm not sure how I'd have perl > "confirm" the new password at the confirmation prompt from htpasswd. > > Any help would be much appreciated! > Is this just a cracked idea altogether? > > Happy Holidays! > > Dave Dunstan > Mission Control Consulting LLC > 301 8th Street, Suite 215 > San Francisco CA 94103 > ph 415.701.0088 > fx 415.241.0807 >
Re: Compiling mod_perl as a DSO?
On Sun, 30 Jan 2000, Bill Bradford wrote: > Is it possible to compile/install mod_perl as a DSO, on an existing > pre-compiled copy of apache (with mod_so enabled), yet? If so, > how? I couldnt find it in the docs... and I'm tired of having to > statically compile the module in... so any help would be appreciated. > I read on the list at one time that the DSO verson has a memory leak. Don't know if this is still true or not. The static version apparently did not have that problem. If someone knows the answer to this I'd like to know myself as the DSO version is considerably easier to put together with other modules. Michael
Re: Compiling mod_perl as a DSO? (fwd)
On Sun, 30 Jan 2000, Bill Bradford wrote: > Is it possible to compile/install mod_perl as a DSO, on an existing > pre-compiled copy of apache (with mod_so enabled), yet? If so, > how? I couldnt find it in the docs... and I'm tired of having to > statically compile the module in... so any help would be appreciated. > I read on the list at one time that the DSO verson has a memory leak. Don't know if this is still true or not. The static version apparently did not have that problem. If someone knows the answer to this I'd like to know myself as the DSO version is considerably easier to put together with other modules. Michael
Re: runaway httpd processes
> > There are a large number of happy, silent Apache::Session users. > > Yes, I am a silent and happy Apache::Session user. You're right Jeffrey, > happy users should not be silent. > Ditto that. Have Apache::Session serving content for a dynamic chat page. It gets hit every 30 - 45 sec by every user in the chat room -- thousands of hits an hour. It's been running for months without a shutdown or reboot.
Re: mod_perl weaknesses? help me build a case....
> if you use it as a back end > to a lightweight front-end proxy which a busy site needs anyway. My site is starting to get "busy enough". Are there some docs that explain how to to do this. Apache proxy has always seemed unclear to me, my lack of understanding really I've been using standard apache with mod_perl for several years now and have run squid in front of it, but this is a bit of a setup hassle when things change.
Re: BerkeleyDB Problems
> On Tue, Mar 12, 2002 at 11:06:00AM -0500, Mark Matthews wrote:
> > Hello,
> >
> > I am moving a website that now resides on a i686 server running RedHat
> > 6.2 with perl v5.005_03 to another i686 server running Suse 7.1 with
> > perl v5.6.1.
>
> > The website uses a number of cgi scripts that read and write from
> > BerkeleyDB files using the tie function.
> >
> > The site is currently running fine on the RedHat server, but when
> > testing the scripts on the Suse box I am finding the the scripts are
> > failing complaining that the db file cannot be opened.
>
> > The function calling the script is as follows...
> > $db = "blurb";
> > tie(%BLURB, "DB_File", $db, O_RDONLY, 0664) || die("Error: could not
> > open $db: $!\n");
> >
> > Things I have tried so far..
> > - I have checked that the BerkeleyDB file (blurb) in the right path,
and
> > is readable/writable.
> > - I have checked that the DB file is not corrupt by ftping it back to
> > the RedHat box and testing it.. Works fine..
> > - the command "file blurb" shows that the db file is Berkeley DB
(Hash,
> > version 5, native byte-order) and my guess is the version of DB_File
> > cannot read that DB version. I have installed earlier versions of
> > DB_File on the Suse box with no luck.
> > - I have successfully created a new db file using tie. The file
created
> > is version 7.
> >
> > Since these scripts do infact work on the RedHat server, what do I
need
> > to do to get them to work on the Suse server
>
> DB_File is usually implemented on top of whatever the latest
> Berkeley DB is available. The file formats are usually not
> compatible from major version to another major version. I believe
> RH 6.2 uses bdb v2 and Suse uses a newer version 3 or 3.1. Use the
> rpm -q -a command to find out which versions are which.
>
> Anyway, you need to try out the db_upgrade command, it should
> upgrade the db file to the latest format. It might not be installed
> by default, so check your local docs. (I think it's in db3-utils,
> or some such..)
>
> You might also try out the BerkeleyDB module for access to more
> interesting features provided by the later versions of this library.
> In particular the transactions subsystem is very, very cool.
>
> Good Luck
>
> --
It's more complicated than that :-(
Newer versions of Linux (e.g. RedHat 6, SuSe 6) ship with a C library
that has version 2.x of Berkeley DB linked into it. My particular
version has 2.x with header files for 3.x. To make matters worse,
prior to Perl 5.6.1, the perl binary itself included the Berkeley DB
library. This has caused me some headaches which I've solved by
building and installing BDB v 4.x and including the following at the
beginning of the apachecel / httpsdctl file.
# fix up problem with C-lib database
export LD_PRELOAD=/usr/local/BerkeleyDB.4.0/lib/libdb.so
The LD_PRELOAD environment variable to point to the new shared
library, Perl will use it instead of the version of Berkeley DB that
shipped with your Linux distribution.
Maybe this will work for you as well. If you use DBD, make sure and
re-install the DBD / DBI modules with the new pointers to the
database lib.
Michael Robinton
BizSystems
4600 El Camino Real - Ste 206
Los Altos, CA 94022
650-947-3351
Re: Cookies and IE in mod_perl
On Sat, 23 Mar 2002, Jesse and Rebecca Stay wrote:
> Ok - I got rid of the Apache::Cookie stuff, and am now doing things manually,
> but it still doesn't generate a cookie in IE. It still works in Netscape. I
> get a redirect, but no cookie. Here is my code:
>
> my $r = Apache->request;
>
> $r->content_type('text/html');
> $r->err_headers_out->add('Set-Cookie' => 'userSession=test;
> domain=.hainesfamily.org; path=/; expires=Mon, 25-Mar-2002 03:30:43 GMT');
> $r->headers_out->add(Location => $redir);
> $r->status(REDIRECT);
> $r->send_http_header;
>
> my $headers_out = $r->headers_out;
> foreach (keys %$headers_out) {
> warn "$_=$headers_out->{$_}";
> }
>
> return OK;
I think this should be
return 302;
Re: SSL Installation Questions - Help
> On Sat, Mar 09, 2002 at 10:12:32AM -0800, Kirk Rogers wrote: > > Hi all, > > So I went ahead and tried to install apache-ssl and am following the > > instructions to the T. > > > > I've acquired: > > mod_perl-1.26.tar.gz > > openssl-0.9.6c.tar.gz > > apache_1.3.22.tar.gz > > apache_1.3.22+ssl_1.47.tar.gz > > Man this is terrible. > > Having to compile, install, integrate everything yourself is a huge > waste of time. Your are duplicating all the efforts put in by the > distributions, for zero added value. Plus you've got an upgrade > nightmare waiting for you. > It is quite easy actually. do it this way build and install open_ssl untar apache in /usr/src ln -s apache_version apache cp apache_1.3.22+ssl_1.47.tar.gz into the apache directory untar apache_1.3.22+ssl_1.47.tar.gz run ./FixPatch If you wish to use mod_so or any of the other non-standard modules rm src/Configuration rm src/Configuration.apaci edit src/Configuration.tmpl as required i.e. for mod_rewrite, mod_so, etc -- untar mod_perl distribution in the mod perl source directory, ... perl Makefile.PL \ APACHE_SRC=/usr/src/apache/src \ DO_HTTPD=1 \ USE_APACI=1 \ PREP_HTTPD=1 \ EVERYTHING=1 \ make make test # broken make install in apache directory ./configure --with-layout=Apache \ --activate-module=src/modules/perl/libperl.a make make install
bug I think.
Apache/1.3.22 Ben-SSL/1.47 (Unix) DAV/1.0.3 mod_perl/1.26
The function
getservbyport
causes Apache to segfault
when run from a terminal or as a normal cgi script it works fine
when run with mod_perl it crashes.
sample cgi is the part commented out.
#!/usr/bin/perl
my $proto = 'tcp';
my $proto = 'tcp';
my $name = getservbyport($port, $proto);
#print <
#$port, $name
#
#
#EOF
use Apache;
my $r = Apache->request;
my $html = q|
$port, $name
|;
$_ = length($html);
$r->status(200);
$r->content_type("text/html");
$r->header_out("Content-length","$_");
$r->send_http_header;
$r->print ($html);
return 200; # HTTP_OK
Re: [Fwd: Re: Cheap and unique]
> >I'm just curious - what's wrong with the function you're already using? > > Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_) >TIMESTAMP . $$ . $GLOBAL++ I use the above. If you create a global for the child process then that is adequate since the PID belongs to the child and will be unique at least for a second until the next time tick -- it's not plausible to create 65k children in one second. If you need the variable global across multiple servers then include a unique part of the host address as part of the variable in addition to the time stamp. Michael
RE: Porting to OS X
From: "Noam Solomon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: Porting to OS X Date sent:Tue, 4 Jun 2002 13:43:11 -0400 >[ Double-click this line for list subscription options ] > >Can anyone give me a rough idea how much time it would take to move a >server serving >mod_perl websites from UNIX to OS X? It uses Apache::Session, >DBI::Mysql, >HTML::Mason, CGI, >and Apache::OpenIndex, among others, and uses both AuthHandlers and >AuthzHandlers. > >I know it's difficult to estimate without knowing how big the websites >are, what kind of >functions they call, etc., but if you could give me an idea of what kind >of problems I can >expect to encounter and how difficult they are to work around, I can give >a quote to my >client. > >Thanks, >Noam Solomon I'd be very interested in how this progresses. I recently helped a collegue to get a cgi program running under apache using standard perl on OSX -- I found that the perl distribution that comes with OSX is the original 5.6 rather than more up to date versions AND that the application, which runs on an aging 486 with 64 megs in our shop and uses about 4 megs including mod_perl enhanced apache, took 40 megs on OSX and was very slow. This was on a G4 with 500 megs of memory. Michael
[ANNOUNCE] release of LaBrea::Tarpit 1.03
LaBrea::Tarpit is an enhanced reporting module that generates web pages showing the activity of worm and trojan attacks agains your netblock. It uses Tom Liston's "LaBrea" daemon as a front end to provide data for the reports. New Features * paginated reporting, much nicer than the BIG long page *stubs for yet to be announced tracking of ICMP and UDP scans w/ DShield reporting * remote daemon operation -- daemon will run on remote host and can be interrogated to retrieve data for web-scripts. See my demo sites at: http://scans.bizsystems.net/ -- runs on the local host http://probes.bizsystems.net/ -- is in another city, different primary network supplier. Both web sites are hosted on the same web server and report in real time. other interesting stuff added in recent releases: dshield reporting -- mail_dshield.pl reports new attacks to dshield.org old bad guy reports -- tell_me.pl lets you know when an attacking host has been your tarpit for a predetermined length of time other sites reports -- web_scan.pl shows a summary of the activity of other sites running LaBrea::Tarpit Grab the new release from the download site, there is a button on the demo site to reach it. If anyone has a good idea what category all this should be classified under, I'll submit it to CPAN. enjoy, Michael
Re: Getting mod_perl-1.27 & Apache-2.0.39
On Sun, 14 Jul 2002, eric wrote: > I've tried every which way and still can't get mod_perl to compile. > apache 2.x is not supported well at this point You didn't say which SSL you were running, but if it's ben's apache-ssl, this simple set of instructions will work. build and install openssl9.6x (b or c) at least unpack apache_1.3.26 copy apache_1.3.26_ssl_1.48.tgz into apache directory, uppack and run ./FixPatch rm apache/src/Configuration rm apache/src/Configuration.apaci edit apache/src/Configuration.tmpl to enable standard modules you may want that are commented out. Typically that will be something like ... mod_info.o, mod_rewrite.o, mod_so.o libproxy.a now go to the mod perl directory modperl-1.26 or 1.27 Run: perl Makefile.PL \ APACHE_SRC=/usr/src/apache/src \ DO_HTTPD=1 \ USE_APACI=1 \ PREP_HTTPD=1 \ EVERYTHING=1 \ make make test # broken make install This will build modperl and copy the appropriate modules to the apache src directories. Answer YES to the questions asked by script go back to apache directory and run ./configure --with-layout=Apache \ --activate-module=src/modules/perl/libperl.a make make install all done :-) Michael
hiding perl code
ules by virtue of the PerlRequire or PerlModule directives in the users
config file. B, the AuthCookie module B have a
B $ptr2_License inserted in the beginning statements.
=item 5
With all this accomplished, all modules should load and de-crypt without
problem.
=back
=head1 EXPORT
None by default.
=head1 TOOLS
makeCert.pl makes a License document
makeLicenseMod.pl makes only unsplit Licensed modules
makeCrypt.plmakes a split Licensed module
makePOD.pl separates POD from mixed module
mod_parser.pl used by makeCrypt, makePOD, makeLicenseMod
=head1 AUTHOR
Michael Robinton, [EMAIL PROTECTED]
=head1 COPYRIGHT
Copyright 2000 Michael Robinton, BizSystems.
All rights reserved.
=head1 SEE ALSO
L, L
=cut
=head1 NAME
BZS::License::Notice -- perl extension for License
=head1 SYNOPSIS
require BZS::License::Notice;
BZS::License::Notice->check($input_hash)
=head1 DESCRIPTION
=over 4
=item BZS::License::Notice->check($input_data_ptr)
$input_hash_ptr = { # optional parameters
'ACTION'=> 'default /usr/lib/sendmail -t -oi',
'TMPDIR'=> 'default /tmp',
'INTERVALS' => 'default 5d,30d,60d',
'TO'=> 'default [EMAIL PROTECTED]',
# mandatory parameters
'path' => 'path to LICENSE',
'expires' => 'seconds until expiration',
};
The B routine will send a notice message at the requested or default
intervals IF the temporary directory exists and is writeable AND if the
B parameter exists and is positive AND the LICENSE file exists and is
readable. Substitutes can be made for the default values for ACTION, TMPDIR,
TO, and INTERVALS. Valid suffixes for INTERVALS are w=weeks,
d=days, h=hours, m=minutes, s=seconds (default if no suffix).
B returns an empty array on any error or if B does not exist. It
returns an
array of the INTERVALS values in in seconds, highest to lowest, if a check
is performed.
Note that the b hash can be combined with the hash used for the
B module and that they share common variables B and
B. All other B hash keys are lower while B
hash keys are upper case.
=back
=head1 COPYRIGHT
This Library is proprietary software and may be used only with the
permission of the author.
Copyright 2001 Michael Robinton, BizSystems
=head1 AUTHOR
Michael Robinton, BizSystems <[EMAIL PROTECTED]>
Subject: Re: hiding perl code
>> BZS::License performs a similar load operation to BZS::Loader. First, >> however it looks for a hash pointer in the caller program called >> $ptr2_License. >> The hash contains the path to the License file and an optional >>'private' key >> list of modules which will decrypt only with the 'private' key. B, > I thought that somebody has already said here that you cannot hide your > perl code. if you have an access to the perl interpreter you can dump > the source code after it was decrypted. > > wouldn't it be a good idea to add the truth to the POD so not to mislead > the crowd? I've read through the doc but didn't see a word mentioning > this "little" caveat. > > Shouldn't the module be renamed to BZS::Obscure::...? ;) You are correct. If you... use Hidden::Module then use Data::Dumper to reconstruct most of the raw code. This would be about as useful as decompiling 'B' code. If you had access to the intrepreter directly, you could probably even capture the decrypt stream before perl compiles it, but all of that would take a degree of sophistication that is better used to make real money instead of hacking stuff apart. How about BZS::VeryObscure :-) Michael
naming convention
I have a proposed perl / modperl module that will go to CPAN Graphics::ColorPicker : A perl module for WYSIWYG web applications that allow selection of HEX color numbers I think this is an appropriate name, but have not submitted in this category before. Please advise. See: http://www.bizsystems.net/downloads/graphics/demo.html Thanks, Michael
Re: naming convention
Stas wrote:
> Michael Robinton wrote:
> > I have a proposed perl / modperl module that will go to CPAN
> >
> > Graphics::ColorPicker : A perl module for WYSIWYG web
> > applications that allow selection of HEX color numbers
> >
> > I think this is an appropriate name, but have not submitted in
> > this category before. Please advise.
>
> I guess that this module is not extending mod_perl functionality,
> but simply optionally uses it and therefore you better off
> discussing this at [EMAIL PROTECTED], [EMAIL PROTECTED] without
> even mentioning mod_perl so not to confuse people. If my guess is
> wrong (you provided too little info) and it *requires* mod_perl it
> should probably be named something like Apache::ColorPicker, but
> again, you've provided too little info to tell.
Sorry bout that. It does optionally use mod_perl -- it tests
eval{require Apache} and proceeds, otherwise uses print statements to STDOUT
>
> > See: http://www.bizsystems.net/downloads/graphics/demo.html
>
> FWIW, it doesn't seem to do anything on mozilla-1.0/linux.
hmm works fine on my mozilla-1.0/linux build #2001061002
tested on above + windoze MSIE5.5, Netscape 4.7, Mozilla 1.0
If you can tell me more that would be nice.
Michael
odd authetication situation
I have a modperl handler that sets a cookie and does a redirect if the
cookie was not present. The redirected page eventually loads the same page
again. In addition, this page is called from a protected portion of the
site that requires Basic Auth.
When the redirect calls the mod_perl routine the second or "some"
subsequent times, $r->connection->user and $ENV{REMOTE_USER} are both
empty or non-existent yet the page does not appear to fail the
authentication request and executes and returns html.
The failure is repeatable though not consistently so, maybe 70% or more.
I'm scratching my head on this one. Any ideas??
Michael
Re: odd authetication situation
> Maybe you can try to add specifically:
> $r->connection->user('who_the_user_is') before the cookie access
> control returns OK in the module. Note that some of the cookie
> authentication modules are based on "access-only" control so
> $r->connection->user() can return a value in late phases only if one
> assigns it at the first place.
>
>
> Peter Bi
>
hmm... let me see if I understand what you are saying
It is necessary to specify $r->connection->user('current-known-user');
before I send OK so that on the next contact by the browser to the web
server $r->connection->user will have the correct value???
Is this because of keep-alives and using the same child process??
I would think that the client would send the token for each connection.
then what about the Cookie?? It appears that gets lost sometimes,
but not as often as the authentication token. This "fuzzy" behavior makes
redirects where cookies and tokens are expected very dicey...
Michael
> - Original Message -
> From: "Michael Robinton" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, August 28, 2002 1:05 PM
> Subject: odd authetication situation
>
>
> >
> > I have a modperl handler that sets a cookie and does a redirect if the
> > cookie was not present. The redirected page eventually loads the same
page
> > again. In addition, this page is called from a protected portion of
the
> > site that requires Basic Auth.
> >
> > When the redirect calls the mod_perl routine the second or "some"
> > subsequent times, $r->connection->user and $ENV{REMOTE_USER} are both
> > empty or non-existent yet the page does not appear to fail the
> > authentication request and executes and returns html.
> >
> > The failure is repeatable though not consistently so, maybe 70% or
more.
> >
> > I'm scratching my head on this one. Any ideas??
> >
> > Michael
Re: odd authetication situation
Peter wrote:
> Maybe you can try to add specifically:
> $r->connection->user('who_the_user_is') before the cookie access control
> returns OK in the module. Note that some of the cookie authentication
> modules are based on "access-only" control so $r->connection->user() can
> return a value in late phases only if one assigns it at the first place.
Point of clarification...
The authentication I'm writing about is BASIC AUTHENTICATION. apache takes
care of all of that. It appears as though the client is not sending it,
but I don't know why ... and if not, how it manages to pass the
authentication portion of the apache request loop.
the example I'm using does the following:
.htaccess
AuthType Basic
AuthName MagicName
AuthUserFile
/home/web/public_html/cgi/private/user.access
require valid-user
scriptA.plx ->redirect to scriptB.plx
scriptB.plx ->redirect to scriptA.plx CONDITIONALLY
if the CONDITION is met, the redirect is not done
i.e. cookie present + "user" present
what happens.. scriptA always has ENV{REMOTE_USER} and
$r->connection->user valid
scriptB rarely has them both valid
either script can set the same cookie if it is not present.
The cookie is always present for scriptA and usually but not always
present for scriptB
WHY???
Michael
problems installing libapreq-1.0
I have two identical hosts with the following mod_perl-1.26 apache apache_1.3.26 ben apachessl_1.48 openssll-0.9.6b on one, libapreq-1.0 installs just fine, on the other I get this error: In file included from /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include/include/httpd.h:79, from apache_request.h:5, from apache_request.c:59: /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include/include/buff.h:75: openssl/ssl.h: No such file or directory /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include/include/buff.h:78: #error "Don't use OpenSSL/SSLeay versions less than 0.9.2b, they have a serious security problem!" make[1]: *** [apache_request.o] Error 1 I can't figure out what the problem is. all the include files appear to be in the same places on both machines. I've rebuilt everything from scratch on the machine that fails :-( Any ideas?? Michael
Re: problems installing libapreq-1.0
never mind. It appears that the order in which things are done is important. I finally got it to work by reinstalling mod-perl for the umpteenth time and then again trying libapreq. Strange, the old version that was installed would no re-install until I did this. > I have two identical hosts with the following > > mod_perl-1.26 > apache apache_1.3.26 > ben apachessl_1.48 > openssll-0.9.6b > > on one, libapreq-1.0 installs just fine, on the other I get this > error: > > In file included from > /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include/include/http > d.h:79, > from apache_request.h:5, > from apache_request.c:59: > /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include/include/buff > .h:75: openssl/ssl.h: No such file or directory > /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include/include/buff > .h:78: > #error "Don't use OpenSSL/SSLeay versions less than 0.9.2b, they have a > serious security problem!" > make[1]: *** [apache_request.o] Error 1 > > I can't figure out what the problem is. all the include files appear > to be in the same places on both machines. I've rebuilt everything > from scratch on the machine that fails :-( > > Any ideas?? >
[ANNOUNCE] Apache::Test::CookieEmulator 0.04
Test::Apache::CookieEmulator - test tool for Cookies without httpd SYNOPSIS use Test::Apache::CookieEmulator; loads into Apache::Cookie namespace DESCRIPTION This module assists authors of Apache::* modules write test suites that would use Apache::Cookie without actually having to run and query a server to test the cookie methods. Loaded in the test script after the author's target module is loaded, Test::Apache::CookieEmulator Usage is the same as Apache::Cookie [EMAIL PROTECTED]
Re: mod perl and apache with ssl and openssl
On Tue, 24 Sep 2002, Allan P. Magmanlac wrote: > Hello, > >Can anyone advise me on how to build > apache server with ssl and openssl and > using mod perl. > > this is how I do it WITHOUT mod perl support > cd to modssl soure directory and then run the following command > ./configure \ > --with-apache=../apache_1.3.26 \ > --with-ssl=../openssl-0.9.6g \ > --prefix=/usr/local/root/httpd_1.3.26 \ > --with-crt=/usr/local/root/httpd/usr/local/www/conf/ssl.crt/server.crt \ > --with-key=/usr/local/root/httpd/usr/local/www/conf/ssl.key/server.key \ > --enable-module=proxy > > So how would I do it WITH mod perl support. (exact commands would > be appreciated) > > Thanks > Sure, here's my receipe. Works every time make sure open-ssl is built and installed then in apache-xxx/ untar and run the Fixpatch script for the appropriate version of appache-ssl rm apache/src/Configuration rm /usr/src/apache/src/Configuration.apaci edit /usr/src/apache/src/Configuration.tmpl and modules, i.e. activate mod_info.o, mod_rewrite.o, mod_so.o libproxy.a or whatever you plan to use then in mod perl source directory Run: perl Makefile.PL \ APACHE_SRC=/usr/src/apache/src \ DO_HTTPD=1 \ USE_APACI=1 \ PREP_HTTPD=1 \ EVERYTHING=1 \ in apache directory ./configure --with-layout=Apache \ --activate-module=src/modules/perl/libperl.a make make install Michael
Re: BUG:Apache::Cookie v1.0
>> * Michael McLagan <[EMAIL PROTECTED]> [2002-09-21 11:45]:
>> > There is a bug in Apache::Cookie. It doesn't handle a cookie with
>> > zero bytes in it!
>
>> This is because Apache::Cookie is implemented in C, and C uses NULL as
>> the end of string terminator.
>
>No quite accurate. C has no concept of a string. There are a number of
>library functions for string handling that use '\0' as the string
>terminator.
>
>If somebody rewrites Apache::Cookie to replace those functions, it will
>be able to handle such cookies.
>
>> This is probably something that needs to be done in Perl, since I doubt
>> there's a way to check for "embedded" NULLs in a string in C...
>
>/* We assume there will always a '\0' to be found. */
>char *
>find_nul(char *str)
>{
> while (*str) {
>str++;
> }
>
> return str;
>}
>
>What interests me much more is *why* a cookie should be able to contain
>*any* control character. If you want binary data in a cookie, you should
>encode it somehow.
>
>If the '\0' was a '\n', things would be much more interesting ...
>
>Lupe Christoph
hmmm... that's not really to point. Apache::Cookie is supposed to be
modeled on and replace CGI::Cookie. If you examine the code in CGI::Cookie
you see that when the "values" are extracted from the input hash, they are
escaped and then placed into the string format used for a cookie. There is
no limitation at all on what characters may be place in the "values" that
are submitted for XXX::Cookie->new($r,%hash). The present situation really
is a bug in implementation due to the nature of the C lib used to process
the "value" portion of the cookie string. I suspect the same is true about
the cookie "name" since it is processed in a similar way in CGI::Cookie.
We're not discussing what is allowable in the cookie itself, only the
compatibility of the Apache::Cookie vs CGI::Cookie implementation on which
it is patterned.
Michael
RE: Obfusacating the source
I am in the process of releasing these two modules which together provide perl source obfuscation. They are not uniquely Apache oriented though I've never used them for anything else, thus the designation in "Crypt". They have been used in production for over 2 years with little in the way of updates so they could be termed "stable". The name has been changed so that it fits into the CPAN hierarchy a little better. Crypt-CapnMidNite-1.00.tar.gz Crypt-License-2.00.tar.gz They may be found at: http://www.bizsystems.net/downloads/other README from Crypt::License Crypt::License This module set provides tools to effectively obfuscate perl source code and allow it to be decoded and executed based on host server, user, expiration date and other parameters. Further, decoding and execution can be set for a system wide key as well as a unique user key. In addition, there are a set of utilities that provide email notification of License expiration and indirect use of the encrypted modules by other standard modules that may reside on the system. i.e. sub-process calls by Apache-AuthCookie while not in user space. Tools and Makefile.PL additions are included to allow the creation of encrypted distribution "binaries" with commands make crypt make cryptdist Basic operation: Encryption uses a modified RC4 algorithim to convert the text perl file into a "binary" consisting of bits -- this is a non-text file. When perl attempts to load the module if first encounters "use Crypt::License;" at the beginning of the file which in turn decrypts the stream of "bits" and delivers it directly to the perl interpreter. Details in the POD's Michael
Re: Wanted: Modperl/Mason consultant:
where are you located?? Michael Robinton BizSystems 4600 El Camino Real - Suite 206B Los Altos, CA 94022 650 947-3351 [EMAIL PROTECTED] On Wed, 29 Nov 2000, Robert Monical wrote: > Hello. > > We have an Apache/Modperl/Mason/Oracle system and no programmers > experienced with the front end environment. (details available on request). > We are the Oracle programmer/DBA and Unix admin guys and fumble around in > the Perl as needed. Slowly coming up to speed on Perl. The Apche server is > Solaris Intel, the Oracle database (7.3.4) may be on Solaris or Windows NT. > > Our conclusion is that we need some adult supervision to get over some of > the rough spots as we develop proficiency in this tool set. We are further > handicapped by the reality that we each only have a few hours a week to > devote to the Web side of our application. I don't even have time to stay > current with the modperl mailing list. > > The types of problems you would help us with include. > -- On a new Apache server we were bringing up, our program would not write > a file. It took us two days to decide to look at the permissions on the > directory in question and give everybody write privilege. You would have > asked the question very early on. > -- Whilst working on a tedious but routine fix, in a moment of paranoia I > managed to convince myself that changes to the /usr/local/lib/perl tree > were not getting picked up by Apache unless I rebooted the host > machine. You would have calmed me down and suggested that I look deeper > into my database logic. > -- We have a nasty problem where sessions seem to refuse to die unless the > client browser exits. Still don't know where the problem is. > -- You will take us to the magical world of modperl debugging. It will be > like Disney World, only better. I'm sure of it. > > Requirements > -- Very proficient with Modperl and Mason. Experience with CGI a plus. > -- Focus. The abrupt departure of the Web team left a lot of "gotta do's" > in the application system. You'll need to overlook those and focus on the > problem at hand. > -- We would probably need less than 5 hours a week of your time. We have > flexible hours. > -- Sense of humor: we'll be pretty punchy by the time we need your services. > -- You will have to execute a non-disclosure/non-compete agreement drawn up > by our ubiquitous legal staff. > > If this is of interest to you, please forward a resume and rate to me at > [EMAIL PROTECTED] > > Thanks > > > robert monical > [EMAIL PROTECTED] > > "Letter writing is the only device for combining solitude and good company." > Lord Byron > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: > On Tue, 5 Dec 2000, Perrin Harkins wrote: > > > Brian, you've been taking a beating on this thread. I don't want to add > > to it, but you did raise a couple of interesting questions in this post. > > > The Big Thing for a serious project is providing a lot of services. If > you look at Weblogic server, you get all database, sessions, message > queuing, directory access, blah blah blah for free. Basically, the > programmer lives in a little cocoon where a truckload of services are > available and he only has to worry about his code. > > > Maybe they need some more work in certain areas if they don't function > > correctly "out of the box" for most people. > > There are a whole lot of people who just can't understand how to install > Apache::Session. They shouldn't need to. > Give a man a dump truck full of leggos, motors and gears and you can build some really interesting stuff, give man an end mill or a lathe and he can build a rocket ship to the moon. You figure out which one is Weblogic and which one is Apache-modperl :-) Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: difference in 123, 124 => 124_01
On Tue, 9 Jan 2001, Michael wrote: > > Hi there, > > > > On Tue, 9 Jan 2001, Michael wrote: > > > > > In upgrading to 1.24_01 I notice some warnings when the apache starts > > > that I don't remember being present. > > > > > Constant subroutine con redefined at /usr/lib/perl5/constant.pm line 91. > > > > I know it says perl5 in that path, but what version of Perl are you > > using? > > > > The reason I ask is that I found a few similar things (the result of > > some sloppy coding) when I upgraded from 5.005_03 to 5.6. > > Been using 5.6 all along. Don't know the effect on 5.0x loaded it on a production server that runs apache 1.3.14 modperl 1.24_01 and perl 5.0 patchlevel 5 subversion 3 so this is independent of perl Michael
Re: ssl advice? modssl vs. apache-ssl vs. ?
> I've just taken a quick look at the modssl site and the apache-ssl site. > Does anyone want to comment on the pros and cons of these 2 approaches? > > Can mod_perl co-exist with either or both of these? > > All responses welcome, including "don't do it, go back, save yourself!". > Don't know anything about modssl, I've been using apache-ssl + mod_perl for several years and am quite happy with the results. Currently up to: on 2 production and 1 development system apache_1.3.14 apache-ssl_1.42. mod_perl-1.24_01 openssl-0.9.6 Hope this helps Mod_perl development & telecommuting available Michael
