RE: PerlSetVar WhatEverSecure
At least part of the problem can also be solved by replacing PerlSetVar FooTicketLoginHandler /login with PerlSetVar FooTicketLoginHandler https://servername.domain.com/login so that the password the user types is always passed through a secure channel. I'm at a loss as to how to change the Apache::AuthTicket->login (or a similarly oriented subclass function) to: a) Remember if the original URL was secure or not b) Switching back to a nonsecure if the original URL was not secure Has anyone succeded in implementing a similar method? Rafael At 09:42 PM 6/13/2002 -0700, you wrote: >It's not the prettiest in the world, but try this (see attached file). >If anyone sees room for improvement, please, chime in. It's working >fine on the intranet site I run at work - and I haven't tried to make it >any better since it's working as is. You use this script instead of the >loginscreen method of AuthTicket. It uses the http-equiv refresh when >switch schemes since going from https to http causes most browsers to >popup a warning about getting redirected to an insecure site. > >Here are my relevant httpd.conf settings: > >PerlSetVar realmTicketLoginHandler /LOGIN >PerlSetVar realmTicketLogoutURI / >PerlSetVar realmLoginScript /login > >Alias /login /v01/data/web/auth/login > > Options ExecCGI > SetHandler perl-script > PerlHandler Apache::Registry > > > > > SSLRequireSSL > > SetHandler perl-script > PerlHandler Apache::AuthTicket->login > > >--Jim > > > -Original Message- > > From: Brian Reichert [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 13, 2002 1:13 PM > > To: Michael Schout > > Cc: Brian Reichert; [EMAIL PROTECTED] > > Subject: Re: PerlSetVar WhatEverSecure > > > > > > On Thu, Jun 13, 2002 at 10:40:18AM -0500, Michael Schout wrote: > > > Brian Reichert wrote: > > > > > > > > > > > > > > > PerlSetVar FormScriptSecure 1 > > > > AuthType Apache::AuthTicket > > > > ... > > > > > > > > > > > > But, in each case, my login program is server in the > > clear. What am > > > > I missing? > > > > > > THe authnameSecure setting only affects the cookie. If you want to > > > forbid access to the login form from non-ssl, there are > > verious ways to > > > do that. One way would be to add "SSLRequireSSL" that > > block (assuming > > > your using mod_ssl). > > > > Apache::AuthTicket says: > > > >Finally, by using the Secure mode of Apache::AuthCookie, the > >ticket is not passed over unencrypted connections. > > > > Passed in what direction? > > > > It would only go server->client if the client made a SSL request. > > > > With the 'FormScriptSecure' as I have it above, I _can_ log > > in over a non-encrypted channel, so clearly it's not > > enforcing the 'secure' criteria... > > > > (Still reading up on cookies...) > > > > I suppose my real question is: > > > > How can I intercept a unencrypted request for a protected > > document, but have the login form be submitted over an > > encrypted channel? > > > > (Thanks for the feedback, by the way...) > > > > > > > > Regards, > > > Mike > > > > > > > -- > > Brian 'you Bastard' Reichert <[EMAIL PROTECTED]> > > 37 Crystal Ave. #303 Daytime number: (603) 434-6842 > > Derry NH 03038-1713 USA Intel > > architecture: the left-hand path > >
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
Peter:
Squid complains about http://mod_perl.home.att.net which it says contains
an invalid character ("_"), so I can't access it.
Rafael Caceres
At 10:58 PM 5/3/2002 -0700, you wrote:
>Try my Apache::AccessCookie too. It provides the same ticketing interface
>for many different authenticating methods such as LDAP, IMAP, ftp, SMB, and
>(of course) DBI, plus a number of useful features. One can simply implement
>her own mechanism too. It can be downloaded at http://mod_perl.home.att.net.
>
>BTW, I tried to register the module in CPAN, but was kind of lost in the
>middle.
>
>
>Peter Bi
>
>- Original Message -
>From: "Jim Helm" <[EMAIL PROTECTED]>
>To: "'Fran Fabrizio'" <[EMAIL PROTECTED]>; "'F.Xavier Noria'"
><[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Sent: Friday, May 03, 2002 10:08 PM
>Subject: RE: problems setting up Apache::AuthCookieDBI (solved but no fully
>understood)
>
>
> > p.s. FWIW, I ended up using Apache::AuthTicket instead - has a feature I
> > wanted (timeout, not just expiry), which CookieDBI didn't have), and it
> > worked as documented with zero hassle...
> >
> > Jim
> >
> > > > -Original Message-
> > > > From: Fran Fabrizio [mailto:[EMAIL PROTECTED]]
> > > > Sent: Friday, May 03, 2002 6:38 AM
> > > > To: F.Xavier Noria
> > > > Cc: [EMAIL PROTECTED]
> > > > Subject: Re: problems setting up Apache::AuthCookieDBI
> > > > (solved but no fully understood)
> > > >
> > > >
> > > > >
> > > > >
> > > > >Does the server load the module that way?
> > > > >
> > > > >
> > > > It's beyond my expertise at this point but my experience
> > > > would indicate
> > > > that it does not work this way since I have PerlModule before the
> > > > PerlSetVar and it works fine.
> > > >
> > > > -Fran
> > > >
> > > >
> > > >
> > >
> >
> >
RE: mod_perl and perl RPMs and Oracle 9iAS
Rob Bloodgood wrote: > > Perrin Harkins wrote: > > >Rafael Caceres wrote: > > >>I'm facing a dilemma here. We are testing an Oracle 9iAS installation > > >>(Apache 1.3.19, mod_ssl 2.8.1, mod_perl 1.25 as DSO, Perl 5.005_03) on > > >>Red Hat Linux 7.2, which itself came with Perl 5.6.0, and from your > > >>comments, that's bad.. > > > > > >First of all, if it's working for you then don't worry about it. > > > > I have not started testing scripts that currently work on other boxes. I > > will install the required modules for the 5.005_03 perl used by Oracle > > 9iAS, and see what happens. > > This road forces me to have the two perl versions coexisting, or, > > to search > > for all the perl modules installed for the 5.6 version by the rpm's on > > initial installation, install them for the 5.005_03 version and > > then remove > > the 5.6 one permanently. > >OK, for starters: >Oracle includes their own version of perl/apache/mod_perl for the Web >interface they are bundling with the new 9i servers. It's their own >version, built by their own people, for their own usage, on their own >product, in its own path, under the Oracle product installation tree. > >Let 'em have it. It's only a few megs of disk space, and if your 9i >installation works, GREAT. Don't think of it as two versions co-existing. >Think of it as Oracle's insurance to themselves that their system will have >the exact parts it needs. Besides, except for a few configuration files, >shouldn't everything under $ORACLE_HOME be considered hands-off anyway? They dont seem to use it though, there is no visible perl script on the default httpd.conf other than the printenv script under /cgi-bin. But, they set PERL5LIB to point to their perl in apachectl and httpd.conf, which I guess can be fixed in the mentioned places. >Now, on to the real world: 10 minutes ago I just saw a post by a RedHat >employee stating that there are new RPM's for Perl 5.6.1 and the latest >mod_perl. Which means you can download and install them, and THEN begin >installing other modules, like Apache::DBI, Apache::Session, etc etc >according to your needs, into the "real" perl installation tree, where all >of YOUR system's perl modules live. I've always used DBI along with DBD::Oracle for Database access, and I intend to use them along Oracle 9iAS's other capabilities. So if I'm following you correctly, the steps involved are: -get the 5.6.1 RPM (which doesn't seem to be in Red Hat's site anyway) -get the Apache 1.3.19 sources (to be used in the next step), then 'discarded' without installing Apache per se. -get the mod_perl 1.24_01-2.src.rpm and compile it as a DSO -reinstall all previously installed packages, so other programs using them keep working -install the modules the mod_perl apps require -change the apachectl and httpd.conf files to reflect the proper perl 'home' -change httpd.conf to load the mod_perl.so file from it's new location Is this list OK? > > Yes, there are at least two modules: mod_plsql and mod_oprocmgr for which > > there is no source, so rebuilding seems to be out of the question > >Those modules are *only* for the Oracle administrative webservice, as I >mentioned above. If you want to use Oracle from Perl/mod_perl, do it like >everybody else: DBI and DBD::Oracle (for the record, I build them for 9i >several months ago with 0 headaches). This *does* include the ability to >execute PL/SQL. The mod_plsql is called heavily from the Oracle 9iAS Portal applets, so it needs to be kept in place. >L8r, >Rob > >#!/usr/bin/perl -w >use Disclaimer qw/:standard/; Regards, Rafael
Re: mod_perl and perl RPMs and Oracle 9iAS
Perrin Harkins wrote: >Rafael Caceres wrote: >>I'm facing a dilemma here. We are testing an Oracle 9iAS installation >>(Apache 1.3.19, mod_ssl 2.8.1, mod_perl 1.25 as DSO, Perl 5.005_03) on >>Red Hat Linux 7.2, which itself came with Perl 5.6.0, and from your >>comments, that's bad.. > >First of all, if it's working for you then don't worry about it. I have not started testing scripts that currently work on other boxes. I will install the required modules for the 5.005_03 perl used by Oracle 9iAS, and see what happens. This road forces me to have the two perl versions coexisting, or, to search for all the perl modules installed for the 5.6 version by the rpm's on initial installation, install them for the 5.005_03 version and then remove the 5.6 one permanently. >I'm curious about this though: >>On the other hand, Oracle's product does not include all the sources >>-which could have patches- making up the mod_perl enabled Apache > >Are you saying Oracle provided special modules for you to use? Are you >sure they aren't just the standard DBD::Oracle stuff? Oracle has never >been very interested in helping people solve DBD::Oracle problems before, >so I don't see why they would be secretly distributing special versions >with private patches. > >Unless there is some additional module provided by Oracle which has a C >component and no source, you should be fine to replace everything they >gave you if you want to. I wouldn't bother though, unless it's giving you >trouble. Yes, there are at least two modules: mod_plsql and mod_oprocmgr for which there is no source, so rebuilding seems to be out of the question Regards, Rafael Caceres
Re: mod_perl and perl RPMs and Oracle 9iAS
Dear Friends: I'm facing a dilemma here. We are testing an Oracle 9iAS installation (Apache 1.3.19, mod_ssl 2.8.1, mod_perl 1.25 as DSO, Perl 5.005_03) on Red Hat Linux 7.2, which itself came with Perl 5.6.0, and from your comments, that's bad.. On the other hand, Oracle's product does not include all the sources -which could have patches- making up the mod_perl enabled Apache, so I've got various basic choices: -Do double installations of perl modules, for the 5.6.0 and 5.005_03 Perls. -Install new modules only for 5.005.3, for use in web development. Do double installs only for those usefull for admin work. -Obtain and install all the modules installed for 5.6.0 and install them for the 'Oracle' 5.005_03 Perl, then replace the /usr/bin/perl with the 5.005_03 version. -Go the tough route and try to replace 5.005_03 in Oracle's product with 5.6.1, where the problem would be absence of source for any Oracle modules. This would also thow support from Oracle out the window when/if the box ends testing and goes into production. I'm eyeing the first option as the easiest, most stable. Now that means using 5.005_03 as DSO under Red Hat 7.2. Is that combination stable? Or is Perl 5.6.1 required to have stability for mod_perl as DSO on that platform? Your comments will be appreciated. Regards, Rafael Caceers At 09:38 PM 3/5/2002 -0500, you wrote: >Just thought I'd drop a note here and let people know we've errata'd >perl 5.6.1 and mod_perl 1.26 for Red Hat Linux 7.2. Most >significantly, mod_perl as a DSO under 7.2 work properly now. I've >spoken with a few of you off list about some of the issues, so >hopefully this release will solve the problems people have had in the >past with Red Hat and mod_perl DSOs. Not to mention banishing 5.6.0 >from 7.2 :) > >Chip > >-- >Chip Turner [EMAIL PROTECTED] > Red Hat Network
Re: modperl + FrontPage Server Extensions
Hi Jose: I don't use Apache-ASP, but we have Apache-Sandwich, SSL and FrontPage support in both a Linux and Alpha boxes, and have never seen a conflict. The only tough part was building it, as SSL and Frontpage try to patch the same source files. Hope this helps. Regards, Rafael Caceres At 09:21 PM 2/2/01 -0800, you wrote: >Hi Everybody > >I've a Linux box already running Apache/1.3.14 compiled with >mod_perl-1.24_01 running Apache-ASP-2.03. Well the question is if >Installing FrontPage Server Extensions will conflict?. > >Thanks in advance > >Regards > >-Jose > >[EMAIL PROTECTED] >www.datacourse.com
Re: fork inherits socket connection
At 01:46 PM 12/15/00 +0100, you wrote:
>On Fri, 15 Dec 2000, Kees Vonk 7249 24549 wrote:
>
> > Stas,
> >
> > I had the following in my code:
> >
> > my($nOrgPID) = fork;
> > exit if $nOrgPID;
> > die "Could not fork: $!" unless defined $nOrgPID;
> >
> > close STDIN;
> > close STDOUT;
> > close STDERR;
> > setsid() or die "Could not start new session: $!";
> >
> >
> > but that didn't work, however when I changed it to this:
> >
> > my($nOrgPID) = fork;
> > exit if $nOrgPID;
> > die "Could not fork: $!" unless defined $nOrgPID;
> >
> > require 'sys/syscall.ph';
> > for (my $i=0; $i<=255; $i++) {
> > syscall(&SYS_close, $i + 0); # must force numeric
> > }
> >
> > setsid() or die "Could not start new session: $!";
> >
> >
> > the socket got released and I could restart the server. I
> > know it is a little crud, but it seems to work.
>
>But you don't need to call setsid() when you fork. Why looking for
>complicated workaround when you can do it properly without any workaround.
>Have you ever seen an example of fork that uses setsid?
Yes, the following is taken straight out from the perlipc documentation:
-
Complete Dissociation of Child from Parent
In some cases (starting server processes, for instance) you'll want to
completely dissociate the child process from the
parent. This is often called daemonization. A well behaved daemon will also
chdir() to the root directory (so it
doesn't prevent unmounting the filesystem containing the directory from
which it was launched) and redirect its standard
file descriptors from and to /dev/null (so that random output doesn't wind
up on the user's terminal).
use POSIX 'setsid';
sub daemonize {
chdir '/' or die "Can't chdir to /: $!";
open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
open STDOUT, '>/dev/null'
or die "Can't write to /dev/null: $!";
defined(my $pid = fork) or die "Can't fork: $!";
exit if $pid;
setsid or die "Can't start a new session: $!";
open STDERR, '>&STDOUT' or die "Can't dup stdout: $!";
}
The fork() has to come before the setsid() to ensure that you aren't a
process group leader (the setsid() will fail if you are). If your system
doesn't have the setsid() function, open /dev/tty and use the TIOCNOTTY
ioctl() on it instead. See tty(4) for details.
-
Am I missing something?
Regards,
Rafael Caceres
Re: Apache + mod_perl + mod_ssl + mod_frontpage on Solaris 2.7
Hi Joerg, I have essentially the same mix functioning for several months on Digital Unix. The assembly order was: openssl mod_ssl mod_perl frontpage apply frontpage patch to apache apache I guess the order of the patches affects the result if a 'following' patch is made after a line that was already modified by a 'previous' patch (in the list of assembly, that is). Hope it helps. Rafael Caceres Information Systems Manager Corporacion Aceros Arequipa S.A. At 03:39 PM 12/1/00 +0100, you wrote: >Hi, >I'm trying to set up apache_1.3.14 with mod_frontpage-1.4.1-1.3.14, >mod_perl-1.24_01, mod_ssl-2.7.1-1.3.14 on a Sun Ultra 60 with Solaris 2.7, >using gcc 2.95.1, perl 5.6.0. >I assemble the pieces in this order: >- Frontpage Extensions >- mod_ssl >- mod_frontpage >- mod_perl >- Apache (with test certificate) >Compilation seems to run without problems, but I can't get it to run >afterwards: Sometimes the httpds are started, but crash with a >segmentation fault when they receive a request, sometimes they crash right >after they are started by apachectl, >without a trace in the logfiles (at Loglevel debug!). >Without mod_perl (only mod_ssl, mod_frontpage), everything was fine, >that's why I'm posting to this list. >Can anyone give me a hint what went wrong here? May it be a 32/ 64- Bit >problem, wrong libraries, or whatever? >Thanks for your support! > >Ciao, >Joerg > >-- > \ > _)\ >( \ > \ Joerg Reuter ... Rechnerbetreuung C-Lab Paderborn \ > \05251-606051, [EMAIL PROTECTED], www.stachelig.de\ >\ _) > \( > \ > >- >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: compiling modperl on alpha
Didier: I had no trouble compiling mod_perl (with SSL and Frontpage support) on 4.0B and 4.0D True64. The script used on the mod_perl side is: #!/bin/sh perl Makefile.PL \ APACHE_SRC=../apache_1.3.12/src \ SSL_BASE=../openssl-0.9.5a \ DO_HTTPD=1 \ USE_APACI=1 \ PREP_HTTPD=1 \ EVERYTHING=1 make make test ### and on the Apache (1.3.12) side: #!/bin/sh SSL_BASE=../openssl-0.9.5a \ ./configure --prefix=/usr/local/apache \ --enable-module=ssl \ --activate-module=src/modules/perl/libperl.a \ --activate-module=src/modules/extra/mod_frontpage.o make make certificate make install ### It's worked like a charm. I guess that perl 5.6 differences appart, it should work. Regards, Rafael Caceres At 07:24 PM 11/16/00 -0500, you wrote: >Hi all, > >maybe somebody can shed some light on this: > >I'm trying to compile mod_perl as a dso with apxs on Alpha/Tru64 unix and >there is an error from the linker: > >ld -shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib -o >libperl.so mod_perl.lo perlxsi.lo perl_config.lo perl_util.l >o perlio.lo mod_perl_opmask.lo Apache.lo Constants.lo ModuleConfig.lo >Log.lo URI.lo Util.lo Connection.lo Server.lo File.lo Table.l >o -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE -L/usr/local/lib >/usr/local/lib/perl5/5.6.0/alpha-dec_osf/auto/DynaLoade >r/DynaLoader.a -L/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE -lperl -lbind >-ldbm -ldb -lm -liconv >ld: >Invalid flag usage: Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE, >-Wx,-option must appear after -_SYSTYPE_SVR4 >ld: Usage: ld [options] file [...] >*** Exit 1 > >Where would this flag be defined? How can this be fixed? >I tried this on both a Tru64 5.1 and an older DU4.0b and the error is the >same. > >Can anyone give a clue? > >-- >Didier Godefroy >mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Authentication and Frontpage webs
Dear Friends: I'm running the following setup: Apache/1.3.12 , with FrontPage/4.0.4.3, mod_perl/1.23, mod_ssl/2.6.3 with OpenSSL/0.9.5a on an Alpha 4100 box for our Intranet. One of the frontpage webs departments about to 'go live' has indicated that there is a rather intrincate set of users/permissions that would have to be in effect for different documents/subdirs. In the Frontpage model, this would mean that a very large number of subwebs would have to be created. All the content is pure HTML. Is there any way that we could use an authentication modules under Apache:: , together with setting up a parallel authentication database? This would let us keep using a 1 Frontpage model, along with a very flexible permissions setup. I must say that in terms of Apache:: modules, my only experience is with Apache::Sandwich. Any ideas will be greatly appreciated. Thanks in advance, Rafael Caceres
Re: Simple question: httpd (apache) vs httpd (mod_perl)
Hello Keith, We have a couple Alphas 4100 in the office with perl and mod_perl enabled Apache. The main difference is that the mod_perl httpd has the full perl embedded. That is, there is no need to load perl in order to execute cgi scripts written in perl. That is a big improvement in performance. Even more can be achieved by having the scripts remain (precompiled) in memory as part of the httpd son processes. On top of that your cgi scripts can interact at any stage of the Apache request handling process, which results in an incredibly powerfull/versatile server. In terms of being able to use the new httpd instead of the previous (Apache only) httpd, the answer is an absolute yes! Regards, Rafael Caceres At 09:36 AM 8/22/00 +0100, you wrote: >Hello, > >My understanding of perl is minimal, my understanding of mod_perl >non-existant but I have a (simple) question that I can't find anywhere >in the FAQ. Hopefully someone can help? > >I've just installed the apache web server (1.3.12) on our Tru64 Unix box. >One of the applications we run (via the web) suggests that you install >mod_perl to increase efficiency...so I did (version 1.24). > >I noticed that during the install mod_perl creates a new version of httpd >(in the src/ directory). How is this version different to the version >that apache creates? Should I use the latter version in preference to >the apache version? > >Thanks in advance, > >Keith > > >~ Keith Bradnam - Developer, Arabidopsis Genome Resource (AGR) >~ Nottingham Arabidopsis Stock Centre - http://nasc.nott.ac.uk/ >~ University Park, University of Nottingham, NG7 2RD, UK >~ Tel: (0115) 951 3091
Apache 1.3.12+mod_perl + mod_ssl + FP extensions
Hi, I'm getting ready to setup the following combination of packages for our webserver: Perl 5.005 Apache 1.3.12 mod_perl 1.23 mod_ssl (for Apache 1.3.12) FP extensions (latest RTR software version, 'compatible' with Apache 1.3.12) Is there any particular 'appropriate' order to do patching/setup? Both mod_ssl and the FP extensions will try to patch Apache, and I'm not sure what's the proper order of installation. Any and all help is greatly appreciated. Regards, Rafael
Too many arguments for .. problem
Dear friends:
I've started with mod_perl just a month ago, and have been building a
mod_perl/DBI/Oracle applicacion which went fine, until the following
sequence ocurred:
1) I added the exit() routine from the guide, along with it's corresponding
BEGIN block
2) I started getting the following error on the logs:
[Fri Feb 4 14:57:02 2000] [error] Too many arguments for
Apache::ROOTintranet_2eaasa_2ecom_2epe::cgi_2dbtrack::bugtrack_2epl::do_old_
user at /usr/local/apache/share/cgi-btrack/bugtrack.pl line 142, near "$Pwd1)"
after every file edit and save cycle. And it always refers to the same
subroutine:
sub do_login_work {
#examine parameters passed and see if user can be passed on, or
should be
#held back at the login.
my $Name = $query->param('Name') || '';
my $Pwd1 = $query->param('Pwd1') || '';
if(length($Name) && length($Pwd1))
{
do_old_user($Name,$Pwd1);
} else {
do_more_data();
};
}
sub do_old_user() {
#verify that user is on file to let him proceed
my ($Name,$Pwd1)=@_;
my (@usrpwd);
The only way to fix it up until now has been to kill and re-start Apache.
It has not helped to try the following:
-comment out the BEGIN block dealing with exit() redefining, and the new
exit() from the Guide
-pre-declare :
sub do_old_user($$);
What am I doing wrong?
Regards,
Rafael Caceres
