Re: syntax and sanity check?
Paul wrote:
I'm doing a 45 minute seminar at UAB tomorrow on mod_perl, and would be
very grateful if anyone would point out holes in this code before I try
to show it to a roomful of attendees:
#~~
# module for Apache/mod_perl PerlPostReadRequestHandler to redirect
# users on the nonsecure port over to SSL (hopefully saving bookmarks)
#__
package Apache::PortCorrect; # define the package space
use strict; # pragma for clean code
use Apache::Constants qw( :response );# installed with mod_perl
sub handler {# default methodname
my($r) = _; # the request object
return OK if 443 == $r-get_server_port; # ok if already SSL
the best way to check for whether you're using SSL is by checking
$r-subprocess_env('HTTPS') rather than the port. see the archives
for why.
my $uri = https://myserver.com; # DNS literal *
. (split /\s+/, $r-the_request)[1]; # requested page
how about $r-uri instead of $r-the_request? actually, since there's
sometimes more involved in the request, like the port and query
string, the right way to change a URI scheme is really
my $uri = Apache::URI-parse($r);
$uri-scheme('https');
my $new_uri = $uri-unparse;
you can see
http://www.modperlcookbook.org/code/ch04/Cookbook/SSLStatus.pm
or recipes 5.3 and 5.4 in the cookbook for a few more examples of
Apache::URI, and 5.4 shows $r-subprocess_env('HTTPS') (with some
errata in the code in the first edition, unfortunately).
$r-custom_response(MOVED,$uri); # for re-request
return MOVED;# page moved!
you can certainly do that, but most people just use a redirect here.
so... i'd probably end up with something like
package Apache::RedirectToSSL;
use strict;
use Apache::Constants qw( OK REDIRECT );
use Apache::URI;
sub handler {
my $r = shift;
return OK if $r-subprocess_env('HTTPS');
my $uri = Apache::URI-parse($r);
$uri-scheme('https');
$r-headers_out-set(Location = $uri-unparse);
return REDIRECT;
}
1;
but that's just me :)
If someone is interested in seeing the rest of the presentation, I've
posted it at http://thesilentbard.com/ACM%20Seminar.ppt -- if you'd
care to post it online anywhere else, please let me know first, but
that's cool, too. Any corrections are welcome.
I didn't have the chance to take a look, but it's nice to see people
promoting mod_perl in as many places as possible :)
I know it isn't clean (I tried to make sure it fit on one slide and
didn't get too complicated for the topic, hence such non-portable
features as the DNS literal, etc), but suggestions are still very
welcome.
right, that's always the problem with presentations, and it usually
comes down to a decision between overwhelming your audience with
details and getting the main point across (even if that point isn't
the whole truth, best way, etc...).
good luck.
--Geoff
RE: Using Perl END{} with Apache::Registry
After doing some additional testing it appears that this problem only
occurs on my Windows machine with Apache 2.0. I tried it on my Linux
box Apache 1.3 and things worked fine. Since I am not using Windows in
a production environment I will be OK.
Thanks anyway.
-Original Message-
From: Jim Schueler [mailto:jschueler;tqis.com]
Sent: Tuesday, November 12, 2002 9:02 PM
To: Justin Luster
Subject: RE: Using Perl END{} with Apache::Registry
Pity that the module doesn't help.
I spent many hours testing END {} block behavior in Apache::Registry and
relied heavily on logged error messages. I cannot confirm your
hypothesis
that END {} blocks affect error reporting.
When testing code, reliable failures are important. If it won't fail
predictably, it won't run predictably. I recommend you double check
your assumption that It seems to be working fine.
Apache::Registry is tricky because it's there's so much uncertainty
about
the state of a process. For example, it's impossible to determine which
sequence various scripts will run in. One of the reasons I recommend my
Apache::ChildExit module is because otherwise, all of a process's
encountered END {} blocks are run at the end of a request, including END
{} blocks from other scripts and all modules that have been imported
over
the lifetime of the process. Apache::ChildExit eliminates the
possibility
that unexpected or unknown END {} blocks will impact the process state
because it ensures that END {} blocks are only run when the process
terminates.
-Jim
On Tue, 12 Nov 2002, Justin Luster wrote:
Thanks for the reply. Unfortunately I need the END block to run for
every request. I just was wondering why it altered the way error
messages were logged.
Thanks.
-Original Message-
From: Jim Schueler [mailto:jschueler;tqis.com]
Sent: Tuesday, November 12, 2002 2:41 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Using Perl END{} with Apache::Registry
Hello Justin.
I've done a little work on a similar problem due to Apache::Registry's
unusual treatment of END {} blocks. You may want to take a look at
the module I recently submitted:
http://www.cpan.org/authors/id/T/TQ/TQISJIM/ChildExit_0-1.tar.gz
-Jim
Hi, I'm trying to use the END{ } block in my Perl Scripts to do some
code clean up (making sure files are not locked) at the end of each
request. It seems to be working fine. I'm using Apache::Registry
to
run a regular Perl script. I'm having a problem with error
messages.
I have an included file that I'm requiring:
require test.pl;
Without the END { } block if the script cannot find test.pl I get a
Server error 500 and an appropriate error message in the log file.
When
I include the END{ } block I get no Server Error and no message in
the
log file. It is almost as if the END{ } is overwriting the
ModPerlRegistry error system.
Any ideas?
Thanks.
Stylistically : To inherit, or to contain
Re: Using Perl END{} with Apache::Registry
Justin Luster wrote: After doing some additional testing it appears that this problem only occurs on my Windows machine with Apache 2.0. I tried it on my Linux box Apache 1.3 and things worked fine. That's a key distinction. Please make sure you say mod_perl 2 when that's what you are using. There is actually no module called Apache::Registry in mod_perl 2, so I assumed you meant the 1.x series. - Perrin
problem with session ids
Recently I installed the Apache::Session module on my server in order
to give a kind of identity to my e-shop visitors, seems to work but
generates different session ids when I reload the bellow test cgi.
What can I do in order to have my visitor the same session id, up to
close his web browser.
#!/usr/bin/perl
use CGI;
use Apache::Session::File;
my $query = new CGI;
my %session;
my $id = undef;
$id = $query-cookie(-name=SID01);
tie %session, 'Apache::Session::File', $id,
{ Directory = /tmp/,
LockDirectory = /tmp/};
if ($id == undef) {
$cookie = $query-cookie( -name='SID01',
-value=$session{_session_id},
-expires='+1y',
-path='/session');
print $query-header(-cookie=$cookie);
print Assigned session IDbrn;
} else {
print $query-header();
print Not assigned session IDbrn;
};
$id = $session{_session_id};
print htmln;
print headtitleSession ID/title/headn;
print body bgcolor=#ffn;
print Your session ID is $idn;
print /bodyn;
print /htmln;
thank you in advance
Minas
Re: problem with session ids
Minas wrote: Recently I installed the Apache::Session module on my server in order to give a kind of identity to my e-shop visitors, seems to work but generates different session ids when I reload the bellow test cgi. What can I do in order to have my visitor the same session id, up to close his web browser. You're going to have to do some debugging to find out why your script isn't working. You use of Apache::Session::File looks okay, except that you don't handle possible errors. Check if the cookie is being set, if the files are being created in /tmp, etc. - Perrin
Cleanup question
Hello, I have a shop system wirtten in Perl which I now must switch to mod_perl bevor going live. The code is written with use strict and I think it is in biggest parts a good source. ;-) The question I have now is, that I have to switch the error handling. Until now, I display an error message to the users web browser and then die(). As I know, this is not a good idea unter mod_perl, especially because I use references on lager data structures and some objects in my code. I searched the web for a documentation about that topic and found some things wwhich are somehow confusing to me. Perhaps someone of you knows a documentation which explains who to do this properly? Thanks for your help, Jan Theofel -- Jan Theofel Fon: +49 (7 11) 48 90 83 - 0 ETES - EDV-Systemhaus GbRFax: +49 (7 11) 48 90 83 - 50 Libanonstrasse 58 A * D-70184 Stuttgart Web: http://www.etes.de __ Inflex - eMail Scanning and Protection Queries to: [EMAIL PROTECTED]
Stacking ErrorDocuments OR multilevel PerlAccessHandler
Once upon a time there was a project that required a PerlAccessHandler and form-based login. This project lived in the land of mod_perl, so it lived a happy life, with a setup something like: Location /not-protected PerlHandler Apache::Registry SetHandler perl-script Options +ExecCGI /Location Location /requireslogin PerlAccessHandler My::EnforceLogin ErrorDocument 403 /not-protected/login.pl?rm=Bounce PerlHandler Apache::Registry SetHandler perl-script Options +ExecCGI /Location (/not-protected/login.pl is a CGI::Application-based script, which is why I'm using Apache::Registry) This solution worked fine, and the project was a happy creature. Then one day the project decided to expand to include a second layer of authorization. Now users fell into three groups: No requirements, login required, and logged-in-as-confirmed user. (Any logged in user can become a confirmed user (a one time process) by going through a series of steps, held at, say, /requireslogin/confirm.pl. Thus, you must be logged in before I can check that you are confirmed, but a logged in user may or may not be a confirmed user) I, as caretaker for the innocent little (if growing) project, wanted to add a second access handler. The thought was that /requiresconfirm/ could use the same My::EnforceLogin as /requireslogin/ as well as My::EnforceConfirm. The ErrorDocument would bounce the user to /requireslogin/confirm.pl, and if they weren't logged in, it in turn would bounce them to /not-protected/login.pl I thought this a solid and clever answer, with nice modular little bits, and full code reuse. Sadly, I am not as clever as I thought (again), because a 403 on a 403 (as happens if a non-logged-in user tries to access /requiresconfirm/) doesn't bounce twice but drops to the generic handler. So now I have a few options, and I'm not sure what is the best way to go about this. I've tried using an AuthenHandler with a different ErrorDocument to handle it, but AUTH_REQUIRED began negotiations with th e browser -- undesirable. I could make my handlers do internal redirects (a new task for me). I could do external redirects. I could ask you folks if what I originally intended can work just fine with some minor magic change. OR I could just toss code reuse out and make My::BloatedandRepetativeHandler to check for both. The Cookbook and the Eagle book, so far as I've discovered, don't cover cascading errordocuments. (at least in the Auth* chapters) So I thought I'd check -- I can't be the first (or 1000th) to have this issue, how is it normally handled?
Unicode and URI escaping
Hello wise guys. heh. I'm trying to URI encode UTF-8 and it's killing URI::Escape (uri_escape) and CGI::Util (called by CGI.pm, and does _seem_ to fix itself when I put use utf8; in the main script. Darn, this is NOT the right list. I've subscribed to perl-unicode. Does Apache::Util already handle this? Danke. -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
ANNOUNCE: Bricolage 1.4.5
The Bricolage team is pleased to announce the release of Bricolage 1.4.5. This maintenance release fixes over 25 bugs in version 1.4.4 and, as a bonus, makes a few significant changes that affect how it works, to whit: * Categories are now displayed by their URIs instead of their names wherever possible. * Improved error handling by the SOAP server. Full errors will now be printed to the Apache error log, error messages sent back to the client are properly escaped, and all database transactions for a single request will be rolled back in the event of an error. Among the more important bug fixes are the following: * The Bricolage SOAP interface will no longer allow the creation of stories and media with duplicate URIs. * The burner no longer fails when it publishes an asset that's not on a desk. * SOAP now does the proper thing when deleting assets, removing them from desks and workflow only if they're on desks and in workflow. * Setting permissions on the assets in a category works again. * Stories, media, and templates created but not saved no longer disappear into the void. They are instead moved into workflow, put on a desk, and saved as soon as they were created. * The SOAP interface now properly logs events for its activities. All users of earlier versions of Bricolage are encouraged to upgrade. For a complete list of the changes, see the changes file at https://sourceforge.net/project/shownotes.php?release_id=122230. ABOUT BRICOLAGE Bricolage is a full-featured, enterprise-class content management and publishing system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete programming language support for flexibility, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. Learn more about Bricolage and download it from the Bricolage home page, http://bricolage.cc/. Enjoy! --The Bricolage Team
Re: Cleanup question
Jan Theofel wrote: Hello, I have a shop system wirtten in Perl which I now must switch to mod_perl bevor going live. The code is written with use strict and I think it is in biggest parts a good source. ;-) The question I have now is, that I have to switch the error handling. Until now, I display an error message to the users web browser and then die(). As I know, this is not a good idea unter mod_perl, especially because I use references on lager data structures and some objects in my code. I searched the web for a documentation about that topic and found some things wwhich are somehow confusing to me. Perhaps someone of you knows a documentation which explains who to do this properly? You can die() under mod_perl. See: http://perl.apache.org/docs/1.0/guide/porting.html#die___and_mod_perl Other relevant pages to read: http://perl.apache.org/docs/1.0/guide/snippets.html#Redirecting_Errors_to_the_Client_Instead_of_error_log http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Exception_Handling_for_mod_perl http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Customized___DIE___hanlder __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
