Re: questions on $r-lookup_uri
1 - Why was no documentation for this method found in the manpage for Apache::Request? Where should I have looked for docs on this? perldoc Apache There are some Apache API docs on ap_sub_req_lookup_uri here: http://httpd.apache.org/docs/misc/API.html#req_orig Though they may not help much in your situation, as they indicate that each sub-request function constructs a new request_rec structure and processes it as you would expect. :) 2 - I did manage to find some docs for this in Ch. 4 of the Stein/Maceachern book, but am wondering why lookup_uri() goes through all phases of request processing up to but not including the content handler. It would seem that looking up a URI would only need to go through the URI translation phase of the subrequest to lookup a URI. From 'perldoc Apache': Apache provides a sub-request mechanism to lookup a uri or filename, performing all access checks, etc., without actually running the response phase of the given request. So presumably it is important that sub-requests get run through standard authentication/authorization/access checks for that particular URI. Among other things. bye, Ben
Re: Problem with DBD::Oracle with mod_perl
PH Don't open a connection during startup. PH Open a connection in the child process instead. BT I will second this. I've done this (unintentionally) when using MySQL, and BT you get a lot of weird errors about statement handles being active, etc. I haven't read the entire thread, so forgive me if I'm restating. But there are reasons for sharing DB connections (and reasons not to). In the case of MySQL and getting messages about active statement handles, that's because you're disconnecting the DBH. If you are in a shared connection enviroment with MySQL, you are winning. Since you don't have to worry about things like transactions and rolling back somebody elses changes. All you need to do is finish() your statement handled when you are finished with them: $sth-finish; This will prevent the errors you are seeing and will allow you to keep the shared DB connection. A shared connection is usefull for efficiency, since creating a connection may be expensive. No, I called finish on all of my statement handles; that is not the reason for the errors I got. The behavior I am talking about *only occurs* for me when I open a connection in the Apache parent. Then this same DB connection is shared across all of the Apache children, and Strange Things occur. I am sorry but this topic is confusing me... Are you saying that persistent DB connection objects are bad? It sounds like that, doesn't it? Well, I'm sorry if it sounds like that, but that's not what I'm saying. :) I am merely echoing Perrin's statement that opening a shared connection in the parent is bad, because this connection is then shared between *all* of the children. You don't want this. You want one connection per child, not one connection shared between all Apache children. The latter *will* cause problems. I am about to switch to Apache::DBI for that very reason. I don't want to create a new db handle with every request. Should I stop, or am I missing something here? Nope, you've got it. If you don't have transactions (anything else?) to worry about, I'd say to use Apache::DBI. I would absolutely encourage anyone to use Apache::DBI. The case I am talking about is a very particular one: when you open a shared connection in the parent. You don't want this connection to be an Apache::DBI connection, so instead you should use the magic 6th arg to DBI::connect to force DBI to handle it exclusively. bye, Ben
Re: Problem with DBD::Oracle with mod_perl
PH Don't open a connection during startup. If you do, it will be shared when
PH Apache forks, and sharing a database handle is bad for the same reasons
PH sharig a file handle is. Open a connection in the child process instead.
I will second this. I've done this (unintentionally) when using MySQL, and
you get a lot of weird errors about statement handles being active, etc.
Speaking of which, what does one do when Apache::DBI is loaded, and
the parent process needs to pull some config info out of the database
that all clients also use? That is, how can I force Apache::DBI to
close that handle prior to the forking of children?
By using the magic 6th arg ($connect_meth in the DBI::connect source) to
DBI::connect. In my DB wrapper I have a connect method that internally calls
DBI::connect; before doing so, it checks to see if it is being called while
Apache is starting up in the parent process, and if so, it uses this special
arg.
my @args = (dbi:$db-{driver}:$dbname, $user, $pass,
{ RaiseError = 1 });
push @args, (undef, 'connect')
if $Apache::Server::Starting or $Visius::httpd_conf::Loading;
$self-{handle} = DBI-connect(@args);
The 'connect' is that magic argument that forces DBI to use its standard
connect method, rather than Apache::DBI::connect, when creating the new db
handle. This means that it is essentially a use-once DB handle, and that it
will not be reused by Apache::DBI.
Does this help?
bye,
Ben
Re: Error decrypting in message using gpg in modperl script
Anyone know why the decryption fails using gpg when run in a perl script in a browser but works if run in a shell? Here's the code sample: my $cipher = TAG; -BEGIN PGP MESSAGE- pvbhS8Q22VYPqn+4sitEw0bgTmDhPo6rruzsSJxCHLBUyTPrYaPlmelF2iADCpKD IeqIOK0KZwRMHrXrlFir37i+2NzmNzcF4kidPKWuKSQe6ZNWs28= =w+vi -END PGP MESSAGE- This is not an answer to your question, but might I suggest (plug) using Crypt::OpenPGP, my pure-Perl OpenPGP implementation? It will decrypt your message, and it won't require launching an external shell etc. use Crypt::OpenPGP: my $pgp = Crypt::OpenPGP-new; my $pt = $pgp-decrypt( Data = $cipher, Passphrase = $pass ); Here is a page w/ some more information: http://rhumba.pair.com/ben/perl/openpgp/ If you have any problems let me know by mail. bye, Ben
Re: ssl encryption
When apache is serving a ssl connection, I assume that everything
sent back and forth between the server and the client is encrypted.
I want an mod_perl script to encrypt/decrypt credit card numbers
obtained over the ssl connection for storage in a db on the server.
Is there any access to the same routines that apache is using for the
encryption or do I have to use some other module. If I have to use
another module, what would be a good choice?
You could use either an asymmetric cipher or a symmetric cipher.
An example of the former is Crypt::RSA (Crypt::DSA is another, but DSA is
used only for signing/verification, not for encryption/decryption).
A good, fast example of the latter is Crypt::Blowfish. Used together with
Crypt::CBC, you get Blowfish in CBC mode:
use Crypt::CBC;
my $cipher = Crypt::CBC-new('passphrase', 'Blowfish');
my $ciphertext = $cipher-encrypt('data');
my $plaintext = $cipher-decrypt($ciphertext);
In other words, you use the same passphrase to both encrypt and decrypt the
data (ie. symmetric).
Personally, I think I'd use a symmetric cipher, but the thing you have to be
careful of is leaving your passphrase around in plain text (eg. in a
script). Doing this negates many of the benefits of encrypting the data in
the first place. :) Sadly I'm not sure of the best answer to this dilemma.
bye,
Ben
Re: Perl Sections, NameVirtualHost, and Aliases
I think that this:
PerlSetVar = {
Auth_DBI_data_source = 'dbi:Pg:dbname=reckdb',
Auth_DBI_username = 'dvicci',
Auth_DBI_pwd_table = 'user_profile',
Auth_DBI_uid_field = 'user_username',
Auth_DBI_pwd_field = 'user_password',
Auth_DBI_pwd_whereclause = '"user_usertype0"',
Auth_DBI_encrypted = 'off',
},
should look more like this:
PerlSetVar = [
[ Auth_DBI_data_source = 'dbi:Pg:dbname=reckdb' ],
[ Auth_DBI_username = 'dvicci' ],
[ Auth_DBI_pwd_table = 'user_profile' ],
[ Auth_DBI_uid_field = 'user_username' ],
[ Auth_DBI_pwd_field = 'user_password' ],
[ Auth_DBI_pwd_whereclause = '"user_usertype0"' ],
[ Auth_DBI_encrypted = 'off' ],
],
That's the format I use when using PerlSetVar.
bye,
Ben
Re: Perl Sections, NameVirtualHost, and Aliases
However, now I'm getting this: Perl: PerlSetVar takes two arguments, Perl config var and value. I don't think PerlSetVar likes this line: [ Auth_DBI_pwd_whereclause = '"user_usertype0"' ], You could try taking out the quotes and see if that helps, cause it did for me (though I didn't check whether the correct var got set): [ Auth_DBI_pwd_whereclause = 'user_usertype0' ], bye, Ben
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Perhaps part of this is that we simply need smarter configure/install methods. ... I've also dealt with this on another app I'm working on (currently under NDA) that requires a bunch of modules, a set of tables in a database, mod_perl, etc. I've been dealing w/ very similar issues in work I'm doing. I've got: * Perl modules * command line tools * database tables * data files * custom configuration * other open-source distributions and more, and it's all got to be installed in the right place, and the Right Thing has to happen if some pieces are already installed, etc. My "solution", so far, is a custom install script. Rather than trying to hack everything into MakeMaker and make it work through some deep magic, I'm writing an install script that's a layer above the MakeMaker stuff: I still let MakeMaker do its job w/ the Perl modules, regression tests, etc. But so far I've ended up writing my own code for everything else. And that's partly why it's not done yet. :) I also mean to investigate cons. bye, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Files .. in virtualhosts in perl sections
Anyone have any experience doing Files sections inside of perlsections
virtualhosts.
I can't see anything in the docs about this.
Just wanted to ask before I start experimenting, as I don't have the first
clue about how this syntax might work.
Assuming I'm not missing something subtle about Files blocks vs. Location
blocks--I've done the latter, not the former--you can just assign your Files
key a hashref:
push @{ $VirtualHosts{$IP} }, {
Files = {
'/foo' = {
SetHandler = 'perl-script',
PerlHandler = 'Foo',
},
},
};
And so on. I use "push" instead of direct assignment because it allows for
multiple named virtual hosts.
bye,
Ben
Re: Flakey [Named]VirtualHost support, should TieHash be used?
For some reason I usually
need to start Apache 4-5 times before it actually "sticks" and starts.
What do you mean by "sticks"? You mean, when it doesn't "work", Apache isn't
running?
What happens when you do httpd -S (should show the configured virtual
hosts)?
One other weirdness.. when I startup Apache, I get a bunch of "unreferenced
and undefined" warnings. Those are evident in the ServerConfig.pm below.
You mean the @VirtualHost = ( undef, undef, ... ) stuff?
This is because of the following line:
$VirtualHost{$ip}[++$#VirtualHost] = {
Where you write $#VirtualHost, that's the *array* @VirtualHost; it's not the
number of elements in @{ $VirtualHost{$ip} }. See the difference? Each time
you increment $#VirtualHost, you
It'd be possible to get the number of elements in @{ $VirtualHost{$ip} } and
increment that etc. But why not just use push?
push @{ $VirtualHost{$ip} }, { ... };
Much easier, yes?
Same thing here:
$NameVirtualHost[++$#NameVirtualHost] = $ip;
push @NameVirtualHost, $ip;
bye,
Benjamin Trott
Re: Flakey [Named]VirtualHost support, should TieHash be used?
Attempt to free unreferenced scalar.
Attempt to free unreferenced scalar.
Attempt to free unreferenced scalar.
Attempt to free unreferenced scalar.
Attempt to free unreferenced scalar.
Interesting. Is the number of "Attempt to free unreferenced scalar."
messages the same as the number of undef elements in @VirtualHost?
Where you write $#VirtualHost, that's the *array* @VirtualHost; it's not the
number of elements in @{ $VirtualHost{$ip} }. See the difference? Each time
you increment $#VirtualHost, you
... got cut off.. I increment the array not the elements??
Oops, sorry. I was going to say that when you increment $#VirtualHost, you
increase the size of the array @VirtualHost, adding a new (undefined)
element.
In other words you're using an array as a glorified index counter. :)
bye,
Ben
Re: [REPOST] MyClass::import() not being called.
The types of parameters I'll pass to this handler will change machine-by-machine. You see, I need to run this package on several different servers, and need it to know how to configure it's self. Okay... I don't think I get exactly why this situation makes using PerlSetVar impossible/impractical, because if you were thinking that you could write PerlAccessHandler My::Access 'parameters' Why can't you just write PerlAccessHandler My::Access PerlSetVar param1 value1 PerlSetVar param2 value2 So I'm not sure I understand that distinction. *However*, if you really want to use import, couldn't you go about doing so like this: Perl use My::Access 'parameters'; /Perl PerlAccessHandler My::Access If you do that, and define a My::Access::import, it should definitely be called correctly. bye, Ben
Bizarre Perl Sections Problem
I'm having a really strange (in my opinion) problem with Perl sections and
using the Apache::ReadConfig namespace explicitly (qualifying variables,
like %Apache::ReadConfig::Location). Here's what I'm doing: I have a small
library of routines; I'm using PerlRequire to load that library. In a Perl
section, I'm then calling a routine from that library that should alter
%Apache::ReadConfig::Location. When I dump out the ReadConfig namespace,
though (using PerlSections-dump), there's nothing in %Location.
*However*, and this is the weird part, this only happens if I don't have a
Perl section before the PerlRequire statement. This will be demonstrated
below.
I have a small test case. Here's the library, called 'foo.pl':
package Foo;
sub bar {
$Apache::ReadConfig::Location{"/foo"} = {
Options = 'ExecCGI',
};
}
1;
Here's the relevant portion of my httpd.conf, where the PerlRequire is
before the first Perl section:
PerlRequire conf/foo.pl
Perl
use Apache::PerlSections;
Foo::bar();
print STDERR Apache::PerlSections-dump;
/Perl
Here's the output of starting up the webserver with that configuration file
(I compiled with PERL_TRACE on):
PerlRequire: arg=`conf/foo.pl'
attempting to require `conf/foo.pl'
loading perl module 'Apache'...ok
loading perl module 'Apache::Constants::Exports'...ok
loading perl module 'Tie::IxHash'...ok
perl_section: /Files
perl_section: /Directory
perl_section: /Files
perl_section: /Directory
perl_section: /VirtualHost
perl_section: /Location
perl_section: /Location
loading perl module 'Apache'...ok
loading perl module 'Tie::IxHash'...ok
package Apache::ReadConfig;
#scalars:
#arrays:
#hashes:
1;
__END__
perl_section: /Files
perl_section: /Directory
perl_section: /Files
perl_section: /Directory
perl_section: /VirtualHost
perl_section: /Location
perl_section: /Location
Nothing in the Apache::ReadConfig namespace, as you can see.
Now, here's the *working* webserver configuration, with a (blank) Perl
section coming before the PerlRequire:
Perl
/Perl
PerlRequire conf/foo.pl
Perl
use Apache::PerlSections;
Foo::bar();
print STDERR Apache::PerlSections-dump;
/Perl
And here's the output:
loading perl module 'Apache'...ok
loading perl module 'Apache::Constants::Exports'...ok
loading perl module 'Tie::IxHash'...ok
perl_section: /Files
perl_section: /Directory
perl_section: /Files
perl_section: /Directory
perl_section: /VirtualHost
perl_section: /Location
perl_section: /Location
PerlRequire: arg=`conf/foo.pl'
attempting to require `conf/foo.pl'
loading perl module 'Apache'...ok
loading perl module 'Tie::IxHash'...ok
package Apache::ReadConfig;
#scalars:
#arrays:
#hashes:
%Location = (
'/foo' = {
'Options' = 'ExecCGI'
}
);
1;
__END__
perl_section: /Files
perl_section: /Directory
perl_section: /Files
perl_section: /Directory
perl_section: /VirtualHost
perl_section: /Location
perl_section: Location /foo
Options ExecCGI (OK) Limit=no
perl_section: /Location
In other words, it works as expected when the blank Perl section is added
before the PerlRequire. So what seems to be happening--and I don't know the
internals side of this, so I'm just making guesses--is that the first Perl
section initializes the Apache::ReadConfig namespace, including the
%Location hash. Without this initialization, an explicit use of
%Apache::ReadConfig::Location seems to be... broken.
And that's as far as I can go with it. :)
So what I'd really like, if possible, is an explanation for this behavior;
adding the blank Perl section seems to provide a useable workaround, but I'd
like to know *why* this is happening.
Thanks all.
bye,
Benjamin Trott
