Recompiling Apache
Hello Group, I want to add the rewrite module to my apache and it would appear I have to recompile apache to do so.. Does this mean I'll need to redo mod_perl after Apache as well? RH 8 Apache 2.044 mod_perl 1.99.09 Thanks -Chris
Re: AuthDBI logoff
Todd White wrote:
if there was a means by which i could strip out the Authorization header
in the client request, this would force a 401 response from the server
which would also satisfy my specific need.
is there a means by which i can manipulate an incoming request header from
the client?
Location /foo
PerlInitHandler 'sub { shift-headers_out-unset(Authorization); 0 }'
/Location
or something similar - you get the idea :)
--Geoff
Re: [Question] Handler executing twice!?!
AHA! That's the culprit! mod_dir implements this at the fix-up stage to allow the directive in .htaccess files, hence my confusion. Thank you Stas! It all makes sense now. -Vince Stas Bekman wrote: Vince Veselosky wrote: [...] The thing that triggered it was the fact that the url was an index.pl file. When called as example.com/index.pl, everything worked as expected, but when called as example.com/, apache (or something) generated a subrequest for index.pl. NOW my question is, why does apache generate the subrequest *after* the HeaderParser phase, causing it to execute twice? This seems like a pure URI translation issue, and I would expect it to happen in the URI translation phase, *before* the HeaderParser executes at all. I'm wondering if this happens in all requests, or if it is related to Apache::Registry in the content handler. I didn't take the time to track down exactly where the subrequest originates, so I'm not sure if it is a mod_perl issue or just an apache issue. I might one day build some test cases and figure it out, but not soon. Anyone have some insight to add? Do you have mod_dir (DirectoryIndex) configured? It performs a rewrite/sub_request-redirect in the fixup stage. http://httpd.apache.org/docs/mod/mod_dir.html __ Stas Bekman JAm_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: Segmentation fault - is Error.pm the culprit?
Richard Clarke [EMAIL PROTECTED] writes: I'm using a subclass of Error.pm to throw exceptions when a DBI error happens. The SEGV only happens after I return SERVER_ERROR in response to the thrown and propogated error. I do not know whether it can be related to your problem but for me some cryptical problems disappeared when I replaced default Error.pm with the newer version from CPAN.
Fw: [Perl] CPAN was hacked !
- Original Message - From: Gabor Szabo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 31, 2003 11:41 PM Subject: [Perl] CPAN was hacked ! by Matt's Script Archive, Inc. april fools!
RE: AuthDBI logoff
Hi Todd, Trying to logoff using Basic Auth is becoming something of a faq... if there was a means by which i could strip out the Authorization header in the client request, this would force a 401 response from the server which would also satisfy my specific need. I doubt if this will work. I suspect you want to strip this out when the user does his logout-request (ie. a request for .../logout.html). If you do this, the browser should present a popup-box to the user, which he most probably would cancel. However, most browsers seem to recollect their authorisation information they used before. Thus, as soon as the user gets to a page that requests a login, the browser tries with the user credentials that were kept and a popup is never shown. As someone already suggested: use a Cookie based algorithem. The cookie gives you the opportunity to follow the status of the user and effectively log him out. Another approach I once saw was the use of a dedicated realm for that user. In stead of using a fixed realm (ie. security domain) the domain is on a per session basis. You should still fix the session someway (using the uri or a cookie), but you can still stick with the 'Basic Auth' mechanism. Hope this helps. --Frank
Off Topic but curious
If I bought a domain name with perl in it to build a perl script site, would I be infringing on any perl trademark or copyrights. Would it be ok or could I be told I couldn't use the domain. Thanks John Michael
Re: Recompiling Apache
Chris Faust wrote: Hello Group, I want to add the rewrite module to my apache and it would appear I have to recompile apache to do so.. Does this mean I'll need to redo mod_perl after Apache as well? RH 8 Apache 2.044 mod_perl 1.99.09 If it's a DSO module and you just add another module in without changing the core you don't need to recompile DSO. I believe you don't even need to recompile Apache itself, if mod_rewrite can be compiled as DSO, but I haven't tried that. __ 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: Off Topic but curious
John Michael wrote: If I bought a domain name with perl in it to build a perl script site, would I be infringing on any perl trademark or copyrights. Would it be ok or could I be told I couldn't use the domain. John, Please repost the question to the perl advocacy list. ([EMAIL PROTECTED]). In the future please refer to http://lists.perl.org to find an appropriate list to post non-mod_perl perl-related questions. Thank you. __ 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
cookie setting/retieval
I'm currently in the process of writing a wrapper
for a site using Apache::Session and mod_perl. I was having great success
using the following code to either validate a cookie which was already present
or set a new cookie if necessary:
my $r =
Apache-request; my $cookie =
$r-header_in('Cookie'); my
$cgi = new CGI;
$cookie
=~ s/SESSION_ID=(\w*)/$1/;
# create the
session from the cookie or create a new one
my
%session; tie %session,
'Apache::Session::File', $cookie,
{
Directory =
'/tmp/sessions', };
my
$session_cookie =
"SESSION_ID=$session{_session_id};";
$r-header_out("Set-Cookie" = $session_cookie);
Now...this works like a charm, passing the cookie
and reading the sessionas long as all of the pages are on the same level of
the tree...i.e. :
http://www.yoursite.com/perl/hithere.cgi
http://www.yoursite.com/perl/ilovecookies.cgi
http://www.yoursite.com/perl/monkey.cgi
Howeveras soon as you move to anything below
that:
http://www.yoursite.com/perl/cookies/bananna.cgi
http://www.yoursite.com/perl/cookies/arenolongercool.cgi
I receive the following error (from the
error_log):
"Died at
/usr/local/lib/perl5/site_perl/5.8.0/Apache/Session/Generate/MD5.pm line
40"
By using Mozilla's cookie manager I see that the
path attribute of the cookie set in the browser is changed from:
"/perl/"
to:
"/perl/cookies/"
...but I can't seem to figure out why
Apache::Session isn't using the combination of the SESSION_ID and the directory
stated in the tie() (/tmp/sessions) to retrieve the cookie...the SESSION_ID
hasn't changed?
Thnx much!
~j
Re: cookie setting/retieval
On Mon, 31 Mar 2003 18:11:21 -0600 Jason Jolly [EMAIL PROTECTED] wrote: I'm currently in the process of writing a wrapper for a site using Apache::Session and mod_perl. I was having great success using the following code to either validate a cookie which was already present or set a new cookie if necessary: Hi Jason, don't reinvent the wheel! ;-) There's already an Apache::Session wrapper on CPAN called Apache::SessionManager. Apache::SessionManager is a mod_perl module that helps session management of a web application. It creates a session object and makes it available to all other handlers transparenlty. Also session expiration policies are available. http://cpan.org/modules/by-module/Apache/Apache-SessionManager-0.04.tar.gz See perldoc Apache::SessionManager for more infos. by - Enrico
