RE: PerlModule options?
Hi again Stas Perrin, So, its a no-can-do then. I'll keep putting the use in every module to import the symbols in the proper namespace. Alternatively I guess I could probably use the functions with fully qualfied name Apache::ReadConfig::myFunction(), however this would add extra typing and this is exactly what I was trying to escape from. Thanks everyone for your time and kind answers. Cheers, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 7:08 PM To: Mike P. Mikhailov Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: PerlModule options? Mike P. Mikhailov wrote: Hello [EMAIL PROTECTED], Tuesday, August 05, 2003, 2:55:52 PM, you wrote: cfr Hi list, cfr One questions for the braves ;-) cfr As I understand, the directive cfr PerlModule Foo::Bar cfr loads the module but doesn't import the symbols since it is equivalent to cfr the use Foo::Bar (). Therefore I should use use Foo::Bar in each program cfr only to make the import. cfr Is there other way to load the module and import the symobols specified in cfr @EXPORT at mod_perl reloading time, without adding a special line in each cfr and every script using them? cfr Perhaps some options passed to PerlModule though adding (...) doesn't help cfr since PerlModule expects a list of modules. I think this will work perl use Foo::Bar qw ( ... whatever you want to import ... ); /perl I think Lian was asking how to import symbols into his scripts/handlers at the server startup. Lian, you *must* put the special line in each and every script you want the symbols to be exported to, because exporting happens inside the script's namespace, which is no main:: under Apache::Registry, but special for each script. You can preload registry scripts using Apache::RegistryLoader, but this doesn't remove the need for an explicit import. __ 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: ModPerl - CGI in the same request phase
Hi, I'm in the happy position of finding myself a solution to my problem. Here it is for anyone interested ... PerlModule MyModules::Module1 Directory /usr/local/apache1/protected SetHandler perl-script PerlHandler MyModules::Module1 PerlSendHeader Off /Directory PerlModule Apache::PerlRun Directory /usr/local/apache1/protected/admin/ SetHandler perl-script PerlHandler MyModules::Module1 Apache::PerlRun Options +ExecCGI /Directory And then, inside my handler, when I decide the users are alowed to run scripts from the /admin directory I let them through by returning DECLINE, if not I print an error page and return DONE to skip the second handler in this phase. Thanks anyway, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 2:33 PM To: [EMAIL PROTECTED] Subject: ModPerl - CGI in the same request phase Hi again everybody, I have the following interesting (I hope ;-) requirement. Sorry for this rather long posting. (mod_perl 1, Apache 1.3.27) I have a custom authentication authorization handler of mine which is the king in a protected directory (and its subdirectories): PerlModule MyModules::Module1 Directory /usr/local/apache1/protected SetHandler perl-script PerlHandler MyModules::Module1 PerlSendHeader Off /Directory Then, for some users that I authenticate as SuperUsers, I should allow the execution of the administrative .cgi scripts in a subdir of this dir(/usr/local/apache1/ssl/protected/admin). (One solution would be to integrate the cgi-s logic into my handler but let's say want to leave them as simple CGI scripts.) I tried to use the Apache::PerlRun in the subdir like this: PerlModule Apache::PerlRun Directory /usr/local/apache1/protected/admin SetHandler perl-script PerlHandler Apache::PerlRun PerlSendHeader On Options ExecCGI /Directory I tried also: Directory /usr/local/apache1/ssl/protected/admin SetHandler cgi-script Options +ExecCGI /Directory The problem is it allows anybody to execute the cgi's since it's not going through my handler anymore (a warn ... statement inserted in my handler shows it's not executed when requesting /protected/admin/* files.) More generally: how can I dynamically change a directory's handler during the same phase I was thinking about using dynamic stacked handlers, something like: if the user is allowed in the admin section, my handler should push the cgi-script handler in the line of execution. However, the documentation says about stacking more custom created handlers and not those coming with Apache so I'm not sure how to do it. Thanks for your time, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net
RE: PerlModule options?
Hello Mike, Thanks for your answer, this should do it indeed. Super! Somehow I didn't think about perl sections... Thanks again, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: Mike P. Mikhailov [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 2:23 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: PerlModule options? Hello [EMAIL PROTECTED], Tuesday, August 05, 2003, 2:55:52 PM, you wrote: cfr Hi list, cfr One questions for the braves ;-) cfr As I understand, the directive cfr PerlModule Foo::Bar cfr loads the module but doesn't import the symbols since it is equivalent to cfr the use Foo::Bar (). Therefore I should use use Foo::Bar in each program cfr only to make the import. cfr Is there other way to load the module and import the symobols specified in cfr @EXPORT at mod_perl reloading time, without adding a special line in each cfr and every script using them? cfr Perhaps some options passed to PerlModule though adding (...) doesn't help cfr since PerlModule expects a list of modules. cfr Thanks a bunch, cfr Lian Sebe, M.Sc. cfr Freelance Analyst-Programmer cfr www.programEz.net I think this will work perl use Foo::Bar qw ( ... whatever you want to import ... ); /perl -- WBR, Mike P. Mikhailov mailto: [EMAIL PROTECTED] ICQ:280990142 I believe in God, only I spell it Nature.
RE: help on setting up a PerlFixupHandler
Well, thank you very much for the references.
I guess I'll have to skip next few pints and finally get that book I've
heard so much about ;-)
Lian Sebe, M.Sc.
Freelance Analyst-Programmer
www.programEz.net
-Original Message-
From: Geoffrey Young [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 07, 2003 3:15 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: help on setting up a PerlFixupHandler
So, while I'm not 100% sure about this, logically the $r-content_type
should be empty before the response is prepared to be sent to
the browser,
so it should be empty in the Fixup stage.
not necessarily.
if you request index.html, mod_mime (at the mime-type phase) will set the
content type to text/html based on the file extension.
mod_mime_magic will
do the same, but by analyzing the contents of the file.
if you are generating dynamic content and there is no file type
to examine
(or consistently relate, as .cgi can produce multiple CTs), no
default type,
and no file to examine, then there is no way the mime modules can set a
content type. the end result would be undef in fixup and beyond.
In fact what I miss (and I guess I'm not alone ;-) is a
documentation that
would take the $r from the newly born state and describe what's
added/deleted to it during a full process loop, at each stage.
there is lots of documentation on this kind of thing, but nothing
specific
like $r-content_type is set during the mime-type phase because things
like this are dependent on varying circumstances.
Part III of the mod_perl Developer's Cookbook talks about the
each phase of
the request cycle in depth. you can read part of it from
http://www.modperlcookbook.org/. the eagle book also covers it.
Besides I'd like to know about each major optional module (like
mod_rewrite,
mod_ssl, etc) where they intervine in the loop and what they
read/or set.
Most of these one can guess but I'm not aware of such a documentation.
that's complex. for instance, mod_rewrite can enter just about
every part
of the request cycle, depending on how it's configured.
the way to discover this is to look at the code (remember, it's
open :) - at
the end of each extension module is the place where hooks are typically
registered. look for a line such as
module MODULE_VAR_EXPORT rewrite_module = {
which begins the list of phases the module hooks into.
HTH
--Geoff
RE: help on setting up a PerlFixupHandler
Hi Geoffrey Xavier,
I don't argue on the fact the Content-type is an entity header available in
both situations. However I'm talking about how to get/set in mod_perl the
Content-type in those 2 situations, which according to the mod_perl 1.0 API
docs and as I understand it, are different animals:
1.7.8 $r-content_type( [$newval] )
Get or set the content type being sent to the client. Content types are
strings like text/plain,
text/html or image/gif. This corresponds to the Content-Type header in
the HTTP
protocol. Example of usage is:
$previous_type = $r-content_type;
$r-content_type(text/plain);
...
1.5.16 $r-header_in( $header_name, [$value] )
Return the value of a client header. Can be used like this:
$ct = $r-header_in(Content-type);
So, while I'm not 100% sure about this, logically the $r-content_type
should be empty before the response is prepared to be sent to the browser,
so it should be empty in the Fixup stage.
In fact what I miss (and I guess I'm not alone ;-) is a documentation that
would take the $r from the newly born state and describe what's
added/deleted to it during a full process loop, at each stage.
Besides I'd like to know about each major optional module (like mod_rewrite,
mod_ssl, etc) where they intervine in the loop and what they read/or set.
Most of these one can guess but I'm not aware of such a documentation.
Regards,
Lian Sebe, M.Sc.
Freelance Analyst-Programmer
www.programEz.net
-Original Message-
From: Geoffrey Young [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 07, 2003 5:36 AM
To: Xavier Noria
Cc: [EMAIL PROTECTED]
Subject: Re: help on setting up a PerlFixupHandler
Xavier Noria wrote:
[EMAIL PROTECTED] wrote:
It seems to me that $r-content-type is for what your server
sends to the
client, which is probably undef in the Fixup stage, where you test it.
You probaly meant to test for the
$ct = $r-header_in(Content-type)
if you wanted to see whats requested from the client.
Content-Type is an entity header, so it can apply to both incoming and
outgoing headers. however, it's more generally seen as an
outgoing header
for normal web activity, leaving headers_in empty.
But then, there are examples in the books that use that method that way.
For instance, in recipe 14.1 of the Cookbook, which is about how to
disable a configured mod_perl PerlHandler, the Technique section says:
Set the handler back to the default Apache content handler from a
PerlFixupHandler.
# Only run the PerlHandler for HTML.
# For everything else, run the default Apache content handler.
$r-handler('default-handler') unless $r-content_type eq 'text/html';
I think in the Eagle book there is some code like that as well, cannot
check it right now however.
So, looks like that test makes sense, or can make sense, in
that handler.
$r-content_type is generally set by mod_mime, during the
mime-type phase,
according to it's rules. for most setups, it should be set to
something by
fixup, but I guess it's dependent on your particular settings.
--Geoff
RE: PerlModule options?
Hi Perrin, I see your point. However I'm speaking about one simple templating module exporting 2 functions that are used to generate HTML in every other module on the server. So it'll be pollution but bearable ;-) Thank you, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 8:29 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: PerlModule options? On Tue, 2003-08-05 at 04:55, [EMAIL PROTECTED] wrote: loads the module but doesn't import the symbols since it is equivalent to the use Foo::Bar (). Therefore I should use use Foo::Bar in each program only to make the import. Correct. Is there other way to load the module and import the symobols specified in @EXPORT at mod_perl reloading time, without adding a special line in each and every script using them? No, that would be Bad. By putting a use Foo in each module that wants to import functions from Foo, you are explicitly saying please pollute my namespace to Foo. That sort of thing shouldn't happen unless you request it. Perhaps some options passed to PerlModule though adding (...) doesn't help since PerlModule expects a list of modules. There's no way it could since PerlModule has no way of knowing what namespaces you are going to want polluted. - Perrin
ModPerl - CGI in the same request phase
Hi again everybody, I have the following interesting (I hope ;-) requirement. Sorry for this rather long posting. (mod_perl 1, Apache 1.3.27) I have a custom authentication authorization handler of mine which is the king in a protected directory (and its subdirectories): PerlModule MyModules::Module1 Directory /usr/local/apache1/protected SetHandler perl-script PerlHandler MyModules::Module1 PerlSendHeader Off /Directory Then, for some users that I authenticate as SuperUsers, I should allow the execution of the administrative .cgi scripts in a subdir of this dir(/usr/local/apache1/ssl/protected/admin). (One solution would be to integrate the cgi-s logic into my handler but let's say want to leave them as simple CGI scripts.) I tried to use the Apache::PerlRun in the subdir like this: PerlModule Apache::PerlRun Directory /usr/local/apache1/protected/admin SetHandler perl-script PerlHandler Apache::PerlRun PerlSendHeader On Options ExecCGI /Directory I tried also: Directory /usr/local/apache1/ssl/protected/admin SetHandler cgi-script Options +ExecCGI /Directory The problem is it allows anybody to execute the cgi's since it's not going through my handler anymore (a warn ... statement inserted in my handler shows it's not executed when requesting /protected/admin/* files.) More generally: how can I dynamically change a directory's handler during the same phase I was thinking about using dynamic stacked handlers, something like: if the user is allowed in the admin section, my handler should push the cgi-script handler in the line of execution. However, the documentation says about stacking more custom created handlers and not those coming with Apache so I'm not sure how to do it. Thanks for your time, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net
RE: help on setting up a PerlFixupHandler
Hi, It seems to me that $r-content-type is for what your server sends to the client, which is probably undef in the Fixup stage, where you test it. You probaly meant to test for the $ct = $r-header_in(Content-type) if you wanted to see whats requested from the client. Anyway, as Christopher pointed out you can get the what's before load off your shoulders ;-) HTH, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: Xavier Noria [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 9:40 PM To: [EMAIL PROTECTED] Subject: Re: help on setting up a PerlFixupHandler On Wednesday 06 August 2003 20:26, Christopher Grau wrote: On Wed, Aug 06, 2003 at 08:24:30PM +0200, Xavier Noria wrote: To fix that, is it safe to change the test to defined $r-content_type and $r-content_type ne 'text/html'; or is there a better way? I usually don't concern myself with the previous content type when writing Location-based content handlers. My output is always text/html anyway. Would it be safe in your application to just leave it out completely? Hmmm, you are right, now that I think about it /admin will only serve HTML and since I don't understand that undef I'll remove that line altogether, the test is performed by Location anyway. Now that I understand what happens I will try to figure out in the docs when $r-content_type returns something. Thank you very much to all, I was somewhat stuck with this. -- fxn
PerlModule options?
Hi list, One questions for the braves ;-) As I understand, the directive PerlModule Foo::Bar loads the module but doesn't import the symbols since it is equivalent to the use Foo::Bar (). Therefore I should use use Foo::Bar in each program only to make the import. Is there other way to load the module and import the symobols specified in @EXPORT at mod_perl reloading time, without adding a special line in each and every script using them? Perhaps some options passed to PerlModule though adding (...) doesn't help since PerlModule expects a list of modules. Thanks a bunch, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net
RE: templating system opinions (axkit?)
Hi Jesse, -Original Message- From: Jesse Erlbaum [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 8:50 PM To: 'Patrick Galbraith' Cc: [EMAIL PROTECTED] Subject: RE: templating system opinions (axkit?) Hi Patrick -- I like the idea of XSLT/XML, though I find myself trying to read between the lines of hype vs. something that's actually very useful. I don't know, so I don't have any opinions. I do know I'd like to use XSLT/XML so as to have a project to use it for, hence learn it. It's mostly hype in my experience. And not even very useful hype, like Java or PHP, which are actually real things which people might want to use. XSLT seems to be XML geeks' answer to CSS+templating. As if CSS wasn't very successful, as if the world needed another templating system, XSLT seems to have been invented to take the creative work of designing web sites out of the hands of HTML designers, and put it in the hands of XPath programmers. You know. Programmers who are really good at both creative design and communicating with human beings. Not. Alright, pretty smarmy. But unless you just happen to have thousands of XML documents sitting around on your hard drive, XSLT is a solution in search of a problem. Most of my data is in a RDBMS -- not XML. To enhance the *need* for XSLT, some databases will now return XML. That's an interesting idea. Instead of using a mature language like Perl|Java|PHP, let's use something like XSLT to turn my data into a web page! It's new, shiny, and will solve the problem of TOO MANY people knowing the other aforementioned languages. D'oh! Too cynical? Maybe. The fact that XSLT is still discussed in serious company just bugs me. ;-) Not just that, but what about SOAP... Net RPC... I'd like to know where those fit in as well. Fantastic, useful stuff. I get so tired of Java types talking about how perl is just a scripting language.. it's not an application platform/server like Dynamo/WebSpere/insert $$$ java non-OS app here. I even tried to crack a particular Orielly java book and was turned off on a statement like Perl is good for proto-typing but not a full application server. Yes, there are a lot of prototypes getting millions of pageviews a day and generating signicifican revenue. You hit the nail on the head there: Prototype in Perl, and then just keep using it! A strategy for the NEW New Economy. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 It's nice to see that I'm not alone ;-) Without trying to start a religious war, I think all the debate can easily slip to: Is XML really useful? I mean besides creating new job positions, new software, new frameworks, new problems to be solved, some overhead over processing simple text files, etc. But I shouldn't go in there... As for Java, unfortunately the Perl community is in my opinion in a no-win situation. I've seen lots of people in managerial positions hardly knowing how to read/write their emails using Outlook, not knowing that Perl even exists, but giving lessons about the Java usefulness; to quote a recent one: You can't survive on the Internet today without Java. There is a technical snobbery that is hard to defeat since snobbery itself is human nature. But what would I know? Quit cheap philosophy and back to work... Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net I'm not mad. I've been in bad mood for the last 30 years...
RE: CGI files in apache
Start by looking in Apache's error log to see what's reporting. HTH, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: AROSO Jose Antonio [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 12:36 PM To: '[EMAIL PROTECTED]' Subject: CGI files in apache Hi... When I run a cgi file codified in perl in apache server the server says that have a 500 internal server error. What is it and how can resolve? thanks
RE: Problem with PerlTransHandler
Have you tried to comment out the 2 DBI lines like this:
#my $dbh = DBI-connect('dbi:mysql:db', 'user', 'pswd');
#$dbh-disconnect;
and is still not working? You really need the database connection?
Lian
-Original Message-
From: Sergey V. Stashinskas [mailto:[EMAIL PROTECTED]
Sent: Friday, June 27, 2003 1:48 PM
To: [EMAIL PROTECTED]
Subject: Problem with PerlTransHandler
Hi all,
Excuse me for my poor English because I'm from Russia.
I have the problem with url translation.
There are 2 scripts to do it.
1st script work perfectly, but 2nd failed.
Only difference between them is string my $dbh = DBI-connect...;
I use Apche::DBI but without this module the same thing happens.
Why?
1st:
package Apache::StripSession
use strict;
use Apache;
use Apache::Constants qw(:common);
sub handler {
my $r = shift;
return DECLINED unless $r-uri =~ /^\/session\/([a-zA-Z0-9]{32})(.*)/;
$r-subprocess_env(SESSION = $1);
$r-uri($2);
return DECLINED;
}
2nd:
package Apache::StripSession;
use strict;
use Apache;
use Apache::Constants qw(:common);
sub handler {
my $r = shift;
my $dbh = DBI-connect('dbi:mysql:db', 'user', 'pswd');
$dbh-disconnect;
return DECLINED unless $r-uri =~ /^\/session\/([a-zA-Z0-9]{32})(.*)/;
$r-subprocess_env(SESSION = $1);
$r-uri($2);
return DECLINED;
}
