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: 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: 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: 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: 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
[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]
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??
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
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
hiding perl code
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
LBZS::License::Notice(3), LBZS::License::Util(3)
=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 Bcheck routine will send a notice message at the requested or default
intervals IF the temporary directory exists and is writeable AND if the
Bexpires 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).
Bcheck returns an empty array on any error or if Bexpires 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 bNotice.pm hash can be combined with the hash used for the
BLicense.pm module and that they share common variables Bpath and
Bexpires. All other BLicense.pm hash keys are lower while BNotice.pm
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]
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. snip 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
[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: 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
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
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 EOF; #Content-type: text/html # #htmlbody bgcolor=#ff #$port, $name #/body #/html #EOF use Apache; my $r = Apache-request; my $html = q|html body bgcolor=#ff $port, $name /body /html |; $_ = 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: 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
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: 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: 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
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. snip 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. snip 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: 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: 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 Directory 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: 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 !--#include file="index.inc"-- 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: 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: 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: 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: 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: 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
