Re: [MP2] Apache::Reload date bug
On Wed, 26 Feb 2003 22:30:51 -0600 (CST), Randy Kobes wrote: On Thu, 27 Feb 2003, Ron Savage wrote: On Wed, 26 Feb 2003 09:23:39 +1100, Stas Bekman wrote: HI Randy The mod_perl 2 ppm package (for ActivePerl 8xx) at http://theoryx5.uwinnipeg.ca/ppms/ is updated periodically with a cvs build - as of tonight, it's current. Thanx. Now my dual-booter at work is working, I hope to try this tomorrow. It's 8pm here now. -- Cheers Ron Savage, [EMAIL PROTECTED] on 27/02/2003 http://savage.net.au/index.html
Re: Scripts and HTML docs in the same directory (+ modperl newbieexperiences)
Stas Bekman wrote: Mark James wrote: 1. In http://perl.apache.org/docs/1.0/guide/getwet.html , use of x.x.x for both the Apache and mod_perl version numbers made me think that the version numbers had to be matched. Maybe y.y.y should be used for one. Please get used to x.x.x meaning any. Otherwise we would need to remember to use z.z.z. for php plugs in and f.f.f. when openssl is added, etc... hope you get the idea. When they're discussed in the same sentence, and when building one requires linking to the installation or source directory of the other, I think a different variable helps. 2. In the configuration section of the 2.0 docs (http://perl.apache.org/docs/2.0/user/intro/start_fast.html#toc_Configuration) it neglects to state the need to issue a directive for the mod_perl handler one is going to use, e.g. PerlModule ModPerl::Registry, though it is covered in the configuration docs (including the startup-file option). you mean preloading the module? That's not necessarily in mp2, though advisable for performance reasons. In mp2, you can say: PerlResponseHandler ModPerl::Registry without: PerlModule ModPerl::Registry Well I just commented out use ModPerl::Registry () in my startup script and it still worked. But earlier I had found that adding PerlModule ModPerl::Registry the http.conf was the key to getting rid of the rash of error messages I was getting on server start-up. It must have been a manifestation of some other problem, perhaps with mod_perl-1.99_08 (now using the CVS version to fix a missing OPEN in Apache::RequestRec, and to avoid the failed perlio tests), or with an older CGI.pm (found out late that CGI=2.89 was needed). you can also use the syntactic sugar to preload modules, by simply stating at the beginning of your mod_perl configuration 'PerlOptions +Autoload'. See http://perl.apache.org/docs/2.0/user/config/config.html#C_AutoLoad_ or using + before the handler name: PerlResponseHandler +ModPerl::Registry OK, so 2.0 is not like 1.0 where PerlModule acts like use() (http://perl.apache.org/docs/1.0/guide/config.html#PerlModule_and_PerlRequire_Directives), but is more like @INC manipulation; and these handler autoload directives are an alternative to use-ing them in a start-up script. My start-up script is very long because it calls use for just about every package in an extensive package set. I suppose an import function could be created in a master package of package suite that when called require-ed all the associated packages, so that mod_perl can have the entire suite pre-loaded prior to forking through just one line in the start-up script. Thank you Stas for your prompt help. Mark
Authorization question
Hi List, In theory Authentication / Authorization handlers are very cool, because the application underneath it doesn't need to know the logic of it, and as long as you design web applications with nice, RESTful, sensible URIs it would all work beautifully. BUT, I cannot figure out how to 'ask' apache wether a request would succeed or not. I'm wondering wether there would be a way to do: my $ok = $r-would_be_authorized ($uri); # or my $ok = $r-would_be_authorized ($uri, 'GET'); # or my $ok = $r-would_be_authorized ($uri, 'POST', $fh); This would be handy because for example in your web application you might want certain controls or links to be replaced by proper messages rather than directing the user to a location that he/she doesn't have access to. If I missed something obvious please point out a URI so that I can RTFM! All ideas appreciated! Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
mod_perl Developer's Cookbook
A question about mod_perl Developer's Cookbook by Young, Lindner and Kobes: Is this book still relevant and worth buying for mod_perl2 ? (I'm about to dive into web development using Apache/mod_perl and intend to go straight to mp2). Thanks, NG
Re: Authorization question
I've never had any reason to do this so there might be a shortcut but I
think something along the lines of the following should work (As long as
your access/auth handler doesnt make use of $r-is_intial_req())
use Apache::Constants (:common);
my $subr = $r-lookup_uri('/new/request/?foo=bar');
my $status = $subr-status;
my $ok = $status==AUTH_REQUIRED ? 0:1;
Ric.
- Original Message -
From: Jean-Michel Hiver [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, February 27, 2003 10:42 AM
Subject: Authorization question
Hi List,
In theory Authentication / Authorization handlers are very cool, because
the application underneath it doesn't need to know the logic of it, and
as long as you design web applications with nice, RESTful, sensible URIs
it would all work beautifully.
BUT, I cannot figure out how to 'ask' apache wether a request would
succeed or not. I'm wondering wether there would be a way to do:
my $ok = $r-would_be_authorized ($uri);
# or
my $ok = $r-would_be_authorized ($uri, 'GET');
# or
my $ok = $r-would_be_authorized ($uri, 'POST', $fh);
This would be handy because for example in your web application you
might want certain controls or links to be replaced by proper messages
rather than directing the user to a location that he/she doesn't have
access to.
If I missed something obvious please point out a URI so that I can RTFM!
All ideas appreciated!
Cheers,
--
Building a better web - http://www.mkdoc.com/
-
Jean-Michel Hiver
[EMAIL PROTECTED] - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
Re: mod_perl Developer's Cookbook
On 27 Feb 2003 at 11:35, Gazi, Nasser (London) wrote: A question about mod_perl Developer's Cookbook by Young, Lindner and Kobes: Is this book still relevant and worth buying for mod_perl2 ? (I'm about to dive into web development using Apache/mod_perl and intend to go straight to mp2). Thanks, NG The underlying principles remain the same. And I happen to know that Geoff Young is writing some articles (for perl.com?) that highlight the differences between the two systems using examples from the Cookbook. -Chris
Re: Authorization question
On Thu 27-Feb-2003 at 11:39:32AM -, Richard Clarke wrote:
I've never had any reason to do this so there might be a shortcut but I
think something along the lines of the following should work (As long as
your access/auth handler doesnt make use of $r-is_intial_req())
use Apache::Constants (:common);
my $subr = $r-lookup_uri('/new/request/?foo=bar');
my $status = $subr-status;
my $ok = $status==AUTH_REQUIRED ? 0:1;
Wow! Thanks for the tip :)
Is there a way to tell Apache::SubRequest that you're doing a HEAD / GET
/ POST / PUT / etc? Authorization handlers might behave differently
depending on the HTTP method being used.
Cheers,
--
Building a better web - http://www.mkdoc.com/
-
Jean-Michel Hiver
[EMAIL PROTECTED] - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
RE: make errors with mod_perl-1.99_08 on aix 4.3.3
Thanks for the quick response, additional information as requested is below.
Priest, Darryl - BALTO wrote:
I'm getting the error below for every cc in the make:
/usr/local/perl5.8.0/lib/5.8.0/aix/CORE/config.h, line 41.9: 1506-236
(W)
Macro name __attribute__ has been redefined.
/usr/local/perl5.8.0/lib/5.8.0/aix/CORE/config.h, line 41.9: 1506-358
(I)
__attribute__ is defined on line 28 of /usr/local/apache/include/apr.h.
I'll take this issue to the apr/p5p lists, but this is non-fatal.
But the make sails along until:
cc -I/tmp/mod_perl-1.99_08/src/modules/perl
-I/tmp/mod_perl-1.99_08/xs -I/usr/local/apache/include -D_ALL_SOURCE
-D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=16384 -qnoansialias
-DUSE_NATIVE_DLOPEN -I/usr/local/perl5.8.0/lib/5.8.0/aix/CORE -DMOD_PERL
-O -c modperl_sys.c mv modperl_sys.o modperl_sys.lo
modperl_largefiles.h, line 15.9: 1506-199 (S) #define directive requires
a
macro name.
modperl_largefiles.h, line 17.9: 1506-199 (S) #define directive requires
a
macro name.
[...]
Is it just a coincidence that perl has USE_LARGE_FILES on and the file
that
make finally fails on is modperl_largefiles.h ?
Can you please post your src/modules/perl/modperl_largefiles.h and the
output of:
#ifndef MODPERL_LARGEFILES_H
#define MODPERL_LARGEFILES_H
/*
* *** WARNING **
* This file generated by ModPerl::Code/0.01
* Any changes made here will be lost
* ***
* 01: lib/ModPerl/Code.pm:648
* 02: lib/ModPerl/Code.pm:674
* 03: Makefile.PL:209
* 04: Makefile.PL:91
*/
#define -q32
#define _LARGE_FILES
#define -qlonglong
#endif /* MODPERL_LARGEFILES_H */
% perl -MConfig -e 'print $Config{ccflags_uselargefiles}'
-q32 -D_LARGE_FILES -qlonglong
__
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
The information contained in this communication may be confidential, is
intended only for the use of the recipient named above, and may be legally
privileged. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, or copying of
this communication, or any of its contents, is strictly prohibited. If you
have received this communication in error, please re-send this communication
to the sender and delete the original message and any copy of it from your
computer system.
Thank you.
For more information please visit us at http://www.piperrudnick.com
Re: mod_perl Developer's Cookbook
[EMAIL PROTECTED] wrote: On 27 Feb 2003 at 11:35, Gazi, Nasser (London) wrote: A question about mod_perl Developer's Cookbook by Young, Lindner and Kobes: Is this book still relevant and worth buying for mod_perl2 ? (I'm about to dive into web development using Apache/mod_perl and intend to go straight to mp2). you can read our official statement on this at our website http://www.modperlcookbook.org/modperl2.html the thing I'm finding about mod_perl 2.0 is that it exposes much more of the raw Apache API than mod_perl 1.0 did, so you really need to think more about what Apache is doing under the hood than you did before. in this sense, the Cookbook should help, since that's the attitude we were taking there all along - you'll understand mod_perl better if you understand Apache. whether you're talking about Apache 1.3 or 2.0, most of the underlying Apache fundamentals are the same (after all, it's still HTTP). however, the Cookbook does not have any mod_perl 2.0 specific examples. you'll have to go to the docs for that. http://perl.apache.org/docs/2.0/ Thanks, NG The underlying principles remain the same. And I happen to know that Geoff Young is writing some articles (for perl.com?) that highlight the differences between the two systems using examples from the Cookbook. yes, you will probably see some mod_perl 2.0 stuff on perl.com over the next few months (perhaps just weeks), but covering all the differences will be a slow process (at best). --Geoff
Apache is exiting....
Hi all
Here's a stripped-down version of a script I use:
===
use Image::Magick;
my $image=Image::Magick-new(size='75x75');
$image-Read('null:white');
my @x =
$image-QueryFontMetrics(font='@/usr/X11R6/lib/X11/fonts/ttf/Ritalin.ttf',text='X',
pointsize=12);
===
If the font can't be found, I get this in my error log:
===
Exception 415: UnableToReadFont (@/usr/X11R6/lib/X11/fonts/ttf/Ritalin.ttf) at
/path/to/script line 584.
[Thu Feb 27 15:17:07 2003] [alert] Child 8329 returned a Fatal error...
Apache is exiting!
===
Even using an Error.pm try/catch block makes no difference. Pretend
for a moment that you have no specific knowledge of the library which
causes this problem: is there any black box approach to stopping some
library's complaints from shutting down my web server?
Thanks
Paolo
Re: Authorization question
Jean-Michel Hiver wrote:
On Thu 27-Feb-2003 at 11:39:32AM -, Richard Clarke wrote:
I've never had any reason to do this so there might be a shortcut but I
think something along the lines of the following should work (As long as
your access/auth handler doesnt make use of $r-is_intial_req())
I've decided that the
return DECLINED if $r-is_inital_req;
bit is a bad idea. after a few hours debugging an authorization
application, I realized that this does nothing but cause problems - if you
DECLINE a subrequest then it's picked up by mod_auth which, if you're not
configured for flat file auth (in addition to your custom auth), mod_auth
will return AUTH_REQUIRED (or worse).
you may want to
return OK if $r-is_inital_req;
but DECLINED is almost certainly a bad idea.
use Apache::Constants (:common);
my $subr = $r-lookup_uri('/new/request/?foo=bar');
my $status = $subr-status;
my $ok = $status==AUTH_REQUIRED ? 0:1;
I'd change that to
my $ok = $status == HTTP_OK ? 1 : 0;
since there are lots of other things that can be thrown other than
AUTH_REQUIRED - for instance FORBIDDEN from an access handler.
we talk about this in Recipe 3.15 in the Cookbook (which came up yesterday,
so see the archives for where you can find it for free).
Wow! Thanks for the tip :)
Is there a way to tell Apache::SubRequest that you're doing a HEAD / GET
/ POST / PUT / etc? Authorization handlers might behave differently
depending on the HTTP method being used.
unfortunately, no - GET is hardcoded in Apache:
API_EXPORT(request_rec *) ap_sub_req_lookup_uri(const char *new_file,
const request_rec *r)
{
return ap_sub_req_method_uri(GET, new_file, r);
}
and by the time you get the subrequest object back, it's too late to call
$sub-method('POST'). of course, theoretically GET and HEAD should be
equivalent :) but I see your point. I guess there's no way around that in
this case.
--Geoff
Re: Apache is exiting....
HI Paolo,
Can you use an eval {}; block?
Or maybe solve the bug. Is the @ symbol meant to appear in the
font path?
NIge
Hi all
Here's a stripped-down version of a script I use:
===
use Image::Magick;
my $image=Image::Magick-new(size='75x75');
$image-Read('null:white');
my @x =
$image-QueryFontMetrics(font='@/usr/X11R6/lib/X11/fonts/ttf/Ritalin.ttf',text='X',
pointsize=12);
===
If the font can't be found, I get this in my error log:
===
Exception 415: UnableToReadFont (@/usr/X11R6/lib/X11/fonts/ttf/Ritalin.ttf) at
/path/to/script line 584.
[Thu Feb 27 15:17:07 2003] [alert] Child 8329 returned a Fatal error...
Apache is exiting!
===
Even using an Error.pm try/catch block makes no difference. Pretend
for a moment that you have no specific knowledge of the library which
causes this problem: is there any black box approach to stopping some
library's complaints from shutting down my web server?
Thanks
Paolo
--
Nigel Hamilton
Turbo10 Metasearch Engine
email: [EMAIL PROTECTED]
tel:+44 (0) 207 987 5460
fax:+44 (0) 207 987 5468
http://turbo10.com Search Deeper. Browse Faster.
RE: Apache is exiting....
Hey Paolo,
Did you try to add some die statements to see if it made any difference, so
something like:
use Image::Magick;
my $image=Image::Magick-new(size='75x75');
$image-Read('null:white');
die display_error(Read Error Error: Image: null:white $image \n) if
($image);
my @x = $image-QueryFontMetrics
font='@/usr/X11R6/lib/X11/fonts/ttf/Ritalin.ttf',text='X', pointsize=12);
die display_error(ImFont Query Error: @x $image) if ($image);
Works for me, then I just have a sub called display_error that prints the
message and error out in a browser, but you could make that anything you
want.
-Chris
-Original Message-
From: Paolo Campanella [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 27, 2003 8:43 AM
To: [EMAIL PROTECTED]
Subject: Apache is exiting
Hi all
Here's a stripped-down version of a script I use:
===
use Image::Magick;
my $image=Image::Magick-new(size='75x75');
$image-Read('null:white');
my @x =
$image-QueryFontMetrics(font='@/usr/X11R6/lib/X11/fonts/ttf/Rit
alin.ttf',text='X', pointsize=12);
===
If the font can't be found, I get this in my error log:
===
Exception 415: UnableToReadFont
(@/usr/X11R6/lib/X11/fonts/ttf/Ritalin.ttf) at /path/to/script line 584.
[Thu Feb 27 15:17:07 2003] [alert] Child 8329 returned a Fatal error...
Apache is exiting!
===
Even using an Error.pm try/catch block makes no difference. Pretend
for a moment that you have no specific knowledge of the library which
causes this problem: is there any black box approach to stopping some
library's complaints from shutting down my web server?
Thanks
Paolo
Re: Apache is exiting....
Hi Nigel
On Thu, 27 Feb 2003 14:16:45 + (GMT)
Nigel Hamilton [EMAIL PROTECTED] wrote:
HI Paolo,
Can you use an eval {}; block?
No, doesn't work. This is also (AFAIK) how Error.pm works.
Or maybe solve the bug. Is the @ symbol meant to appear in the
font path?
Solving the bug is not the problem - I can simply check that the
font exists first. My problem is that I hate having something running
which could kill my web server at any time, perhaps if it is passed
some other argument which it does not like - I can't anticipate
every possible way that it could die, which is why I want a black
box solution to running it safely.
Bye
Paolo
Re: Apache is exiting....
Hi Chris
On Thu, 27 Feb 2003 09:33:07 -0500
Chris Faust [EMAIL PROTECTED] wrote:
Hey Paolo,
Did you try to add some die statements to see if it made any difference,
so something like:
use Image::Magick;
my $image=Image::Magick-new(size='75x75');
$image-Read('null:white');
die display_error(Read Error Error: Image: null:white $image
\n) if
($image);
my @x = $image-QueryFontMetrics
font='@/usr/X11R6/lib/X11/fonts/ttf/Ritalin.ttf',text='X',
pointsize=12);
die display_error(ImFont Query Error: @x $image) if ($image);
Works for me, then I just have a sub called display_error that prints
the message and error out in a browser, but you could make that anything
you want.
In this example, it would croak (let's not call it die, because it
doesn't) on the $image-QueryFontMetrics() call, before it reaches
the die statement. Yes, I have made sure exactly where it dies. I don't
think one can do much better than this:
===
use Image::Magick;
use Error qw (:try);
my $image=Image::Magick-new(size='75x75');
$image-Read('null:white');
try {
my @x =
$image-QueryFontMetrics(font='@/usr/X11R6/lib/X11/fonts/ttf/Ritalin.ttf',text='X',
pointsize=12);
die Got past QueryFontMetrics();
}
catch Error with {
warn trapped an exception;
};
warn Completed;
===
This gives the same output as the original post:
Exception 415: UnableToReadFont (@/usr/X11R6/lib/X11/fonts/ttf/Ritalin.ttf) at
./xxx line 12.
Thanks
Paolo
Re: Apache is exiting....
On Thu, 2003-02-27 at 08:42, Paolo Campanella wrote: Pretend for a moment that you have no specific knowledge of the library which causes this problem: is there any black box approach to stopping some library's complaints from shutting down my web server? No. The library is executing C code in the web server process. There is nothing stopping it from simply saying exit(), or even segfaulting and killing that process. Note that it's just one process though, not the whole server. Not a big deal. You can sort of work around this by using a reverse proxy to separate your mod_perl server from your front-end web server. This gives you a scenario similar to CGI, and it's what FastCGI does, and Microsoft and other commercial vendors make a big fuss about doing this. However, the only advantage to it is that you can return a prettier error message to the user. It won't prevent anyone from exiting a process. - Perrin
RE: [mp1] Help with Apache::MP3
I've resolved this problem, at least to a degree which satisfies me. I built apache-1.3.27 and mod_perl-1.27 together following the INSTALL.simple instructions from the mod_perl source but adding EVERYTHING=1 when running Makefile.PL. This makes Apache::MP3 work on a Red Hat 7.3 system with perl 5.8.0 added and also on Red Hat 8.0 (which has perl 5.8.0 included) but only if mod_perl-1.99 was *not* a selected package. On an 8.0 system with mod_perl-1.99 present, /usr/local/apache/bin/apachectl configtest still causes a segmentation fault. Many thanks to Ged Haywood for plenty of support off-list. -- From: Wilcox, Curtis Sent: Thursday, February 20, 2003 1:31 PM To: [EMAIL PROTECTED] Subject: [mp1] Help with Apache::MP3 Actually I run into the problem before I get to the Apache::MP3 part but running Apache::MP3 is the ultimate goal. The distro I'm trying is Red Hat 8.0 which includes apache 2.x.x, mod_perl 1.99 and perl 5.8.0 but Apache::MP3 requires the 1.0 mod_perl API. I tried to use the Apache::compat module as suggested by the Namp! web site http://namp.sourceforge.net/ to make it compatible with the 1.0 API but that didn't seem to work. I get failed to resolve handler `Apache::MP3' in the httpd/error_log when trying to load the directory Apache::MP3 is set to handle. I would just as soon not use Apache 2 anyway so I tried installing apache-1.3.27 and mod_perl-1.27, following the instructions in INSTALL.simple, included in the mod_perl source. Unfortunately when I add the following to httpd.conf, the apachectl configtest segfaults: Location /Songs SetHandler perl-script PerlHandler Apache::MP3 /Location /usr/local/apache/bin/apachectl configtest /usr/local/apache/bin/apachectl: line 171: 999 Segmentation fault $HTTPD -t The segfault is not caused by the PerlHandler, it still happens if there's only the SetHandler line. I have successfully run Apache::MP3 on a Red Hat 7.3 configuration but I'd like to use Red Hat 8.0 because of a number of the updates included the current version of perl. This page compares the versions of the relevant components (as far as I can tell) and the output of httpd -V, httpd -l, and perl -V on the Red Hat 8.0 and Red Hat 7.3 machines. http://stream.esm.rochester.edu/trouble/stream80_vs_stream73.html I should also mention that on Red Hat 8.0 if I do not select the Web Server set of packages, Apache 2.0 is still installed but mod-perl 1.99 is not. I don't *think* that should make a difference but I can't tell. Does anyone know a specific cause of this problem? What's my best option, do a different compile of apache mod_perl? Could I upgrade Red Hat 7.3 to 8.0 and retain my apache configuration but end up with perl 5.8.0? -- Curtis Wilcox Eastman School of Music [EMAIL PROTECTED]
Re: Apache is exiting....
On 27 Feb 2003 10:33:21 -0500 Perrin Harkins [EMAIL PROTECTED] wrote: On Thu, 2003-02-27 at 08:42, Paolo Campanella wrote: Pretend for a moment that you have no specific knowledge of the library which causes this problem: is there any black box approach to stopping some library's complaints from shutting down my web server? No. The library is executing C code in the web server process. There is nothing stopping it from simply saying exit(), or even segfaulting and killing that process. Note that it's just one process though, not the whole server. Not a big deal. Thanks - that makes sense. I'll just live with making sure that it doesn't happen. Just one thing though: when the process dies, it really does take the main server process down with it: [Thu Feb 27 17:55:04 2003] [alert] Child 8592 returned a Fatal error... Apache is exiting! The remaining child processes then hang around, useful until they receive a similar, deadly request. I'd be interested to know why the main Apache process shuts down. Thanks
Re: Authorization question
On Thu, 27 Feb 2003, Jean-Michel Hiver wrote:
Hi List,
In theory Authentication / Authorization handlers are very cool, because
the application underneath it doesn't need to know the logic of it, and
as long as you design web applications with nice, RESTful, sensible URIs
it would all work beautifully.
BUT, I cannot figure out how to 'ask' apache wether a request would
succeed or not. I'm wondering wether there would be a way to do:
my $ok = $r-would_be_authorized ($uri);
# or
my $ok = $r-would_be_authorized ($uri, 'GET');
# or
my $ok = $r-would_be_authorized ($uri, 'POST', $fh);
This would be handy because for example in your web application you
might want certain controls or links to be replaced by proper messages
rather than directing the user to a location that he/she doesn't have
access to.
If I missed something obvious please point out a URI so that I can RTFM!
All ideas appreciated!
Salut,
I think this may be solved by architecture. If you have an Authz layer
maybe it needs to be called sooner than right when you need it.
I have a Session-based auth system. When the user successfully
authenticates the Auth handler does a lookup in a db where we store all
users' authz information. The db has an access level for each user for
each widget in the application. These are all loaded into a hashref and
stored in the serverside session. An encrypted cookie has the key to the
session.
All of this is tied into the UI such that the user's authz level
determines the content they see. Data such as '$student-first_name' are
displayed by a UI handler according to perms; the UI's methods can write
out either:
First Name: $val or
First Name: input type='text' name ='first_name' val='$val' or
whatever, depending on the user's perms.
HTH,
- nick
--
Nick Tonkin {|8^)
Re: mod_perl Developer's Cookbook
On Thu, 27 Feb 2003, Gazi, Nasser (London) wrote:
A question about mod_perl Developer's Cookbook by Young, Lindner and
Kobes:
Is this book still relevant and worth buying for mod_perl2 ?
Yes, but there are parts that are different for mp2, and other things that
are omitted. Remember: mp2 is not finished!
(I'm about to
dive into web development using Apache/mod_perl and intend to go straight to
mp2).
I would spend a little time on a dev server playing with mp1. There is a
lot more documentation, support and community wisdom available there. By
the time you get up to speed mp2 might be closer to its final version ...
- nick
--
Nick Tonkin {|8^)
Re: Authorization question
On Thu, 27 Feb 2003, Geoffrey Young wrote:
I've decided that the
return DECLINED if $r-is_inital_req;
bit is a bad idea. after a few hours debugging an authorization
application, I realized that this does nothing but cause problems - if you
DECLINE a subrequest then it's picked up by mod_auth which, if you're not
configured for flat file auth (in addition to your custom auth), mod_auth
will return AUTH_REQUIRED (or worse).
you may want to
return OK if $r-is_inital_req;
but DECLINED is almost certainly a bad idea.
What was the idea behind
return DECLINED if $r-is_inital_req;
in auth handlers in the first place?
- nick
--
Nick Tonkin {|8^)
Re: Authorization question
but DECLINED is almost certainly a bad idea. What was the idea behind return DECLINED if $r-is_inital_req; in auth handlers in the first place? I think it stems from the Eagle book, thus from Doug, but I'm not sure - I can't remember exactly. it was probably an attempt to reduce overhead for subrequests when authentication is expensive (say, a DB query) and you don't really care about whether lookups are authenticated or not. I tried to word it carefully in the book, saying using it depends on what you want to do in your application. clearly if you want to depend on proper authentication for lookups, then you don't want to use is_initial_req() logic at all. it wasn't until after it was too late that I realized DECLINED is problematic. my own particular problem with it was with the subrequests that mod_dir makes - IIRC, on a protected directory returning DECLINED on the subrequest really mucks things up. HTH --Geoff
Re: Apache is exiting....
On Thu, 2003-02-27 at 11:06, Paolo Campanella wrote: Just one thing though: when the process dies, it really does take the main server process down with it: [Thu Feb 27 17:55:04 2003] [alert] Child 8592 returned a Fatal error... Apache is exiting! Are you certain? Have you actually checked to see if the main server process PID is still running? If it crashes the parent process, that's bad. (You are running prefork MPM, aren't you?) - Perrin
Re: Authorization question
I think this may be solved by architecture. If you have an Authz layer maybe it needs to be called sooner than right when you need it. I have a Session-based auth system. When the user successfully authenticates the Auth handler does a lookup in a db where we store all users' authz information. The db has an access level for each user for each widget in the application. These are all loaded into a hashref and stored in the serverside session. An encrypted cookie has the key to the session. Yes, but you're then making the authorization layer inseparable from your applicative layer, and hence you loose the interest of using separate handlers. I think it would be much nicer to write webapps on which you can plug any authorization / authentication handler chain and maintain those things as separate as possible. Then if your application uses the REST paradigm, all access control can be done using URIs, which is very neat. Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: Authorization question
On Thu, 27 Feb 2003, Jean-Michel Hiver wrote:
I think this may be solved by architecture. If you have an Authz layer
maybe it needs to be called sooner than right when you need it.
I have a Session-based auth system. When the user successfully
authenticates the Auth handler does a lookup in a db where we store all
users' authz information. The db has an access level for each user for
each widget in the application. These are all loaded into a hashref and
stored in the serverside session. An encrypted cookie has the key to the
session.
Yes, but you're then making the authorization layer inseparable from
your applicative layer, and hence you loose the interest of using
separate handlers.
True. For the type of application I deal with, where authorization levels
and security are paramount, this is not a bad thing. And really, in my
system, the UI modules only need to know the user's authz level (0-4) to
produce content ... they do not care how the authz level was generated.
- nick
--
Nick Tonkin {|8^)
Problem headers_out
Hi all
Why i have problem?
$cookie1 = new CGI::Cookie(
-name = 'sessid', -value = $session-id());
$r-headers_out-{'Set-Cookie'} = $cookie1;
OR
$c-headers_out-{'Set-Cookie'} = aaasdfhajsd fjhasdhfjkajkdf;
[Thu Feb 27 14:42:34 2003] [warn] pid file
/usr/local/apache-2.0/logs/httpd.pid overwritten -- Unclean shutdown of
previous Apache run?
[Thu Feb 27 14:42:34 2003] [notice] Apache/2.0.44 (Unix)
mod_perl/1.99_09-dev Perl/v5.8.0 configured -- resuming normal operations
Use of uninitialized value (#1)
(W uninitialized) An undefined value was used as if it were already
defined. It was interpreted as a or a 0, but maybe it was a mistake.
To suppress this warning assign a defined value to your variables.
To help you figure out what was undefined, perl tells you what operation
you used the undefined value in. Note, however, that perl optimizes
your
program and the operation displayed in the warning may not necessarily
appear literally in your program. For example, that $foo is
usually optimized into that . $foo, and the warning will refer to
the concatenation (.) operator, even though there is no . in your
program.
[Thu Feb 27 14:42:40 2003] [error] [client 127.0.0.1] Can't locate
object method STORE via package APR::Table at
/export/eShop/lib/eShop/Web/Shop/index.pm line 30.
if i remove $r-headers_out-{'Set-Cookie'} = $cookie1;
i dont have proble :/
i using last cvs version and httpd-2.0.44
thanks
nattis
Re: Preloading DBI crashes Apache
Dan Brosemer wrote: Here's the thread to date: http://marc.theaimsgroup.com/?l=apache-modperlm=104586287823510w=2 On Sun, Feb 23, 2003 at 10:27:22AM -0500, Dan Brosemer wrote: On Sun, Feb 23, 2003 at 04:35:39AM -0800, Ask Bjoern Hansen wrote: Hi. I'm new here, and hoping someone can help me. I've installed the latest -current version of OpenBSD, and loaded mod_perl as a DSO. That gets me Apache 1.3.27, Perl 5.8.0, and mod_perl 1.27. The plot thickens. Loading mod_perl statically gets rid of this problem. Even with otherwise-identical configure arguments. Yet, the DSO mod_perl works fine except when I preload DBI. I'm _quite_ confused. I'd really like the DSO method to work, as then I wouldn't have to modify the OpenBSD source tree (any more than I normally do, anyway). Does anyone have suggestions? This sounds kind of similar to some problems I had on Debian. Try a groups.google.com search for author of 'Keith G. Murphy' and subject of Memory leak on reload when the 'Pg' driver is preloaded or even Apache segfaulting upon perl module load. I gave up on it quite some time ago and started using the statically linked mod_perl.
Re: Problem headers_out
Udlei Nattis wrote:
Hi all
Why i have problem?
$cookie1 = new CGI::Cookie(
-name = 'sessid', -value = $session-id());
$r-headers_out-{'Set-Cookie'} = $cookie1;
[snip]
Can't locate
object method STORE via package APR::Table at
/export/eShop/lib/eShop/Web/Shop/index.pm line 30.
if i remove $r-headers_out-{'Set-Cookie'} = $cookie1;
you need to
use APR::Table;
in your script.
HTH
--Geoff
Re: Authorization question
Jean-Michel Hiver wrote: Yes, but you're then making the authorization layer inseparable from your applicative layer, and hence you loose the interest of using separate handlers. It's pretty hard to truly separate these things. Nobody wants to use basic auth, which means there is a need for forms and handlers. Then you have to keep that information in either cookies or URLs, and there is usually a need to talk to an external data database with a site-specific schema. The result is that plug and play auth schemes only work (unmodified) for the simplest sites. - Perrin
Re: Authorization question
On Thu, 27 Feb 2003, Perrin Harkins wrote: Jean-Michel Hiver wrote: Yes, but you're then making the authorization layer inseparable from your applicative layer, and hence you loose the interest of using separate handlers. It's pretty hard to truly separate these things. Nobody wants to use basic auth, which means there is a need for forms and handlers. Then you have to keep that information in either cookies or URLs, and there is usually a need to talk to an external data database with a site-specific schema. The result is that plug and play auth schemes only work (unmodified) for the simplest sites. Anyone using PubCookie? http://www.washington.edu/pubcookie/ -- Bill Moseley [EMAIL PROTECTED]
Re: Authorization question
It's pretty hard to truly separate these things. Nobody wants to use basic auth, which means there is a need for forms and handlers. How do you mean, 'nobody'? Users certainly don't mind! Then you have to keep that information in either cookies or URLs, and there is usually a need to talk to an external data database with a site-specific schema. I admit that it's hard to get away without cookies and URI encoding schemes, but not impossible. There's a lot of tricks that you can do with path_info... For example, http://www.example.com/some/address/hello.txt,do_something This URL is easy to protect / authorize using LocationMatch directives. Basically I think you can use these simple schemes in complex applications if you're careful about your URIs. But it's true that it can be a real mindf*ck :) Basically each state of your application needs a different URI... However I find it well worth it, the promess of a truly modular, standard, pluggable authorization system is seducing, and also very 'marketable' I think. Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Use ByteCode
Hello all , I'm wondering if anybody has successfully used B::Bytecode and ByteLoader for a mod_perl module or any other module that is imported by mod-perl. I need to use this kind off byte loaderfeature or need to change to something that hides the source code. greetings, luc
ANNOUNCE: Loggerithim 6.3.1
Hello again, Loggerithim 6.3.1 is now available, ChangeLog follows: - 6.3.1 * Installer fixes * Unit tests * Fixes from the removal of old db columns * Disable debugging in the agent by default About Loggerithim: Loggerithim is a monitoring package that allows you to monitor your systems, proactively spot problems, perform post-mortems, throw alerts when bad (or good) things happen, and automate routine tasks. http://loggerithim.sourceforge.net As always, please report any problems to the appropriate mailing list (see the website). Upgrading users can consult Appendix C of the documentation. Cory 'G' Watson http://gcdb.spleck.net
Re: Authorization question
On Thu, 27 Feb 2003, Bill Moseley wrote:
On Thu, 27 Feb 2003, Perrin Harkins wrote:
Jean-Michel Hiver wrote:
Yes, but you're then making the authorization layer inseparable from
your applicative layer, and hence you loose the interest of using
separate handlers.
It's pretty hard to truly separate these things. Nobody wants to use
basic auth, which means there is a need for forms and handlers. Then
you have to keep that information in either cookies or URLs, and there
is usually a need to talk to an external data database with a
site-specific schema. The result is that plug and play auth schemes
only work (unmodified) for the simplest sites.
Anyone using PubCookie?
http://www.washington.edu/pubcookie/
All C, no?
- nick
--
Nick Tonkin {|8^)
Re: Authorization question
Jean-Michel Hiver wrote: It's pretty hard to truly separate these things. Nobody wants to use basic auth, which means there is a need for forms and handlers. How do you mean, 'nobody'? Users certainly don't mind! Sure they do. They want a nice HTML login screen, and features like remember this login on this computer (using cookies) which is standard on most major sites now. I admit that it's hard to get away without cookies and URI encoding schemes, but not impossible. There's a lot of tricks that you can do with path_info... But path_info is URI encoding. Also, most of the auth/access modules, including ones that stick to the auth and access phases, use cookies or URIs. There really is no other option except basic auth. If you build a generalized auth system, there may well be other people interested in it. However, it would have to be very easy to change the mechanisms for maintaining state (cookies, URIs, basic auth) and checking credentials (any kind of database with any kind of schema). The latter probably means some custom development on every installation. - Perrin
Re: [mp1] Help with Apache::MP3
Wilcox, Curtis wrote: I've resolved this problem, at least to a degree which satisfies me. I built apache-1.3.27 and mod_perl-1.27 together following the INSTALL.simple instructions from the mod_perl source but adding EVERYTHING=1 when running Makefile.PL. This makes Apache::MP3 work on a Red Hat 7.3 system with perl 5.8.0 added and also on Red Hat 8.0 (which has perl 5.8.0 included) but only if mod_perl-1.99 was *not* a selected package. On an 8.0 system with mod_perl-1.99 present, /usr/local/apache/bin/apachectl configtest still causes a segmentation fault. If you have a problem with mp2, you have to try the latest stable version or even the cvs version, since many bugs were fixed since the version bundled with RH8.0. If the bugs is still there, please do a complete bug report following the guidelines: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems __ 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: Approaches to upgrading Apache but not mod_perl
Carlos Ramirez wrote: I've been using apache/mod_perl for some time now and have upgraded apache many times with mod_perl. In most cases I've only had to upgrade the web server only but since I use mod_perl I also compile mod_perl statically. Now my question is: What's the correct or best approach of compiling mod_perl into Apache without acutally installing mod_perl, since it's already installed? For example, when I want to upgrade to Apache 1.3.26/mod_perl-1.27 to 1.3.27/mod_perl-1.27 I perform the following standard compliation steps: 1. % tar xzvf apache_1.3.27.tar.gz 2. % cd mod_perl-1.xx 3. % perl Makefile.PL APACHE_SRC=../apache_1.3.27/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 4. % make make install 5. % cd ../apache_1.3.xx 6. % make make install Step 4. executes make install which copies mod_perl into the perl installation location, which seems harmless, but is thie ok? Or is there a way that I can somehow just copy the libperl.a into apache_1.3.27/src/modules/lib/perl ? Although, I've been following these steps for years and it works fine, I've got bitten by the curious bug and would like to know how other approach these types of upgrades. To upgrade Apache you are better off to do the whole installation from scratch. Mainly for binary compatibility reasons. e.g. in the 2.0 world, Apache won't start if you have a modperl module built with a previous Apache version. __ 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: Scripts and HTML docs in the same directory (+ modperl newbieexperiences)
Mark James wrote: Stas Bekman wrote: Mark James wrote: 1. In http://perl.apache.org/docs/1.0/guide/getwet.html , use of x.x.x for both the Apache and mod_perl version numbers made me think that the version numbers had to be matched. Maybe y.y.y should be used for one. Please get used to x.x.x meaning any. Otherwise we would need to remember to use z.z.z. for php plugs in and f.f.f. when openssl is added, etc... hope you get the idea. When they're discussed in the same sentence, and when building one requires linking to the installation or source directory of the other, I think a different variable helps. since I've already changed them to be mod_perl-1.xx and apache_1.3.xx there shouldn't be a confusion anymore. 2. In the configuration section of the 2.0 docs (http://perl.apache.org/docs/2.0/user/intro/start_fast.html#toc_Configuration) it neglects to state the need to issue a directive for the mod_perl handler one is going to use, e.g. PerlModule ModPerl::Registry, though it is covered in the configuration docs (including the startup-file option). you mean preloading the module? That's not necessarily in mp2, though advisable for performance reasons. In mp2, you can say: PerlResponseHandler ModPerl::Registry without: PerlModule ModPerl::Registry Well I just commented out use ModPerl::Registry () in my startup script and it still worked. But earlier I had found that adding PerlModule ModPerl::Registry the http.conf was the key to getting rid of the rash of error messages I was getting on server start-up. It must have been a manifestation of some other problem, perhaps with mod_perl-1.99_08 (now using the CVS version to fix a missing OPEN in Apache::RequestRec, and to avoid the failed perlio tests), or with an older CGI.pm (found out late that CGI=2.89 was needed). Bugs get fixed ;) you can also use the syntactic sugar to preload modules, by simply stating at the beginning of your mod_perl configuration 'PerlOptions +Autoload'. See http://perl.apache.org/docs/2.0/user/config/config.html#C_AutoLoad_ or using + before the handler name: PerlResponseHandler +ModPerl::Registry OK, so 2.0 is not like 1.0 where PerlModule acts like use() (http://perl.apache.org/docs/1.0/guide/config.html#PerlModule_and_PerlRequire_Directives), but is more like @INC manipulation; and these handler autoload directives are an alternative to use-ing them in a start-up script. No, it works exactly the same. It's just that in 2.0 you don't have to preload the modules. An attempt to load them will happen when they will be used for the first time. My start-up script is very long because it calls use for just about every package in an extensive package set. I suppose an import function could be created in a master package of package suite that when called require-ed all the associated packages, so that mod_perl can have the entire suite pre-loaded prior to forking through just one line in the start-up script. You can certainly do that. Or you can even preload *all* available mp2 packages :) http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#preload_all_modules__ Thank you Stas for your prompt help. ;) __ 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: mod_perl Developer's Cookbook
Gazi, Nasser (London) wrote: A question about mod_perl Developer's Cookbook by Young, Lindner and Kobes: Is this book still relevant and worth buying for mod_perl2 ? (I'm about to dive into web development using Apache/mod_perl and intend to go straight to mp2). Remember that mp2 is mp1++. Most of the things that worked in mp1 will work the same way in mp2. In addition mp2 introduces a whole lot of new things. The majority of examples from the Eagle book and The Cookbook should work out of box with Apache::compat. See: http://perl.apache.org/docs/2.0/user/compat/compat.html Therefore you want to have these two books on your bookshelf. Believe me you won't need to dust them if you do modperl development. Another reason to purchase the book is to support their authors and publishers. If the books don't pay off, don't expect their second editions that should cover modperl 2.0 to come out any time soon, if at all. __ 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: Problem headers_out
Geoffrey Young wrote:
Udlei Nattis wrote:
Hi all
Why i have problem?
$cookie1 = new CGI::Cookie(
-name = 'sessid', -value = $session-id());
$r-headers_out-{'Set-Cookie'} = $cookie1;
[snip]
Can't locate object method STORE via package APR::Table at
/export/eShop/lib/eShop/Web/Shop/index.pm line 30.
if i remove $r-headers_out-{'Set-Cookie'} = $cookie1;
you need to
use APR::Table;
in your script.
In the future use:
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#lookup_method__
The reason is explained here:
http://perl.apache.org/docs/2.0/user/compat/compat.html#Code_Porting
also please remember to mark your subject with mp2 when asking mp2 questions.
__
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: make errors with mod_perl-1.99_08 on aix 4.3.3
Priest, Darryl - BALTO wrote:
Thanks for the quick response, additional information as requested is below.
Cool, please let me know whether this patch solves the problem (you need to
apply the patch:
cd modperl-2.0
patch -p0 patch_itself
rebuild mod_perl from scratch
Index: lib/ModPerl/Code.pm
===
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/Code.pm,v
retrieving revision 1.92
diff -u -r1.92 Code.pm
--- lib/ModPerl/Code.pm 8 Feb 2003 04:17:11 - 1.92
+++ lib/ModPerl/Code.pm 28 Feb 2003 00:22:23 -
@@ -512,6 +512,7 @@
return unless $flags;
for my $flag (split /\s+/, $flags) {
+next if /^-/; # skip -foo flags
my($name, $val) = split '=', $flag;
$val ||= '';
$name =~ s/^-D//;
__
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: make errors with mod_perl-1.99_08 on aix 4.3.3
Stas Bekman wrote:
Priest, Darryl - BALTO wrote:
Thanks for the quick response, additional information as requested is
below.
Cool, please let me know whether this patch solves the problem (you need
to apply the patch:
cd modperl-2.0
patch -p0 patch_itself
rebuild mod_perl from scratch
oops, please try this one instead:
Index: lib/ModPerl/Code.pm
===
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/Code.pm,v
retrieving revision 1.92
diff -u -r1.92 Code.pm
--- lib/ModPerl/Code.pm 8 Feb 2003 04:17:11 - 1.92
+++ lib/ModPerl/Code.pm 28 Feb 2003 00:24:45 -
@@ -512,6 +512,7 @@
return unless $flags;
for my $flag (split /\s+/, $flags) {
+next if $flag =~ /^-/; # skip -foo flags
my($name, $val) = split '=', $flag;
$val ||= '';
$name =~ s/^-D//;
__
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
Apache version for use with SSL on Windows
To the group, I'm running the configuration listed below. I've delayed adding SSL for as long as I can, but now I have to do it. It is for a government site and they want their sites to use SSL all the time (no port 80 connections at all). So, is Apache 2.x and mod_perl ready for operating in this mode on Windows? Anybody running 2.0 in production on Windows 2000? Input greatly appreciated. Thanks Chuck Build Workstation Software: Visual C++ 6.0 Apache Modules Used: apache_1.3.26source.tar.gz mod_perl-1.27.tar.gz mod_jk1.2.0 PERL Modules Used: MIME-Lite-1.145.tar.gz perl_560_stable.zip DBD-ODBC-0.28.tar.gz ApacheDBI-0.87.tar.gz DBI-1.13.tar.gz libnet-1.0703.tar.gz Apache-Session-1.03.tar.gz MD5-1.7.tar.gz Spreadsheet-WriteExcel-0.10.tar.gz DBD-Oracle-1_03_tar.gz URI-1.07.tar.gz MIME-Base64-2_11_tar.gz Apache Tomcat: Apache Tomcat 4.1.12 Server Software: Oracle 8I 8.1.6 Oracle Client Software Oracle Programmer (for the OCI libraries) Windows 2000
mp2: works with NetBSD? was Re: mp2: anyone got mp2 and apache 2.0.44working on any version of OpenBSD?
As no-one seems interested in this after a few weeks, I'm considering NetBSD ... anyone got mod_perl2 and apache2 running nicely on NetBSD 1.6? That's my next-choice O/S for my application, but I don't have a testbed yet to play with. Carl Carl Brewer wrote: Scanning both dev.modperl and here, I've found a couple of mails concerning OpenBSD and mod_perl 2 (1.99_08) with Apache 2.0.44, I've tried a few quick hacks and have been unable to get it working either, with the same error as seen on : http://mathforum.org/epigone/modperl/sponggrunlim/[EMAIL PROTECTED] I'm using perl 5.8.0 on OpenBSD 2.9, but the same error crops up. Has anyone been able to get it to run? (it seems to work well on SunOS 5.8 with the same apache perl versions) Carl
Re: mp2: works with NetBSD? was Re: mp2: anyone got mp2 and apache2.0.44 working on any version of OpenBSD?
Carl Brewer wrote: As no-one seems interested in this after a few weeks, It's not about not being interested, but lacking the access to the system and/or lacking the expertise on these platforms. We really need to have at least one person taking care of problems on each of the less-mainstream platforms. I'm considering NetBSD ... anyone got mod_perl2 and apache2 running nicely on NetBSD 1.6? That's my next-choice O/S for my application, but I don't have a testbed yet to play with. Carl Carl Brewer wrote: Scanning both dev.modperl and here, I've found a couple of mails concerning OpenBSD and mod_perl 2 (1.99_08) with Apache 2.0.44, I've tried a few quick hacks and have been unable to get it working either, with the same error as seen on : http://mathforum.org/epigone/modperl/sponggrunlim/[EMAIL PROTECTED] I'm using perl 5.8.0 on OpenBSD 2.9, but the same error crops up. Has anyone been able to get it to run? (it seems to work well on SunOS 5.8 with the same apache perl versions) Carl -- __ 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: mp2: works with NetBSD? was Re: mp2: anyone got mp2 and apache2.0.44 working on any version of OpenBSD?
Stas Bekman wrote: Carl Brewer wrote: As no-one seems interested in this after a few weeks, It's not about not being interested, but lacking the access to the system and/or lacking the expertise on these platforms. We really need to have at least one person taking care of problems on each of the less-mainstream platforms. Understood, I can make a box available to you if it helps? Carl
Re: mp2: works with NetBSD? was Re: mp2: anyone got mp2 and apache2.0.44 working on any version of OpenBSD?
Carl Brewer wrote: Stas Bekman wrote: Carl Brewer wrote: As no-one seems interested in this after a few weeks, It's not about not being interested, but lacking the access to the system and/or lacking the expertise on these platforms. We really need to have at least one person taking care of problems on each of the less-mainstream platforms. Understood, I can make a box available to you if it helps? Unfortunately, the and/or lacking the expertise on these platforms part is valid for me. I've responded in hope that somebody else who has the expertise or is interested in getting one, will followup. __ 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
[error] Insecure dependency in unlink while running with -T switch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line 106
All,
Can Anybody see what I'm doing wrong here?
I have the following error :-
[error] Insecure dependency in unlink while running with -T switch at
/usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line 106.
When I run the following subroutine:-
sub delete_session
{
my $self=shift;
my $session_id=shift;
if ($session_id =~ /^(\w\w*)$/)
{
$session_id = $1; # $data now untainted
}
else
{
die Bad Tainted data in $session_id;# log this somewhere
}
die $self-{lh}-maketext(No Session_id given) unless ($session_id);
my $t=time;
my %session;
my $Directory = My::Conf::APACHE_SESSIONS_TMPDIR;
my $LockDirectory = My::Conf::APACHE_SESSIONS_LOCKDIR;
$Directory=XX_GR_XX$Directory.XX_GR_XX; #e.g.
'/path/to/dir/'
$LockDirectory=XX_GR_XX$LockDirectory.XX_GR_XX; #e.g.
'/path/to/dir/'
if ($Directory =~ /^XX_GR_XX(.*)XX_GR_XX$/)
{
$Directory = $1; # $data now untainted
}
else
{
die Bad Tainted data in $Directory;# log this somewhere
}
if ($LockDirectory =~ /^XX_GR_XX(.*)XX_GR_XX$/)
{
$LockDirectory = $1; # $data now untainted
}
else
{
die Bad Tainted data in $LockDirectory;# log this somewhere
}
#Load an existing session
eval
{
tie %session, 'Apache::Session::File',$session_id,
{
Directory = Bficient::Conf::APACHE_SESSIONS_TMPDIR,
LockDirectory = Bficient::Conf::APACHE_SESSIONS_LOCKDIR,
};
};
if ($@)
{
die $self-{lh}-maketext(Couldn't Load Apache::Session - \[_1]\
For '\[_2]\',$@,$self-UserName);
}
print STDERR Just about to unlink\n;
tied(%session)-delete;
return 1;
}
Re: [error] Insecure dependency in unlink while running with -T switch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line 106
Quoting Martin Moss [EMAIL PROTECTED]:
All,
Can Anybody see what I'm doing wrong here?
I have the following error :-
[error] Insecure dependency in unlink while running with -T switch at
/usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line 106.
The problem is not with your code, it is that Apache::Session::File does
not work in Taint mode. Apache::Session::Store::File gets the session ID from a
file (which means session_is is tainted), and then uses the tainted session_id
to delete a file (hence the unlink error).
A quick fix for this is for you to untaint the session ID yourself after
the session has been unserialized. Put the following two lines right after you
tie the session:
$session{_session_id} =~ /^([a-zA-Z0-9]+)$/;
$session{_session_id} = $1;
This probably should be fixed in Apache::Session itself as I am sure other
people will run into it.
By the way, you really shouldn't be using Apache::Session::File anyway for
performance reasons. At least use Apache::Session::DB_File which most likely
doesn't suffer from this taint problem and will be much quicker.
Cees
When I run the following subroutine:-
sub delete_session
{
my $self=shift;
my $session_id=shift;
if ($session_id =~ /^(\w\w*)$/)
{
$session_id = $1; # $data now untainted
}
else
{
die Bad Tainted data in $session_id;# log this somewhere
}
die $self-{lh}-maketext(No Session_id given) unless ($session_id);
my $t=time;
my %session;
my $Directory = My::Conf::APACHE_SESSIONS_TMPDIR;
my $LockDirectory = My::Conf::APACHE_SESSIONS_LOCKDIR;
$Directory=XX_GR_XX$Directory.XX_GR_XX; #e.g.
'/path/to/dir/'
$LockDirectory=XX_GR_XX$LockDirectory.XX_GR_XX; #e.g.
'/path/to/dir/'
if ($Directory =~ /^XX_GR_XX(.*)XX_GR_XX$/)
{
$Directory = $1; # $data now untainted
}
else
{
die Bad Tainted data in $Directory;# log this somewhere
}
if ($LockDirectory =~ /^XX_GR_XX(.*)XX_GR_XX$/)
{
$LockDirectory = $1; # $data now untainted
}
else
{
die Bad Tainted data in $LockDirectory;# log this somewhere
}
#Load an existing session
eval
{
tie %session, 'Apache::Session::File',$session_id,
{
Directory = Bficient::Conf::APACHE_SESSIONS_TMPDIR,
LockDirectory = Bficient::Conf::APACHE_SESSIONS_LOCKDIR,
};
};
if ($@)
{
die $self-{lh}-maketext(Couldn't Load Apache::Session - \[_1]\
For '\[_2]\',$@,$self-UserName);
}
print STDERR Just about to unlink\n;
tied(%session)-delete;
return 1;
}
Re: [error] Insecure dependency in unlink while running with -T switchat /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line 106
Quoting Martin Moss [EMAIL PROTECTED]: just a minor comment regarding untainting techniques. If do /(.*)/ to launder tainted vars as you did in: if ($Directory =~ /^XX_GR_XX(.*)XX_GR_XX$/) you can as well turn the taint mode off. For more info see: http://www.gunther.web66.com/FAQS/taintmode.html#clear_taint __ 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
WEb hosting..
Hi. Some know web hosting providers with mod_perl support... Regards..
Re: WEb hosting..
Fco. Valladolid wrote: Hi. Some know web hosting providers with mod_perl support... Regards..
Re: WEb hosting..
Fco. Valladolid wrote: Hi. Some know web hosting providers with mod_perl support... http://perl.apache.org/help/isps.html As usual, if you know of ISPs that aren't listed there (or listed, but not providing modperl support any longer), please let us know. __ 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
