I am stuck in an Ensim environment (shared web-hosting, Apache 1.3.27
and mod_perl 1.24) and am trying to get around some of the limitations
imposed by Ensim. Basically, I have complete .htaccess control but have
no way to restart the server or start it with different arguments or
modify the
Apache::StatINC is R.I.P. Use Apache::Reload instead.
but Apache::StatINC comes with mp1 and Apache::Reload doesn't - it's
difficult to install modules on these ensim boxes since you don't have
root (and yes, there are other ways around it of course :)
Well, Apache::StatINC wasn't
I am trying to design/implement a fairly simple authentication scheme
using cookies and such, but wanted to air my design questions before I
run into too many issues.
I would like the site to be almost entirely publicly accessible, however
if you log in you get special options in addition to
I am fairly new to mod_perl/apache, having grown up with OpenACS and
AOLServer. I have read all of the docs on the web site (I think) and
had a whole authentication/authorization scheme planned out using
Apache::AuthCookie and Apache::Session. I was just put in charge of a
beta web
For some reason, CGI.pm (2.93) does not seem to parse POST data within a
PerlAuthenHandler. For example, the following:
sub handler {
my $r = shift;
my $q = new CGI($r);
my @params = $q-param;
$r-server-log-error(handler params are . join ::, @params);
return Apache::OK;
}
logs
Jonathan Gardner wrote:
It sounds like you are mixing HTTP-level authentication with
application-level
authentication.
Well, sorta. I am actually using a custom module very similar to the
one found in the cookbook (and AuthCookie, I think), i.e. create a
PerlAuthenHandler that sets the custom
Perrin Harkins wrote:
I'm not certain it won't work to use $r-user, but I don't see the point
when you already have a unique identifier in the cookie.
Well, I figured that the AuthenHandler already parsed the authentication
cookie and declared it valid, so I didn't really see a point the in
Perrin Harkins wrote:
Well, I'm not sure what's involved in determining $r-user aside from
reading the cookie. It may not make any difference.
Here's a typical pattern for this:
- Fetch the session key from the validated cookie.
- Load the session using that key.
- Grab the user ID from the
Hmm, I see now. I don't really care about users who aren't logged in,
so I don't know that there is a need to store session data for them.
I guess my pattern is:
within PerlAuthenHandler
-Check to see if there are passed user/password params. If so,
validate params against user/pass in