Re: Mason vs embperl
Lihn, Horng-Twu [EMAIL PROTECTED] writes: I have a library of perl routine that I call in cgi-bin environment where I usually require. I could not find any way to require it and use it in Embperl. I can not find any doc describing how this is done. (I can require it in the Mason handler.pl) In embperl, you can require or use within [! !] and [- -] tags.
Apache::AuthCookieLDAP secret key [was Problem with Apache-request]
Randy Rasmussen [EMAIL PROTECTED] writes:
This worked to some degree. Here is the page I get now.
Now I get this error:
[Fri Oct 12 14:17:50 2001] [error] access to /test2/ failed for
xxx.xxx.xxx.xxx, reason: Apache::AuthCookieLDAP: didn't the secret key from
for auth realm SA
How does the secret key work and how should I create it?
I'm not familiar with the Apache::AuthCookieLDAP module, so you'd have
to refer to its documentation for details. It may be a word, phrase or
password depending on the module. I'd start with the
SALDAP_SecretKeyFile that you've specified in your httpd.conf:
PerlSetVar SALDAP_SecretKeyFile .../apache/foobar.com.key
See if it exists and verify that the UID under which the web server is
running has permission to access that file.
Apologize for my ignorance.
Randy
Chris Strom wrote:
Are you running login.pl under Apache::Registry? If not, something like
the following should work:
Alias /perl/ /home/httpd/perl/
PerlModule Apache::Registry
Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
/Location
Then put your login.pl script into /home/httpd/perl and change
PerlSetVar SALoginScript /cgi-bin/login.pl
to
PerlSetVar SALoginScript /perl/login.pl
Randy Rasmussen [EMAIL PROTECTED] writes:
I am having a problem with a module that needs Apache-request.
The module is AuthCookieLDAP. I have a .htaccess (/test2/.htaccess) file
that looks like:
AuthType Apache::AuthCookieLDAP
AuthName SA
PerlAuthenHandler Apache::AuthCookieLDAP-authenticate
PerlAuthzHandler Apache::AuthCookieLDAP-authorize
require valid-user
That in turn reads my httpd.conf file which has the following:
Files LOGIN
AuthType Apache::AuthCookieLDAP
AuthName SA
SetHandler perl-script
PerlHandler Apache::AuthCookieLDAP-login
/Files
PerlModule Apache::AuthCookieLDAP
PerlSetVar SAPath /
PerlSetVar SALoginScript /cgi-bin/login.pl
PerlSetVar SALDAP_DN o=isp
PerlSetVar SADBI_DSN isp
PerlSetVar SALDAP_SecretKeyFile .../apache/foobar.com.key
PerlSetVar SALDAP_User tesuser
PerlSetVar SALDAP_host host.foobar.com
#PerlSetVar SALDAP_host ldap.foobar.com
PerlSetVar SALDAP_EncryptionType none
PerlSetVar SALDAP_SessionLifetime 00-24-00-00
Then it runs the login.pl script which looks like:
#!/usr/bin/perl
#
# $Id: login.pl,v 1.1 2000/07/11 17:03:05 jacob Exp $
use strict;
use 5.004;
use Text::TagTemplate;
use Apache;
my $t = new Text::TagTemplate;
my $r = Apache-request();
my $destination;
my $authcookiereason;
if ( $r-prev() ) { # we are called as a subrequest.
$destination = $r-prev()-args()
? $r-prev()-uri() . '?' . $r-prev-args()
: $r-prev()-uri();
$authcookiereason = $r-prev()-subprocess_env(
'AuthCookieReason' );
} else {
$destination = $r-args( 'destination' );
$authcookiereason = $r-args( 'AuthCookieReason' );
}
$t-add_tag( DESTINATION = $destination );
unless ( $authcookiereason eq 'bad_cookie' ) {
$t-template_file( ../html/login.html );
} else {
$t-template_file( ../html/login-failed.html );
}
$r-send_http_header;
print $t-parse_file unless $r-header_only;
When I go to /test2/index.html I get this error:
Can't locate object method request via package Apache at
.../cgi-bin/login.pl line 16.
[Wed Oct 10 10:43:26 2001] [error] [client 172.28.22.253] Premature end
of script headers: .../cgi-bin/login.pl
Here is the software and versions I have installed:
apache 1.3.20, Apache-AuthCookie-3.00, Apache-AuthCookieLDAP-0.02,
mod_perl-1.26, perl5.005_02
Please help. I have looke all over deja.com, and all of the perl and
mod_perl sites I can think of to no avail.
Re: Problem with Apache-request
Are you running login.pl under Apache::Registry? If not, something like
the following should work:
Alias /perl/ /home/httpd/perl/
PerlModule Apache::Registry
Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
/Location
Then put your login.pl script into /home/httpd/perl and change
PerlSetVar SALoginScript /cgi-bin/login.pl
to
PerlSetVar SALoginScript /perl/login.pl
Randy Rasmussen [EMAIL PROTECTED] writes:
I am having a problem with a module that needs Apache-request.
The module is AuthCookieLDAP. I have a .htaccess (/test2/.htaccess) file
that looks like:
AuthType Apache::AuthCookieLDAP
AuthName SA
PerlAuthenHandler Apache::AuthCookieLDAP-authenticate
PerlAuthzHandler Apache::AuthCookieLDAP-authorize
require valid-user
That in turn reads my httpd.conf file which has the following:
Files LOGIN
AuthType Apache::AuthCookieLDAP
AuthName SA
SetHandler perl-script
PerlHandler Apache::AuthCookieLDAP-login
/Files
PerlModule Apache::AuthCookieLDAP
PerlSetVar SAPath /
PerlSetVar SALoginScript /cgi-bin/login.pl
PerlSetVar SALDAP_DN o=isp
PerlSetVar SADBI_DSN isp
PerlSetVar SALDAP_SecretKeyFile .../apache/foobar.com.key
PerlSetVar SALDAP_User tesuser
PerlSetVar SALDAP_host host.foobar.com
#PerlSetVar SALDAP_host ldap.foobar.com
PerlSetVar SALDAP_EncryptionType none
PerlSetVar SALDAP_SessionLifetime 00-24-00-00
Then it runs the login.pl script which looks like:
#!/usr/bin/perl
#
# $Id: login.pl,v 1.1 2000/07/11 17:03:05 jacob Exp $
use strict;
use 5.004;
use Text::TagTemplate;
use Apache;
my $t = new Text::TagTemplate;
my $r = Apache-request();
my $destination;
my $authcookiereason;
if ( $r-prev() ) { # we are called as a subrequest.
$destination = $r-prev()-args()
? $r-prev()-uri() . '?' . $r-prev-args()
: $r-prev()-uri();
$authcookiereason = $r-prev()-subprocess_env(
'AuthCookieReason' );
} else {
$destination = $r-args( 'destination' );
$authcookiereason = $r-args( 'AuthCookieReason' );
}
$t-add_tag( DESTINATION = $destination );
unless ( $authcookiereason eq 'bad_cookie' ) {
$t-template_file( ../html/login.html );
} else {
$t-template_file( ../html/login-failed.html );
}
$r-send_http_header;
print $t-parse_file unless $r-header_only;
When I go to /test2/index.html I get this error:
Can't locate object method request via package Apache at
.../cgi-bin/login.pl line 16.
[Wed Oct 10 10:43:26 2001] [error] [client 172.28.22.253] Premature end
of script headers: .../cgi-bin/login.pl
Here is the software and versions I have installed:
apache 1.3.20, Apache-AuthCookie-3.00, Apache-AuthCookieLDAP-0.02,
mod_perl-1.26, perl5.005_02
Please help. I have looke all over deja.com, and all of the perl and
mod_perl sites I can think of to no avail.
Re: Using mod_perl to modify referer...
Brian [EMAIL PROTECTED] writes: I have a unique situation in which I need to change the http_referer. What I've done is written a quick script that looks like this: [snip] Now, the problem is this: It works perfectly as long as the client remains on our server. But, if they go to another domain the referer reverts back to what it was before. I need to change it, and have it stay changed. Is there ANY way of doing this with mod_perl? Any help is appreciated. I've been beating my head on the desk for a while here. :o) There is no way to do this. The REFERER field is set by the web client and can not be altered by the server. Once it's sent to the server as part of a HTTP request, the server is free to modify it as it sees fit (as you've done in mod_perl), but it can not tell the client to adopt this new value. Two possible workarounds would be to direct hyperlinks to an intermediate page which in turn redirects the client the final destination. That should set the REFERER correctly to the intermediate page (though perhaps not for 302 redirects). Another possibility would be to abandon using the REFERER field altogether. Use a cookie to encode the necessary information or encode it in the query string of the request itself.
Re: comparison of templating methods?
will trillich [EMAIL PROTECTED] writes: AxKit HTML::Embperl The two that I've had the most experience with are AxKit and HTML::Embperl, and I'd recommend them both. They are both well maintained (both released updates in this week) and the mailing lists for both are very responsive and helpful. AxKit presents XML data in whatever format you choose using XSL (or XPathScript), making it very powerful and giving it staying power (since it's standards based). I haven't had the need to use some of AxKit's other features (XPathScript, XSP), but that's because I've been able to accomplish everything I've needed to with XML/XSLT. I've been using HTML::Embperl for strict HTML presentation. I've recently begun to play with HTML::EmbperlObject (part of the same package), and I like it, a lot. It allows you to define a single file as a base template (or a skin to borrow another term), which is wrapped around individual components. This allows you to keep all of your standard headers and footers in a single file, while your forms and results sets can be defined in separate, self contained templates. Add onto that all of the capabilities of HTML::Embperl, and you've got quite a nice package. XPathScript XSLT These aren't really templating toolkits - just specifications that can be useful for transforming XML data to whatever format you choose. The AxKit site has lots of good information and links on both of these.
Re: Getting the wrong URL
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: OK, I think I have solved this problem, but I would like to run my solution by you folks, and see if it makes any sense. What we found, on a more thorough code review, was that a number of the handlers were doing a redirect by calling send_cgi_header, and then exit()'ing. It seemed to us that the exit would kill the Perl interp, and the Apache child would then just keep serving whatever it had in its buffer at the time. Does that make any sense? If so, will die() have the same results? I started grepping for exit everywhere, and removed it, but along the way I saw a number of places that we're calling die. I expect that this is just a really stupid newbie problem - I've only been doing mod_perl stuff for about 6 months or so. And, in fact, once it occurred to me that this might be the problem, of course I found it in the FAQ. In case you haven't found the guide yet: http://perl.apache.org/guide/porting.html#Terminating_requests_and_process http://perl.apache.org/guide/porting.html#die_and_mod_perl -- Rich Bowen - Author - Apache Server Unleashed http://www.apacheunleashed.com/
Re: Authorization question and subdirectories
Mike Cameron [EMAIL PROTECTED] writes: Is it possible to have the same PerlAuthzHandler use different require's on a subdirectory once a user has been authorized for a parent directory? Here is what i would like to be acle to do: Location / SetHandler perl-script AuthType MyAuth AuthName MyAuth PerlAuthenHandler MyAuth-authenticate PerlAuthzHandler MyAuth-authorize require valid-user How about: require valid-user administrator Location/ shouldn't this be /Location? Location /restricted SetHandler perl-script AuthType MyAuth AuthName MyAuthSupertight PerlAuthenHandler MyAuth-authenticate PerlAuthzHandler MyAuth-authorize require user administrator Location/ authenticate is working fine and when I debug the $r-requires in authorize it only returns the 'valid user' requirement and not the user administrator requirement even when i access /restricted. Right now the code in authorize just prints the requirements via $r-log_error() then returns OK; What am I missing? Why doesn't authorize see the second requirement for the URI /restricted?
Re: Authorization question and subdirectories
sterling [EMAIL PROTECTED] writes: On 16 May 2001, Chris Strom wrote: Mike Cameron [EMAIL PROTECTED] writes: Is it possible to have the same PerlAuthzHandler use different require's on a subdirectory once a user has been authorized for a parent directory? Here is what i would like to be acle to do: Location / SetHandler perl-script AuthType MyAuth AuthName MyAuth PerlAuthenHandler MyAuth-authenticate PerlAuthzHandler MyAuth-authorize require valid-user How about: require valid-user administrator no - he just wants valid-user for the root location The MyAuth::authorize handler can be modified to reject user administrator unless the URI matches ^/admin (or whatever it was, sorry I cut that off in my earlier reply). Location/ shouldn't this be /Location? no. I'm pretty sure that it should be. This closes the Location / tag. sterling
Re: [OT] ideas on design of a diff monitor
Nick Tonkin [EMAIL PROTECTED] writes: Hi all, I'm working on a tool that should compare two versions of a file (usually, a web page) and report the _number_ of changes from one to the other. I've played with Algorithm::Diff as well as standard diff and haven't found a really sane way to count changes. With Algorithm::Diff the output appears to be too granular: if I add five words onto a sentence it counts five changes, when it surely is only one ... Wow, this really is OT, but what the hey, it's Friday. There is no way that what you've described is going to work. If I add a word to a sentence on Monday and a second word on Tuesday, there have been two changes. From your description, your ultimate solution would report one change when there have been two. The only way to get what you want is with version control software. You can write your own, but I'd recommend CVS (www.cvshome.org). And diff combines all changes on one line into one, afaics ... Has anyone tackled this issue before? Thanks, ~~~ Nick Tonkin
Re: capturing subrequest output (have things changed)
Anand Raman [EMAIL PROTECTED] writes: hi guys I just started off using modperl so excuse me if this has been answered. Is there a way to capture output from a subrequest.. rather than allowing the subrequest to directly output the response to the client browser. I need to be able to parse the output of the subrequest before outputting it to the browser. Are you trying to do something like: http://perl.apache.org/guide/modules.html#Apache_OutputChain_Chain_Sta or http://perl.apache.org/guide/modules.html#Apache_Filter_Alter_the_outpu Apologies if you've already read the guide, but it sounds as if you might be able to make use of this for what you're trying to do.
RE: PerlAccessHandler via set_handlers()?
-Original Message-
From: will trillich [mailto:[EMAIL PROTECTED]]
thanks one and all for the pointers on cookies. i probably grok
738% more than i did, but i have a feeling it's still only 13% of
the pie. or in this case, cookie...
so how's this PerlAccessHandler, for twisted logic? hole-punching
and pitfall-warning equally welcome:
This ought to work fine, but it probably won't scale well if you ever have a
need to extend this to support multiple authentication paths (more than one
user database or user type). You'll just end up pushing more and more logic
into the handler which is going to get you into trouble. This won't scale
at all if you ever need to create a central login/ticket server.
The beauty of the example in the Eagle book (and Apache::AuthTicket) is that
it defines distinct handlers for distinct URL spaces which, in turn,
correspond to distinct functions (prompt for login, authentication,
authorization). If you ever have the need to separate these across multiple
servers, you'll have difficulties with your scheme.
Also, you'll always have to be extremely careful when extending this in the
future to always unshift login or authentication handlers when you return OK
or DECLINED. Since you've lumped login prompt/authentication/authorization
all into a single handler, returning OK without a challenge/authentication
handler will immediately grant access to the requested resource.
#httpd.conf
PerlAccessHandler My::TrollUnderTheBridge
PerlHandler Something::OrOther
#perl
package My::TrollUnderTheBridge;
sub handler {
my $r = shift;
if ( logging_in($r) ) {
my $h = $r-get_handlers( 'PerlHandler' );
unshift @{$h},\checkUser ; # do
checkUser first
$r-set_handlers( PerlHandler = $h );
I think this is wrong. checkUser() should be a PerlAccessHandler. You
should probably simply return checkUser rather than waiting until the
content handler phase.
} elsif ( needs_login($r) ) {
$r-set_handlers( PerlHandler = [ \login ] );
# return AUTH_REQUIRED; or not ?
Not. Can only return OK, DECLINED or FORBIDDEN in a PerlAccessHandler.
Besides AUTH_REQUIRED (in a PerlAuthHandler) will prompt for a HTTP basic
authentication session, which you certainly don't want. Should simply
return OK or DECLINED and let the request fall through to the PerlHandler.
}
return OK;
}
sub checkUser {
my $r = shift;
if ( bad_passwd( $r ) ) {
# generate html for username/password
login screen, again
login( $r );
# we handled it, other handlers won't
be called (right?)
return OK;
} else {
$r-headers_out-add( 'Set-Cookie' =
make_ticket( $r ) );
# let normal handler do its thing
return DECLINED;
}
}
so i can keep the same url for all three stages, with no need for
preliminary cookies:
3. valid ticket - show web pages
else
2. validate user/pass - make ticket show pages
else
1. login - get user/pass
is this sound? or am i fuxnored?
--
but then from within login() i'd like to be able to abort, like
so--
RE: PerlAccessHandler -- struggling and drowning
headmeta http-equiv=Refresh content=2; http://www.no-way-in-hell-bubba.com/login/; should be: meta http-equiv=Refresh content=2; URL=http://www.no-way-in-hell-bubba.com/login/;
RE: Cookies in PerlAccessHandlers
You may have a typo in the code provided. Also, you should probably start
using mod_perl methods rather than perl built-in functions.
In a PerlAccessHandler I have code similar to the following:
sub handler
{
my $r = shift;
my ($cgi, $cookie);
use CGI;
$cgi = new CGI;
$cookie = $cgi-cookie(-name = 'test');
# For debugging only
open(TEST, /tmp/accesstest);
flock(TEST,2);
print TEST cookie = $cookie;
close(test);
This should certainly be something like:
my $log = $r-log();
$log-debug(cookie = $cookie);
which would log to the apache error log (with LogLevel set to debug in
httpd.conf). Did you mean to close TEST instead of test?
# This if block is not included in the PerlHandler version
if ($cookie eq '')
{
return FORBIDDEN;
}
Still need to return something here!
return OK;
}
However, nothing is written to the log file and the forbidden
screen is
displayed. The exact same code works fine if its in a regular
mod_perl module
installed using PerlHandler. Why is the code working inside a
PerlHandler
module and not in PerlAccessHandler?
PerlHandler's don't require a return value (although it's best to do so in
case you want to chain several of them together). PerlAccessHandler's must
return OK, FORBIDDEN or DECLINED.
Hope that helps,
Chris
RE: Help: Can't use string (Exchange::Account::My) as a HASH ref while strict refs in use trying to use instance variables in my handler
Anyway, what you should do is create a constructor:
sub new {
[snip]
You mean like this code segment that I included in my original post
just below the handler code :)
sub init {
[snip]
Ah yes, but you called your's "init", which is quite misleading to those of
us who tend not to pay attention.
Wait a second. I have a startup.pl, and inside that I have the lines:
use Exchange::Account::My;
my $account_interface = Exchange::Account::My-init;
Won't that do what I need it to do? When the root process forks off
children, won't a complete copy of $account_interface go with it, with
everything all set and ready to go?
I wouldn't think that this would be the case, but I may be mistaken. Since
you've declared $account_interface with 'my', that variable should only be
available within the scope of the startup.pl script. Even if you went with
use vars qw($account_interface);
I still don't think that it would be available in the Exchange::Account::My
namespace.
Except for calling the contructor with every call of the handler,
I think I've done everything right. Isn't the part of idea behind
mod_perl handlers that one _doesn't_ have to call the contructor
_every_ time the handler gets called? Otherwise invites massive
overhead.
Is a bless really massive overhead? I can't say as I've ever had a problem
calling the constructor with every request (at least with simple objects).
Obviously, what I'm doing doesn't work. But could someone show me
how to call the constructor just once in in a childs lifetime?
startup.pl is not the place to do this - it gets called at server start-up
(or restart), not child initialization. What you could do is create a
ChildInitHandler for this class, which sets a global variable within your
package:
use vars qw($SELF);
sub configure {
my ($class) = shift;
Apache-push_handlers( PerlChildInitHandler =
sub {
# use that weird "init" constructor name
$SELF = $class-init(@_);
}
);
}
You can then change your handler to not use the $$ prototype, but get an
object reference from $SELF:
sub handler {
my $q = shift;
my $self = $SELF;
# the rest of your code as is...
}
In your startup.pl, you'd have:
use Exchange::Account::My;
Exchange::Account::My-configure();
I haven't tested that. As I said, I've never had call to create the object
only upon child initialization. I'll be the first to admit that I'm
relatively new to the mod_perl thing, so there may be an easier or more
elegant way to do this, but that ought to work. Hope that helps.
Chris
RE: Help: Can't use string (Exchange::Account::My) as a HASH ref while strict refs in use trying to use instance variables in my handler
Subject: Help: Can't use string ("Exchange::Account::My") as
a HASH ref
while "strict refs" in use trying to use instance variables in my
handler
[snip]
sub handler ($$) {
my ($self, $q) = @_;
my $r= Apache::Request-new($q);
$self-child_init unless $self-{_child_started_up}; # dies
here!
[snip]
I think that you really need to have a legitimate constructor, not one that
is called conditionally. $self is not a blessed reference - just a string
containing the class name. The call to $self-child_init works, even with
strict refs, because there is a child_init subroutine defined in your
package's namespace. With $self-{_child_started_up}, you're just calling
"Exchange::Account::My"-{_child_started_up}, which will cause the error
since the string "Exchange::Account::My" is not a reference to a hash, it's
just a string.
Anyway, what you should do is create a constructor:
sub new {
my $class = shift;
my $self {@_};
bless $self, $class;
return $self;
}
Then rewrite the above snippet of your code to:
sub handler ($$) {
my ($class, $q) = @_;
my $r = Apache::Request-new($q);
my $self = $class-new(request=$r);
$self-child_init unless $self-{_child_started_up};
# The rest of the code...
Then you should be good to go (instance variables and all!). Hope that
helps,
Chris
RE: PerlAccessHandler Question...
#Location Handlers Location PerlAccessHandler Apache::GateKeeper /Location The Location directive needs to specify a URL to which it applies: Location / Perl*Handlers can go pretty much anywhere, as long as the server administrator hasn't diabled .htaccess files. perl.conf will work. httpd.conf will work. Hope that helps. Chris
RE: Add to default chain of handlers
Hi I wonder how would I be able to add a perl handler in front of all the default handlers that are being used by apache. Try the PerlInitHandler directive. Location /members PerlAuthHandler Moo::Auth PerlAuthzHandler Moo::MemberAuth PerlAuthzHandler Moo::MembershipType PerlSetvar MembershipTypeRequired Premium --- Here were it breaks down SetHandler perl-script PerlHandler Moo::Redirect --- Here what works, but makes me feel weird about that. PerlAuthzHandler Moo::Redirect # Use the following instead: PerlInitHandler Moo::Redirect I understand that I clobber the chain of the default handlers that are used by apache in this case. What I am interested in is to use MY perl-script handler first There are several phases of Apache's response to a client request. mod_perl defines a handler for each. PerlInitHandler handles a request before PerlAuthHandler and PerlAuthzHandler. See http://perl.apache.org/guide/config.html#Perl_Handlers for more information.
RE: Transfering Headers... w/ miltiple 'Set_Cookie'
You might try:
$headers-scan(sub {
$r-headers_out-add(@_);
print STDERR join("=", @_), "\n"
});
The STDERR will output the seen headers to your logs.
the problem is that there are many Set-Cookie instructions
in $headers but mod_perl seems to use a tied hash to link
to the request table and so each set cookie replaces the
last as the hash key is seen to equal? How do I get
around thisI tried:
$r-headers_out-add('Set-Cookie' = $cookieString);
This should work. The add() method is part of the Apache::Table class,
which allows multiple key/value pairs with the same key. See the discussion
of Apache::Table in the eagle book for more details, and an exact example of
what you're trying to do here.
If HTTP::Headers::scan() doesn't work, you might look into the HTTP::Cookies
module:
$cookie_jar = HTTP::Cookies-new;
$cookie_jar-extract_cookies($response);
$cookie_jar-scan( sub {
$r-headers_out-add(@_[1,2]);
});
Hope that helps.
Chris
RE: Unset PerlAuthenHandler (I wish)
Removes all PerlAuthenHandlers:
LocationMatch /websites/foo.net/htdocs/passwd_forgoten/
PerlInitHandler "sub
{$_[0]-set_handlers(PerlAuthenHandler=undef);}"
/LocationMatch
Creates a single PerlAuthenHandler whose sole function is to return OK.
I think this should be: ... set_handlers(PerlAuthenHandler = [\OK]);
Both work, but why set up a handler that does nothing?
RE: Use of .htaccess files
You will need to use StatINC. mod_perl does not re-read modules that it has already loaded. -Original Message- From: Kevin Beckford [mailto:[EMAIL PROTECTED]] Sent: Friday, November 17, 2000 11:06 PM To: [EMAIL PROTECTED] Subject: Use of .htaccess files Hello all, I'm a newbie to mod_perl, and I have a question. We have mod_perl on our server, but it is a standard out of the box install (Only PerlHandler is enabled.) Now, I'd like to use .htaccess files to test some stuff out (no dev server either) and I don't want to be constantly restarting the server. Am I correct in thinking that since .htaccess files are read by the server every request, I do not need to use techniques like Apache::StatINC to ensure that the libs get read every request. What Perl directives can I not put in .htaccess? I plan on testing this stuff in a directory, and if it works, moving it into the main server. - 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: ASP Editor
Emacs, of course! Use it in conjunction with MMM Mode for Emacs (http://mmm-mode.sourceforge.net/). Get the latest version of Emacs for windows from http://www.gnu.org/software/emacs/windows/ntemacs.html or http://www.xemacs.org (my preference is for the former). -Original Message-From: Differentiated Software Solutions Pvt. Ltd [mailto:[EMAIL PROTECTED]]Sent: Friday, November 10, 2000 7:07 AMTo: [EMAIL PROTECTED]Subject: ASP Editor Hi, We are using Apache::ASP. Could anybody refer us to a decent windows based editor for this. We want an editor which will have syntax highlighting features for both ASP objects as well as perlscript. Thanks, Murali Differentiated Software Solutions Pvt. Ltd.176, Ground Floor, 6th Main,2nd Block, RT NagarBangalore - 560032Phone : 91 80 3431470www.diffsoft.com
RE: PerlRun StatInc perl5_00405
Creating a nearly empty warnings.pm works, but I had to define the package
namespace and create the unimport method as an empty subroutine like:
##
package warnings;
sub unimport {}
1;
##
If this is done, then you need to change the following lines in PerlRun:
##
BEGIN {
if ($] 5.006) {
$INC{'warnings.pm'} = __FILE__;
*warnings::unimport = sub {};
}
}
##
to the following (after creating warnings.pm, of course):
##
BEGIN {
if ($] 5.006) {
require warnings;
}
}
##
This works (as does my solution of deleting and manually setting
$INC{'warnings.pm'} in a PerlInitHandler). I'm not sure which is more
elegant, but I lean toward yours since anonymous subroutines in apache
configuration files add to clutter.
Thanks.
Chris
My hack:
PerlModule Apache::StatINC
#
# hack to keep $INC{'warnings.pm'} defined. PerlRun includes a
# workaround for perl5.6 which defines $INC{'warnings.pm'} and
# ties the warnings::unimport function to an anonymous sub-routine.
#
PerlInitHandler "sub {delete $INC{'warnings.pm'};
$INC{'warnings.pm'='/usr/local/lib/perl/site_perl/Apache/PerlRun.pm';}"
PerlInitHandler Apache::StatINC
PerlSetVar StatINC_UndefOnReload On
PerlSetVar StatINC_Debug 1
PerlWarn On
PerlTaintCheck On
It's not the prettiest thing, but it does what's needed.
PerlRun StatInc perl5_00405
I'm having trouble using PerlRun with the StatInc module. The symptom is
several error log file entries of the form:
[Wed Nov 8 11:12:20 2000] PerlInitHandler subroutine
`Apache::StatINC::handler' : Apache::StatINC: Can't locate
The offending item in %INC appears to be the 'warnings.pm' entry defined on
line 308 of PerlRun:
BEGIN {
if ($] 5.006) {
$INC{'warnings.pm'} = __FILE__;
*warnings::unimport = sub {};
}
}
The value for this entry is still defined after the PerlModule
Apache::PerlRun directive, but, by the time the PerlHandler is invoked,
$INC{'warnings.pm'} evaluates to undef (the key is still defined, just not
its value). This, of course, causes StatInc to generate the above error
message.
We're using Bundle::Apache 1.02, perl 5_00405.
My perl.conf file contains the following:
snip
PerlFreshRestartOn
PerlModule Apache::StatINC
PerlInitHandler Apache::StatINC
PerlSetVar StatINC_UndefOnReload On
PerlSetVar StatINC_Debug 1
PerlWarn On
PerlTaintCheck On
/snip
My virtual server contains the following:
snip
Alias /cgi-bin /path/to/cgi-bin
PerlModule Apache::PerlRun
Location /cgi-bin
SetHandler perl-script
PerlHandler Apache::PerlRun
Options +ExecCGI
PerlSendHeader On
/Location
/snip
Any help here would be most appreciated. Thanks!
Chris
RE: PerlRun StatInc perl5_00405
No, I don't have warnings.pm. It is only included in 5.6. We have no plans
on upgrading at this time. The code snippet from PerlRun is a workaround
for perl versions prior to the most recent release, but it appears to be
causing problems with StatInc.
perl -V reports:
Summary of my perl5 (5.0 patchlevel 4 subversion 5) configuration:
It may be that the combination of PerlRun/StatInc/perl5.6 simply will not
work. If we were not using StatInc or were using perl 5.6, I do not believe
that we would be having these problems. Unfortunately, our development
environment would be rather painful without StatInc and, as I said, we have
no plans on upgrading from 5_00405.
For now, I've got the following hack in perl.conf:
PerlModule Apache::StatINC
#
# hack to keep $INC{'warnings.pm'} defined. PerlRun includes a
# workaround for perl5.6 which defines $INC{'warnings.pm'} and
# ties the warnings::unimport function to an anonymous sub-routine.
#
PerlInitHandler "sub {delete $INC{'warnings.pm'};
$INC{'warnings.pm'='/usr/local/lib/perl/site_perl/Apache/PerlRun.pm';}"
PerlInitHandler Apache::StatINC
PerlSetVar StatINC_UndefOnReload On
PerlSetVar StatINC_Debug 1
PerlWarn On
PerlTaintCheck On
It's not the prettiest thing, but it does what's needed.
-Original Message-
From: G.W. Haywood [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 08, 2000 3:00 PM
To: Chris Strom
Cc: [EMAIL PROTECTED]
Subject: Re: PerlRun StatInc perl5_00405
Hi there,
On Wed, 8 Nov 2000, Chris Strom wrote:
The offending item in %INC appears to be the 'warnings.pm' entry
defined on line 308 of PerlRun:
BEGIN {
if ($] 5.006) {
$INC{'warnings.pm'} = __FILE__;
*warnings::unimport = sub {};
}
}
Do you even have the file 'warnings.pm' if you're using 5.004_05?
I have it in a 5.6.0 inststallation, but not in 5.005_03. That's
why there's a test for Perl version less than 5.006 (== 5.6.0).
What does Perl -V say?
73,
Ged..
