Re: Confusion: Perl/mod_perl ????
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 31 May 2002 4:09 am, Stas Bekman wrote: > Actually the new site (which should be released realy soon now) has a > nice and easy intro to mod_perl (thanks to Bill Moseley and others who > helped): > > http://perl.apache.org/release/start/index.html > > So Jeff, you may want to start from this URL first. Also a really good read is Kip Hampton's mod_perl intro on take23: http://take23.org/whatis_mod_perl.xml - -- <:->get a SMart net -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE89xfoVBc71ct6OywRAsluAJ4p7MesbitTOdry4XZWWW/aVp6sGACg1uPe Kc8RbHplc8IJ9AhIoz6zP6w= =vzGh -END PGP SIGNATURE-
Re: RFC: Apache::DefaultCharset
At Fri, 31 May 2002 13:58:52 +0900, Tatsuhiko Miyagawa wrote: > =head1 SEE ALSO > > L > > mod_perl cookbook at http://www.modperlcookbook.com/ s/com/org/ -- Tatsuhiko Miyagawa <[EMAIL PROTECTED]>
RFC: Apache::DefaultCharset
Here's a tiny XS mod_perl module to configure AddDefaultCharset stuff
from mod_perl. This is my first XS hack, thanks to mod_perl
developer's cookbook.
Any suggestions are welcome.
http://bulknews.net/lib/archives/Apache-DefaultCharset-0.01.tar.gz
=head1 NAME
Apache::DefaultCharset - AddDefaultCharset configuration from mod_perl
=head1 SYNOPSIS
use Apache::DefaultCharset;
my $charset = Apache::DefaultCharset->new($r);
print "default_charset_name is ", $charset->name;
# or print "default charset is $charset"; will do (overload)
$charset->name('euc-jp'); # modify default_charset_name in run-time
=head1 DESCRIPTION
Apache::DefaultCharset is an XS wrapper for Apache Core's
C configuration.
=head1 EXAMPLES
=head2 Unicode Handling
Suppose you develop multi-language web application, and transparently
decode native encodings into Unicode string inside Perl (5.8 or over
would be better). First you should add
AddDefaultCharset euc-jp
in your C, then leave off C arguments
just to text/html. Then you can get the current configuration with
this module when you use C or C to decode the HTTP
request query into Unicode.
=head2 Modification of DefaultCharset
Suppose you want to add utf-8 for XML files, and Shift_JIS for HTML
files as HTTP charset attribute by default ("By default" means that if
you set C explicitly in content-generation phase, that
will be prior to the defalut). This module enables you to write
C to configure C in
run-time.
=head1 AUTHOR
Tatsuhiko Miyagawa E[EMAIL PROTECTED]
This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.
=head1 SEE ALSO
L
mod_perl cookbook at http://www.modperlcookbook.com/
=cut
Re: Best compile options for perl 5.8 for mod_perl 1.x and 2.x
> ./Configure -des -Dprefix=/home/stas/perl/ithread \ > -Dusethreads -Duseshrplib Also worth using large file support if you habitually munge > 2GB files. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: DBI error_log Logging
Quoting Jayce^ <[EMAIL PROTECTED]>:
> I've been researching the different modules for pushing your access log to a
>
> dbi storage vs. local file and have one question which I'm not sure any of
> them are able to do yet. Perhaps somebody has already thought of this and
> I'm just not seeing the answer (very likely).
>
> I need to log my error_log entries also, not just the access log.
For a non mod_perl way of dumping error_log into a DB just use the standard
Apache ErrorLog directive with a pipe:
ErrorLog "| /usr/local/apache/bin/error_logger.pl"
and in error_logger.pl just read from STDIN ( while (<>) {#do something} ) and
do what you please with the log entries.
Cees
>
> If there is one, especially if it's Apache::DBILogConfig (my favorite
> appearing so far) with that same customization, that would be excellent.
> Otherwise I'd like to know, because I'll probably have to make one *real*
> quick :) Also, if it has the ability to either trigger an event, or just
> log to file the inability to log via DBI, that would be nice.
>
> Jayce^
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE89q8CoTgdT9hhlCIRAjoEAJwKsO9LYavsWMQGwUsD11E1Gr9HiACgl1yR
> mvvJRsub4he4A4PaPoA8PEI=
> =E5ID
> -END PGP SIGNATURE-
>
>
--
Cees Hek
SiteSuite Corporation
Re: Confusion: Perl/mod_perl ????
Doug Silver wrote: > On Thu, 30 May 2002, Jeff McLean wrote: >> >>I have been programming in Perl for about 3 weeks now, and I just >>started doing some Perl CGI. I have Apache 2 installed on my linux >>system, but and my perl scripts work fine, but I don't knwo whether or >>not I'm using Perl (as in /usr/bin/perl) or mod_perl. I thought up >>untill recently that Apache has it's own version of Perl that it uses >>for CGI scripts (mod_perl) but I am now having doubts. Could someone >>please tell me exactly what the difference is between Perl and >>mod_perl, and how exactly mod_perl is used (.i.e. is it just for >>writing apache modules or is it just for CGI, or what) I'm >>big-time confuesd here. > > First go to the http://perl.apache.org/ site to get the full story. In > short, think of mod_perl as a module that you start up with Apache that > allows all of the perl scripts to run faster because the server doesn't > have to launch a subprocess because mod_perl is in a sense Apache's > version of perl. There are a lot of options/etc (this *is* perl we're > talking about), so keep that in mind as you read through the documentation > for what is applicable to your website. Actually the new site (which should be released realy soon now) has a nice and easy intro to mod_perl (thanks to Bill Moseley and others who helped): http://perl.apache.org/release/start/index.html So Jeff, you may want to start from this URL first. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Best compile options for perl 5.8 for mod_perl 1.x and 2.x
Chip Turner wrote: > Subject pretty much says it all. What are the requisite 5.8 compile > options, besudes ithreads, for proper functioning with either mod_perl > branch? Or ones that should be avoided? it may be different on your OS (read the INSTALL doc), but on linux 2.4 I compile with all the defaults (-des): ./Configure -des -Dprefix=/home/stas/perl/ithread \ -Dusethreads -Duseshrplib and I add: -Doptimize='-g' so I can debug problems (don't put it in for production use) -Duseshrplib builds a shared libperl Also you don't need -Dusethreads (which is a bit slower) if you don't plan on using perl threads and threaded Apache mpms (i.e. when you use prefork) __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Confusion: Perl/mod_perl ????
On Thu, 30 May 2002, Jeff McLean wrote: > Hi, > > I have been programming in Perl for about 3 weeks now, and I just > started doing some Perl CGI. I have Apache 2 installed on my linux > system, but and my perl scripts work fine, but I don't knwo whether or > not I'm using Perl (as in /usr/bin/perl) or mod_perl. I thought up > untill recently that Apache has it's own version of Perl that it uses > for CGI scripts (mod_perl) but I am now having doubts. Could someone > please tell me exactly what the difference is between Perl and > mod_perl, and how exactly mod_perl is used (.i.e. is it just for > writing apache modules or is it just for CGI, or what) I'm > big-time confuesd here. > > Thanks very much!!! > > Jeff. > Hi Jeff - First go to the http://perl.apache.org/ site to get the full story. In short, think of mod_perl as a module that you start up with Apache that allows all of the perl scripts to run faster because the server doesn't have to launch a subprocess because mod_perl is in a sense Apache's version of perl. There are a lot of options/etc (this *is* perl we're talking about), so keep that in mind as you read through the documentation for what is applicable to your website. If you're using mod_perl, you can check your log when you start up Apache for something like this: [Fri May 24 14:50:24 2002] [notice] Apache/1.3.22 (Unix) mod_perl -- ~~ Doug Silver Network Manager Urchin Software Corp.http://www.urchin.com ~~
Confusion: Perl/mod_perl ????
Hi, I have been programming in Perl for about 3 weeks now, and I just started doing some Perl CGI. I have Apache 2 installed on my linux system, but and my perl scripts work fine, but I don't knwo whether or not I'm using Perl (as in /usr/bin/perl) or mod_perl. I thought up untill recently that Apache has it's own version of Perl that it uses for CGI scripts (mod_perl) but I am now having doubts. Could someone please tell me exactly what the difference is between Perl and mod_perl, and how exactly mod_perl is used (.i.e. is it just for writing apache modules or is it just for CGI, or what) I'm big-time confuesd here. Thanks very much!!! Jeff.
IE login script woes
(I'm cc'ing the list in hopes that maybe this will help others when deailing with custom error documents that aren't working under IE - there have been a few people having problems with login pages and some of the Apache::Auth* modules, and maybe this will help. If it's old news to everyone, I apologize) Michael, I found something relating to IE (ain't MS grand!) and custom error pages not appearing under the right (wrong?) conditions... Basically, if "friendly http error messages" is turned on for IE 5.X+, your custom error page has to be over a certain size in order for IE to display the original and not it's own "friendly" version. The defaults for IE6.0 (don't have an older one to test with) are anywhere from 256 to 512 bytes, depending on the error code returned. I had a user who was having this problem on my site. Took me a while to figure it out too, since I always turn the pesky thing off on my systems. I eventually remembered there was a way to override them, and a quick search on MS Support site turned up the answer. Anyway, that alternate login script I sent to you needs a minor tweak - basically adding 512 spaces (as simple as ' 'x512) to both the refresh page and the actual login page, so as to prevent the "intelligent" code in IE from hiding the pages. It shouldn't be a problem for most login pages, but the refresh page I'm using to make http->https->http logins work didn't have anywhere near the 512 bytes needed. Hope that's useful to you somehow. Later, Jim
Re: DBI error_log Logging
Jayce^ wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I've been researching the different modules for pushing your access log to a > dbi storage vs. local file and have one question which I'm not sure any of > them are able to do yet. Perhaps somebody has already thought of this and > I'm just not seeing the answer (very likely). > > I need to log my error_log entries also, not just the access log. > this is _far_ trickier than you might suspect at first. for a detailed explanation, see Recipe 16.6 in the mod_perl Developer's Cookbook. the code we used to implement error log capturing is here: http://www.modperlcookbook.org/code/ch16/Cookbook-DivertErrorLog-0.01.tar.gz while sample (but working) code that uses the interface is here: http://www.modperlcookbook.org/code/ch16/Cookbook/ErrorsToIRC.pm paul, randy, and I were all able to get this module to work on three different platforms (including windows) but I'm still not sure how robust it is for production use. nevertheless, it should give you an idea as to why there aren't any modules on CPAN that do this :) --Geoff
DBI error_log Logging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been researching the different modules for pushing your access log to a dbi storage vs. local file and have one question which I'm not sure any of them are able to do yet. Perhaps somebody has already thought of this and I'm just not seeing the answer (very likely). I need to log my error_log entries also, not just the access log. If there is one, especially if it's Apache::DBILogConfig (my favorite appearing so far) with that same customization, that would be excellent. Otherwise I'd like to know, because I'll probably have to make one *real* quick :) Also, if it has the ability to either trigger an event, or just log to file the inability to log via DBI, that would be nice. Jayce^ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE89q8CoTgdT9hhlCIRAjoEAJwKsO9LYavsWMQGwUsD11E1Gr9HiACgl1yR mvvJRsub4he4A4PaPoA8PEI= =E5ID -END PGP SIGNATURE-
RE: separating C from V in MVC
Hi Ray --
> I'm looking for some pointers on MVC in this context. Specifically, M
> is easy ... use Perl objects, but how are others implementing the
> Controllers and Views in order to keep them separate?
[...snip...]
> What's the "right" way to do it? (None of this TMTOWTDO stuff now, I
> want the RIGHT way :-) ... and do I have the concepts right?
You want to do it the RIGHT way?
Before diving off into an abstract conversation about "design patters"...
It has been my experience that applying a design pattern such as MVC is not
a panacea. It's more important to devise a system which works than one
which is "academically correct". The most useful thing one can do with
their CS education is often to immediately forget everything they've learned
except the stuff which actually works at a practical level. My point: My
code isn't good because I apply some "pattern" to it. It may be good, and
it may resemble a pattern -- but those two things are largely coincidental.
:-)
That said, MVC has been a corner-stone of how my company develops web apps
in Perl. It has been our architecture for several years. The concepts are
pretty simple, and I think you already have most of the picture. In brief
--
Model: The business logic. Not related to the UI at all.
View: The user interface.
Controller: The glue between the View and the Model.
As you have already identified, the Model is simply a Perl module. The most
important thing to think of when writing a Model module is to make sure you
make it entirely separate from the user interface. It helps me to think of
the methods in the Model as potentially being called from a web application,
a cron script, or an email-based interface. The Model should not contain
anything specific about any of the interfaces through which it might be
accessed.
The View, in a web application, is really the HTML output. Generally, this
will be your templating system. Optimally, the View avoids *ALL*
application logic. At my company we use HTML::Template because it strongly
enforces the separation of View from Controller -- e.g., HTML from code. (I
realize that many of you prefer other HTML templating systems, but I still
contend that HTML::Template is the most effective system for truly
separating HTML from code. And it's damn fast, too.)
The Controller, as I've already described, connects the View to the Model.
Essentially, the Controller takes user input (e.g., HTTP request input, form
data, environment, etc.) and translates it into method calls on the
underlying Model. The Controller then takes output from the Model and
passes it to your View.
We implement our Controllers as CGI::Application modules. CGI::Application
completely encapsulates a single application into an object-oriented Perl
module which runs a particular application. CGI::Application runs perfectly
under mod_perl, and with a little savvy can be made to play nicely with just
about any architecture. Oh yes -- it also runs outside of mod_perl, outside
of Apache, and will even run on Windows should that be one of your
requirements.
As your message indicated, separating the View from Controller is a problem.
In fact, it is actually a problem related specifically to "Server Page"
architectures such as Mason, EmbPerl, Cold Fusion, ASP or JSP. All these
systems are server-page systems (SPS), and all suffer from problems in
separating the View from the Controller.
Ironically, SPS were invented in response to "CGI scripts". CGI scripts
were largely criticized because they, too, combined the View and the
Controller. When you look at it like that it's hard to argue that SPS have
really improved the situation at all.
If you have to work with an SPS such as Mason but you still want to separate
your View from your Controller, you have to work twice as hard. SPSs
encourage the View and Controller to be in the same document. In fact, it's
virtually impossible to entirely separate them. One of the things which
irks me most about SPS code is when I see the re-invention of "old-school,
CGI-style" coding in the middle of a server-page. How do you know when your
SPS is working against you? When you see this in the middle of your
[Mason|EmbPerl|JSP|ASP|Cold Fusion] page:
if (defined($some_form_param)) {
# 50 lines of spaghetti code to run a search
} else {
# 30 lines of spaghetti code to display a form
}
That, my friends, is what happens when an SPS is used in lieu of a real
architecture. Separating your Controller and View is a great cure for this
ailment.
Warmest regards,
-Jesse-
Jesse Erlbaum, CTO
Vanguard Media
http://www.vm.com
212.242.5317 x115
[EMAIL PROTECTED]
Best compile options for perl 5.8 for mod_perl 1.x and 2.x
Subject pretty much says it all. What are the requisite 5.8 compile options, besudes ithreads, for proper functioning with either mod_perl branch? Or ones that should be avoided? Chip -- Chip Turner [EMAIL PROTECTED] Red Hat, Inc.
Re: AuthzHandler, index.html not being accessed
I should also mention this: Apache/1.3.23 (Unix) mod_perl/1.26 - Original Message - From: "Ken Miller" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 30, 2002 11:12 AM Subject: AuthzHandler, index.html not being accessed > I've got an interesting problem, related to my development of some > Authen/Authz handlers. > > I have a directory on which I've installed an Access, Authen, and Authz > handler: > > - the Access handler makes sure a cookie exists, and redirects the user to a > login page if it doens't. If the cookie does exist, populate > $r->connection->user. This works. > > - Authen handler currently returns OK - it will be used to validate the user > as stored in the cookie > > If I 'require valid-user' in the directory, my authz handler doesn't get > invoked, which I expect. However, If I request the directory (ie. /test/) I > get a directory listing instead of index.html. If I take out the require, > thereby bypassing authen/authz, I get index.html. If I also put in custom > 'requires', my authz handler is invoked, and the same thing happens. > > So, it seems that when OK is returned from an authz handler, the > DirectoryIndex is not being read. > > I've been unsucessful in trying to find a solution. > > Ideas? > > -klm. > > BTW, I understand that what I'm doing does appear to be similar to > Apache::AuthCookie, but I have a few different requirements that I need to > incorporate > > >
Re: AuthzHandler, index.html not being accessed
A note: since cookie is involved, why not to implement all the access/authentication/authurization functions at the access control phase using cookie ? Peter > I've got an interesting problem, related to my development of some > Authen/Authz handlers. > > I have a directory on which I've installed an Access, Authen, and Authz > handler: > > - the Access handler makes sure a cookie exists, and redirects the user to a > login page if it doens't. If the cookie does exist, populate > $r->connection->user. This works. > > - Authen handler currently returns OK - it will be used to validate the user > as stored in the cookie > > If I 'require valid-user' in the directory, my authz handler doesn't get > invoked, which I expect. However, If I request the directory (ie. /test/) I > get a directory listing instead of index.html. If I take out the require, > thereby bypassing authen/authz, I get index.html. If I also put in custom > 'requires', my authz handler is invoked, and the same thing happens. > > So, it seems that when OK is returned from an authz handler, the > DirectoryIndex is not being read. > > I've been unsucessful in trying to find a solution. > > Ideas? > > -klm. > > BTW, I understand that what I'm doing does appear to be similar to > Apache::AuthCookie, but I have a few different requirements that I need to > incorporate > > >
Re: Persistant references [was] Persistent Net::Telnet Objects
I have thought about this, and it's something I'm willing to do if I have
to. I would much rather be able to store an actual code ref and avoid the
overhead of many string-form eval's. Is there no way to do this?
-- Ryan
- Original Message -
From: "Garth Winter Webb" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 29, 2002 11:16 PM
Subject: Re: Persistant references [was] Persistent Net::Telnet Objects
> You could just pass around a string rather than a subref:
>
> my $handler = 'sub { my $arg = @_; do_something(); }';
>
> vs
>
> my $handler = sub { my $arg = @_; do_something(); };
>
> When you want to call it later on you do it like:
>
> eval($handler)->('foo');
>
> vs
>
> $handler->('foo');
>
> Garth
>
> On Wed, 2002-05-29 at 22:17, Ryan Parr wrote:
> > I never do give enough info on the first e-mail. Thank you for bearing
with
> > me...
> >
> > What I mean is, if a request comes in for a certain form I would like to
be
> > able to do something like this:
> >
> > my $form = &load_form($r);
> > $c{$session_id}->{handler} = $form->{handler}; # <-- this being a code
> > ref...
> > $r->send_http_header;
> > print $form;
> >
> > Then when the user completes the form and resubmits:
> >
> > my $handler = $c{$session_id}->{handler};
> > $r->send_http_header;
> > print $handler->($r);
> >
> > This is definately simplified, but the idea is there. I would like to be
> > able to store anything that can be referenced and have it be available
to
> > all processes. I would like to be able to dynamically create anonymous
> > subroutine handlers based on input and have them be active until the
form is
> > submitted, at which time they are used to process the form then
discarded.
> >
> > Is this something that can be accomplished? The global hash using Perl
> > aliasing
> >
(http://thingy.kcilink.com/modperlguide/perl/Using_the_Perl_Aliasing_Feature
> > _.html) works beautifully, until of course the form is submitted to
another
> > httpd process, and I'm hoping to not have to limit myself to just one
child.
> >
> > Obviously this can't be serialized, but there has to be *some* way to do
> > this...
> >
> > -- Ryan
> >
> >
> > - Original Message -
> > From: "Ryan Parr" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, May 29, 2002 9:16 PM
> > Subject: Persistant references [was] Persistent Net::Telnet Objects
> >
> >
> > > Along these same lines I'm seeking a way to store a code reference
into a
> > > global hash that is shared among all processes. For example:
> > >
> > > my $session_id = get_session_from_cookie($r);
> > > my $handler = $c{$session_id}->{handler};
> > >
> > > $r->send_http_header;
> > > print $handler->($r);
> > > return OK;
> > >
> > > Has anyone performed this kind of magical tidbit before? Is there some
> > main
> > > process repository that I can access?
> > >
> > > -- Ryan
> > >
> > >
> > > - Original Message -
> > > From: "Rob Mueller (fastmail)" <[EMAIL PROTECTED]>
> > > To: "French, Shawn" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > > Sent: Wednesday, May 29, 2002 5:35 PM
> > > Subject: Re: Persistent Net::Telnet Objects
> > >
> > >
> > > > Our project needed persistent socket connections open as well. There
is
> > > > supposed to be a standard mechanism to pass file descriptors between
> > unix
> > > > processes, though it's bugginess level depends on your OS. There is
a
> > perl
> > > > module for this called Socket::PassAccessRights. So what you can do
is
> > > > create a daemon process that just hangs round holding socket
connections
> > > > open, like a socket cache basically, and passing them back and forth
> > > between
> > > > Apache processes based on some session ID or user ID or the like.
> > > >
> > > > Your daemon ends up looking something like this (with lots more
error
> > > > checking of course)
> > > >
> > > > my %sockmap;
> > > > while (1) {
> > > > my $clientsock = $listen->accept();
> > > > chomp(my $sessionid = <$clientsock>);
> > > > my $cachesock = ($sockmap{$sessionid} ||= opennewsock());
> > > > Socket::PassAccessRights::sendfd(fileno($clientsock),
> > > fileno($cachesock));
> > > > $clientsock->close();
> > > > }
> > > >
> > > > And in your mod_perl code you do something like:
> > > >
> > > > my $serversock = IO::Socket::INET->new(Server => 'localhost', Port
=>
> > > > SOCKETPOOLPORT);
> > > > print $serversock $sessionid, "\n";
> > > > my $Fd = Socket::PassAccessRights::recvfd(fileno($serversock));
> > > > open(my $realsocket, "<&=$Fd");
> > > > fcntl($realsocket, F_SETFD, 0);
> > > > my $ofh = select($realsocket); $| = 1; select ($ofh);
> > > >
> > > > If you do some experimenting, you'll get something that works,
you'll
> > also
> > > > find lots of cases that don't.
> > > >
> > > > Rob
> > > >
> > > > - Original Message -
> > > > From: "French, Shawn" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Thursday, May 30, 2002 3:53 AM
> > > > Su
AuthzHandler, index.html not being accessed
I've got an interesting problem, related to my development of some Authen/Authz handlers. I have a directory on which I've installed an Access, Authen, and Authz handler: - the Access handler makes sure a cookie exists, and redirects the user to a login page if it doens't. If the cookie does exist, populate $r->connection->user. This works. - Authen handler currently returns OK - it will be used to validate the user as stored in the cookie If I 'require valid-user' in the directory, my authz handler doesn't get invoked, which I expect. However, If I request the directory (ie. /test/) I get a directory listing instead of index.html. If I take out the require, thereby bypassing authen/authz, I get index.html. If I also put in custom 'requires', my authz handler is invoked, and the same thing happens. So, it seems that when OK is returned from an authz handler, the DirectoryIndex is not being read. I've been unsucessful in trying to find a solution. Ideas? -klm. BTW, I understand that what I'm doing does appear to be similar to Apache::AuthCookie, but I have a few different requirements that I need to incorporate
Re: Persistent Net::Telnet Objects
"French, Shawn" wrote: > > I just found this: http://www.devshed.com/Talk/Books/ProApache/page2.html > > "On Windows platforms, Apache does not fork; consequently, the directives > for controlling the number of processes or their lifetime have no effect. > Instead, Apache runs as a multi-threaded process" > > Recall that I am using: Apache/1.3.20 (Win32) mod_perl/1.25_01-dev > mod_ssl/2.8.4 OpenSSL/0.9.6a on Windows 2000 with PHP 4.21 > > Would this be why my scripts are working? Does this mean that as long as I > stay with windows I will be alright? > I'm guessing that it has more to do with having "KeepAlive On" (in httpd.conf) and a client that supports HTTP 1.1. For a test, try "KeepAlive Off", or use a client that doesn't support HTTP 1.1 (Netscape 4.x, for example).
RE: Persistent Net::Telnet Objects
It it possible that KeepAlives are what's making this work? If the user is active enough, in theory, they would always be connected to the same httpd process... Jim -- James Helm - Solaris System Administrator [EMAIL PROTECTED] WNS National Operations - Core Services [EMAIL PROTECTED] AT&T Wireless Services Inc. (425) 288-4395 (Desk) 3555 Monte Villa Pkwy, Bothell, WA 98021 (206) 618-0438 (Cell) > -Original Message- > From: French, Shawn [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 29, 2002 1:50 PM > To: 'Perrin Harkins' > Cc: [EMAIL PROTECTED] > Subject: RE: Persistent Net::Telnet Objects > > > Perrin wrote: > > I can't see how it could be working now > > That makes two of us! > > > You're probably opening new telnet connections from each apache > > process. > > I know that I am not since they are continuing to log to the > same dump file, and my code (as stated in previous message) > simply goes to the hash and takes the object. > > > That won't work, since you can't control which process will handle > > requests from the client. > > OK, is there a way to make sure that there is just one > process? This site is not for milions of users, only 10 - 20. > > I'm sure that others have had to keep persistent sockets > and/or filehandles on their server, and I really don't see > how my problem is any different... > > Please, can anybody help me? > Shawn >
Getting AuthCookie to work on W2K
Hello All,
I am trying to setup the Apache-AuthCookie module and have run into a
problem. Every time
I try to login it just returns my back to the login screen. I can't get past
the login screen!!
(I have tried with Netscape and IE). Next I wrote a perl script to check
things out. (same thing!!)
according to the apache log file it seems that the server is not receiving
the cookie but according
to the LWP debug information it is sending it out!!
Does anyone have any idea what is wrong? What have I missed?
Thanks
Ron
login.pl script=
#!/usr/bin/perl -w
use HTTP::Request::Common;
use HTML::Form;
use LWP::UserAgent;
use LWP::Debug qw(+);
BEGIN {
local $^W = 0;
*LWP::UserAgent::redirect_ok = sub {1}
}
use HTTP::Cookies;
use strict;
my $ua= LWP::UserAgent->new;
$ua->cookie_jar(
HTTP::Cookies->new(
autosave => 1 )
);
my $request = $ua->request( POST 'http://cypci748/uganswer/index.html' );
#print $request->as_string;
my $form = HTML::Form->parse( $request->content, $request->base());
$form->value( 'credential_0', "programmer" );
$form->value( 'credential_1', "Hero" );
my $response = $ua->request( $form->click('submit') );
print $response->as_string;
=output from login.pl (lwp debug
information)=
F:\scripts>login.pl
LWP::UserAgent::new: ()
LWP::UserAgent::request: ()
HTTP::Cookies::add_cookie_header: Checking cypci748.local for cookies
HTTP::Cookies::add_cookie_header: Checking .local for cookies
LWP::UserAgent::send_request: POST http://cypci748/uganswer/index.html
LWP::UserAgent::_need_proxy: Not proxied
LWP::Protocol::http::request: ()
LWP::Protocol::collect: read 763 bytes
LWP::Protocol::collect: read 692 bytes
LWP::UserAgent::request: Simple response: OK
LWP::UserAgent::request: ()
HTTP::Cookies::add_cookie_header: Checking cypci748.local for cookies
HTTP::Cookies::add_cookie_header: Checking .local for cookies
LWP::UserAgent::send_request: POST http://cypci748/LOGIN
LWP::UserAgent::_need_proxy: Not proxied
LWP::Protocol::http::request: ()
LWP::Protocol::collect: read 265 bytes
HTTP::Cookies::extract_cookies: Set cookie Apache::UGA::AuthCookieHandler_Wh
er => programmer:Hero
LWP::UserAgent::request: Simple response: Found
LWP::UserAgent::request: ()
HTTP::Cookies::add_cookie_header: Checking cypci748.local for cookies
HTTP::Cookies::add_cookie_header: Checking .local for cookies
LWP::UserAgent::send_request: POST http://cypci748/uganswer/index.html
LWP::UserAgent::_need_proxy: Not proxied
LWP::Protocol::http::request: ()
LWP::Protocol::collect: read 763 bytes
LWP::Protocol::collect: read 692 bytes
LWP::UserAgent::request: Simple response: OK
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: close
Date: Thu, 30 May 2002 13:51:59 GMT
Pragma: no-cache
Server: Apache/1.3.19 (Win32) AxKit/1.51 mod_perl/1.26
Content-Length: 1455
Content-Type: text/html
Expires: Thu, 30 May 2002 13:51:59 GMT
Client-Date: Thu, 30 May 2002 13:51:59 GMT
Client-Response-Num: 1
[ the login form was here]
Apache error_log
file===
[Thu May 30 06:51:59 2002] [error] auth_type Apache::UGA::AuthCookieHandler
[Thu May 30 06:51:59 2002] [error] auth_name WhatEver
[Thu May 30 06:51:59 2002] [error] ses_key_cookie
[Thu May 30 06:51:59 2002] [error] uri /uganswer/index.html
[Thu May 30 06:51:59 2002] [error] Converting POST -> GET
[Thu May 30 06:51:59 2002] [error] credential_0 programmer
[Thu May 30 06:51:59 2002] [error] credential_1 Hero
[Thu May 30 06:51:59 2002] [error] ses_key programmer:Hero
[Thu May 30 06:51:59 2002] [error] auth_type Apache::UGA::AuthCookieHandler
[Thu May 30 06:51:59 2002] [error] auth_name WhatEver
[Thu May 30 06:51:59 2002] [error] ses_key_cookie
[Thu May 30 06:51:59 2002] [error] uri /uganswer/index.html
Apache http.conf file for
AuthCookie
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlModule Apache::AuthCookie
PerlModule Apache::UGA::AuthCookieHandler
PerlSetVar WhatEverPath f:/Apache/cgi-bin/
PerlSetVar WhatEverLoginScript /perl/login.pl
PerlSetVar AuthCookieDebug 3
AuthType Apache::UGA::AuthCookieHandler
AuthName WhatEver
PerlAuthenHandler Apache::UGA::AuthCookieHandler->authenticate
PerlAuthzHandler Apache::UGA::AuthCookieHandler->authorize
Require user programmer
AuthType Apache::UGA::AuthCookieHandler
AuthName WhatEver
SetHandler perl-script
PerlHandler Apache::UGA::AuthCookieHandler->login
RE: Persistent Net::Telnet Objects
I just found this: http://www.devshed.com/Talk/Books/ProApache/page2.html "On Windows platforms, Apache does not fork; consequently, the directives for controlling the number of processes or their lifetime have no effect. Instead, Apache runs as a multi-threaded process" Recall that I am using: Apache/1.3.20 (Win32) mod_perl/1.25_01-dev mod_ssl/2.8.4 OpenSSL/0.9.6a on Windows 2000 with PHP 4.21 Would this be why my scripts are working? Does this mean that as long as I stay with windows I will be alright? I realize (as Medi Montaseri pointed out) that my scripts might not be too secure (ie. hijacking a telnet session) however I am only concerned about getting this working, and making sure it will remain working, as it will be run behind a firewall in a corporate intranet. For now I will continue coding with my current architecture hoping that the above mentioned information is correct. Thanks for all the help! Shawn
Re: Reloading Modules
Stas Bekman wrote:
> Ted Prah wrote:
> > Thanks for the input Stas. I found your debugging methodology
> > to be very informative and especially useful in a mod_perl environment.
> >
> > I tried your suggestion of commenting out
> > require $key;
> > in Reload.pm, but it did not work for me. I'd be happy to try
> > any other suggestions you might have.
>
> But did you debug whether the module was reloaded from test.pl with the
> modified Reload.pm? If so was the import() called? If not, try to have
> it as a separate call:
>
> require My::Test;
> My::Test->import(':subs');
>
This worked! The modification to Reload.pm was not necessary for
this to work.
>
> > Your code to work around Exporter worked fine. However,
> > I think I'll stick with using Exporter so that I can make use
> > of the export tags.
>
> But it doesn't seem to work? You can easily extend the import() function
> I've suggested to suppport tags.
>
Right, it doesn't work unless I restart the server. Restarting the
server has been made easier due to your advice on cloning the
apachectl script and setting the suid bit.
Thanks again for all your help,
Ted
>
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
RE: Invoke PHP scripts?
On Wed, 29 May 2002, Jim Helm wrote: > How about using php in cgi mode and using `php scriptname` from within > perl to capture the output? Not the best performance-wise, but it would > do what you want, I think. > will the cgi environment be preserved? --- Gabriel Millerd | When I grow up I want a job where I run around in Plumber |circles chasing my tail like an idiot ten hours a day. |-- Monster.com
