Re: PerlAccessHandler
On Fri, Jul 26, 2002 at 04:11:29PM -0700, Rasoul Hajikhani wrote:
Folks,
My PerlAccessHandler is being executed twice per each request. Is this a
normal behavior for an access handler?
Here is my .conf entry
Location /myHandler
SetHandler perl-script
# run is a wrapper for my handler
# all common methods which many of my handlers
# use are stored in the super class of myHandler
# in which run is a part of.
# Also wraps myHandler in a try {} catch { ...
# block.
PerlHandler myHandler-run
PerlAccessHandler myAccess
.
.
.
/Location
Hmm... Is the PerlAccessHandler directive defined anywhere else? Perhaps in
a .htaccess file in the doc root?
The access handler's job is to check for cookies and last login time.
There are no fancy codes there... However, on every request, the handler
is invoked twice. Can someone make a suggestion as to why this is
happening?
Maybe you're trying to pull some sort of image from a local path? Something
like img src=image.gif has bitten me before. Javascript is another
one that bites me often. Mouse over code can be bad too... They are often
coded as relative paths.
Good luck,
Rob
RE: PerlAccessHandler via set_handlers()?
-Original Message-
From: will trillich [mailto:[EMAIL PROTECTED]]
thanks one and all for the pointers on cookies. i probably grok
738% more than i did, but i have a feeling it's still only 13% of
the pie. or in this case, cookie...
so how's this PerlAccessHandler, for twisted logic? hole-punching
and pitfall-warning equally welcome:
This ought to work fine, but it probably won't scale well if you ever have a
need to extend this to support multiple authentication paths (more than one
user database or user type). You'll just end up pushing more and more logic
into the handler which is going to get you into trouble. This won't scale
at all if you ever need to create a central login/ticket server.
The beauty of the example in the Eagle book (and Apache::AuthTicket) is that
it defines distinct handlers for distinct URL spaces which, in turn,
correspond to distinct functions (prompt for login, authentication,
authorization). If you ever have the need to separate these across multiple
servers, you'll have difficulties with your scheme.
Also, you'll always have to be extremely careful when extending this in the
future to always unshift login or authentication handlers when you return OK
or DECLINED. Since you've lumped login prompt/authentication/authorization
all into a single handler, returning OK without a challenge/authentication
handler will immediately grant access to the requested resource.
#httpd.conf
PerlAccessHandler My::TrollUnderTheBridge
PerlHandler Something::OrOther
#perl
package My::TrollUnderTheBridge;
sub handler {
my $r = shift;
if ( logging_in($r) ) {
my $h = $r-get_handlers( 'PerlHandler' );
unshift @{$h},\checkUser ; # do
checkUser first
$r-set_handlers( PerlHandler = $h );
I think this is wrong. checkUser() should be a PerlAccessHandler. You
should probably simply return checkUser rather than waiting until the
content handler phase.
} elsif ( needs_login($r) ) {
$r-set_handlers( PerlHandler = [ \login ] );
# return AUTH_REQUIRED; or not ?
Not. Can only return OK, DECLINED or FORBIDDEN in a PerlAccessHandler.
Besides AUTH_REQUIRED (in a PerlAuthHandler) will prompt for a HTTP basic
authentication session, which you certainly don't want. Should simply
return OK or DECLINED and let the request fall through to the PerlHandler.
}
return OK;
}
sub checkUser {
my $r = shift;
if ( bad_passwd( $r ) ) {
# generate html for username/password
login screen, again
login( $r );
# we handled it, other handlers won't
be called (right?)
return OK;
} else {
$r-headers_out-add( 'Set-Cookie' =
make_ticket( $r ) );
# let normal handler do its thing
return DECLINED;
}
}
so i can keep the same url for all three stages, with no need for
preliminary cookies:
3. valid ticket - show web pages
else
2. validate user/pass - make ticket show pages
else
1. login - get user/pass
is this sound? or am i fuxnored?
--
but then from within login() i'd like to be able to abort, like
so--
Re: PerlAccessHandler -- struggling and drowning
will trillich said... problem: some browsers see 'redirect' and ignore all other headers, so the cookies aren't set. when the browser arrives at the login area, there's no cookie to send there, to formulate a return-to address from. What percentage of 'some browsers' is your user base? I do the following: $r-err_headers_out() to set cookie for decent browsers In my /Login routine, I check for the cookie that was set in err_headers_out. If that cookie does not exist (bad browser), I go to the Apache config and grab DEFAULT_LOGIN_URL, which is set via: PerlSetVar DEFAULT_LOGIN_URL http://foo.com/bad_browsers/welcome.html I then redirect to that location, and explain in that location why they don't get to magically go where they are supposed to. If this is a feature they REALLY want, then they can change browsers. But I see that most people don't really care, and they just happily point and click to the appropriate portion of the site. Now, if you were using Apache::Session, this would probably be moot. You could just add something special to your %session before the redirect in your authhandler, and yank it out after the successful /Login and redirect from it. Hope this makes sense. -- David S. Kenzik [EMAIL PROTECTED] - http://kenzik.com Original Music - http://text.org
Re: PerlAccessHandler -- struggling and drowning
Chris Strom wrote:
-Original Message-
From: will trillich [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 30, 2001 9:44 PM
To: [EMAIL PROTECTED]
Subject: PerlAccessHandler -- struggling and drowning
this is a PerlAccessHandler, which should check for the existence
of a cookie in the incoming headers, and if not there (or
expired) it should redirect the browser to a login area that
takes name/password pair, and if valid, would then return the
browser to the original URL. to do that, as we issue the
'redirect to the login area' we set a cookie containing the URL
to return to.
I can't say as I've had any problems using
err_headers_out-add(Set-Cookie) with any browsers. I'm surprised to hear
that you've had problems with it.
even DURING a redirect? i seem to have hit a chord here, as
i'm getting lots of me too in my mailbox.
You might simply try giving up the use of
a cookie for this, and encode the return URL in a query string instead.
This is guaranteed to work regardless of browser, but you'll have to pass
this information between pages (a reasonable trade off for choosing to
support silly browsers, I suppose).
something else i'm trying now is
$r-set_handlers(PerlHandler = undef);
$r-push_handlers( PerlHandler = sub { ...print meta http-equiv...
but THIS for some reason redirects the browser back to itself,
instead of to the login area. the protected area is /protected
and the login area is /login so the http-equiv tag looks like
meta http-equiv=Refresh content=0; http://www.fricking-site.com/login;
but it cycles back to www.cannot-get-in.com/protected instead... !
this is bizarre enough i'm considering joining a monastery. at least
there, it's quiet.
--
mailto:[EMAIL PROTECTED]
http://www.dontUthink.com/
Re: PerlAccessHandler -- struggling and drowning
On Tue, May 01, 2001 at 01:58:56PM -0400, Chris Strom wrote:
I can't say as I've had any problems using
err_headers_out-add(Set-Cookie) with any browsers. I'm
surprised to hear that you've had problems with it.
even DURING a redirect? i seem to have hit a chord here, as
i'm getting lots of me too in my mailbox.
Even during a redirect. The following works for me (in a PerlInitHandler
NOT a PerlAccessHandler) with lynx (2.7) just fine.
$r-err_headers_out-add('Location' = $dest);
$r-err_headers_out-add('Set-Cookie' = $cookie);
$log-debug(Authentication successful. Redirecting to $dest);
return REDIRECT;
okay, i'll try that, too. expectations low, from experience. :/
something else i'm trying now is
$r-set_handlers(PerlHandler = undef);
$r-push_handlers( PerlHandler = sub { ...print meta
http-equiv...
This ought to work and is a little more conceptually clean that what you
were trying to accomplish with redirects and printing content in the
PerlAccessHandler. Still, my gut feeling is that it's better to move the
handler up the chain to a PerlInitHandler and do simple redirects there.
Obviously it's preferable to perform access checks in PerlAccessHandlers,
but sometimes you do need to set a cookie when doing redirects.
hmm. implying that cookie-setting gets borked in accesshandlers?
(mine sure do.)
but THIS for some reason redirects the browser back to itself,
instead of to the login area. the protected area is /protected
and the login area is /login so the http-equiv tag looks like
meta http-equiv=Refresh content=0;
http://www.fricking-site.com/login;
but it cycles back to www.cannot-get-in.com/protected instead... !
Are you setting HTTP headers?
% telnet no-way-in-hell-bubba.com 80
Trying ##.##.##.##...
Connected to no-way-in-hell-bubba.com.
Escape character is '^]'.
GET /protected HTTP/1.1
Host: no-way-in-hell-bubba.com
i ask for /protected on lunacy-for-lunch.com server, and get
HTTP/1.1 200 OK
Date: Tue, 01 May 2001 18:33:43 GMT
Server: Apache/1.3.9
Set-Cookie: request_uri=http%3A%2F%2Fno-way-in-hell-bubba.com%2Fprotected;
domain=.no-way-in-hell-bubba.com; path=/
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1
148
headmeta http-equiv=Refresh content=2;
http://www.no-way-in-hell-bubba.com/login/;
titleNot logged in/title/head
body bgcolor=white
h1Gotta log in, first/h1
pYou're being redirected to a
href=http://www.no-way-in-hell-bubba.com/login;http://www.no-way-in-hell-bubba.com/login/a
in just a moment./p
h2Please stand by.../h2
/body/html
from my understanding, which gets shakier by the minute, the
headers and http-equiv are all correct. but lynx and netscape
both bounce like hell right back to /protected ad nauseum.
as if the meta tag was
meta http-equiv=refresh content=2; http://yada-yada.com/protected;
which it's not.
next i'll be taking up russian roulette. (i'll leave one chamber
empty, for sport.)
--
don't visit this page. it's bad for you. take my expert word for it.
http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
RE: PerlAccessHandler -- struggling and drowning
headmeta http-equiv=Refresh content=2; http://www.no-way-in-hell-bubba.com/login/; should be: meta http-equiv=Refresh content=2; URL=http://www.no-way-in-hell-bubba.com/login/;
Re: PerlAccessHandler -- struggling and drowning
On Tue, May 01, 2001 at 02:49:05PM -0400, Chris Strom wrote: headmeta http-equiv=Refresh content=2; http://www.no-way-in-hell-bubba.com/login/; should be: meta http-equiv=Refresh content=2; URL=http://www.no-way-in-hell-bubba.com/login/; tolja my understanding was questionable. that helped that part, at least... much thanks! so now i feel like i've got one brick done, only forty-nine thousand, nine hundred ninety-nine to go. (union break time.) -- don't visit this page. it's bad for you. take my expert word for it. http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: PerlAccessHandler -- struggling and drowning
On Tue, May 01, 2001 at 01:39:13PM -0500, will trillich wrote:
On Tue, May 01, 2001 at 01:58:56PM -0400, Chris Strom wrote:
Even during a redirect. The following works for me (in a PerlInitHandler
NOT a PerlAccessHandler) with lynx (2.7) just fine.
$r-err_headers_out-add('Location' = $dest);
$r-err_headers_out-add('Set-Cookie' = $cookie);
$log-debug(Authentication successful. Redirecting to $dest);
return REDIRECT;
okay, i'll try that, too. expectations low, from experience. :/
it's doing what it's supposed to do, i think.
guess what -- new speed bump. (color me surprised.)
now when lynx or netscape (but not konqueror) get validated, and
the server tries to redirect the browser back to the original
URL, the browsers seem to have cached the /login page as if it
were the /protected page.
so i'm trying
Pragma: no-cache
to no effect. anybody got any other ideas?
--
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: PerlAccessHandler -- struggling and drowning
will trillich ([EMAIL PROTECTED]) said something to this effect on 05/01/2001: now when lynx or netscape (but not konqueror) get validated, and the server tries to redirect the browser back to the original URL, the browsers seem to have cached the /login page as if it were the /protected page. so i'm trying Pragma: no-cache to no effect. anybody got any other ideas? Does http://thingy.kcilink.com/modperlguide/snippets/Cache_Control_for_Regular_and_Er.html help you? (darren) -- I don't want Perl to be beautiful, I want you to write beautiful programs in Perl. -- Larry Wall
RE: PerlAccessHandler -- struggling and drowning
-Original Message- From: will trillich [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 01, 2001 3:38 PM To: [EMAIL PROTECTED] Subject: Re: PerlAccessHandler -- struggling and drowning now when lynx or netscape (but not konqueror) get validated, and the server tries to redirect the browser back to the original URL, the browsers seem to have cached the /login page as if it were the /protected page. so i'm trying Pragma: no-cache no-cache headers _should_ have no effect on anything other than a sucessful response. http://www.mail-archive.com/dev@perl.apache.org/msg00081.html --Geoff
Re: PerlAccessHandler causes '500 Server Error' on 'return OK'
Hi. Sometimes, one has to answer one's own questions On Fri, Mar 30, 2001 at 03:00:08PM +0200, Jochen Schnapka wrote: Hi. I'm trying some of the well-known Apache-Perl-Modules, such as DayLimit.pm. Strangely, the server throws an internal error (500), when the Perl module returns 'OK'. The same is with 'DECLINED'. FORBIDDEN works well, AUTH_REQUIRED works also (though it doesn't make sense in the access control stage). I do not see anything in my error_log. The problem seems to be specific to the PerlAccessHandler Other Handlers (e.g.the PerlAuthenHandler) work fine: when returning OK, the page is displayed. After some days of debugging, I finally found the error. The Documentation to DayLimit.pm (http://perl.apache.org/src/contrib/) puts a 'Satisfy any' into the configuration, which causes the error. This statement has nothing to do at this place and should be taken out. See the apache docu for using 'Satisfy'. I consider it as a bug, that there is no specific debug information in the error_log, but only 'Internal Server Error'. I think, this should be enhanced. Greetings, ~~~:-Jochen
RE: PerlAccessHandler Question...
#Location Handlers Location PerlAccessHandler Apache::GateKeeper /Location The Location directive needs to specify a URL to which it applies: Location / Perl*Handlers can go pretty much anywhere, as long as the server administrator hasn't diabled .htaccess files. perl.conf will work. httpd.conf will work. Hope that helps. Chris
Re: PerlAccessHandler Question...
Hi there, On Tue, 9 Jan 2001, Joseph Crotty wrote: open(FILE, "/tmp/dog"); Always check the status returned by a call like open(). 73, Ged.
RE: PerlAccessHandler Question...
Good advice Ged. I figured out the problem...there was another server running on the port almost exactly like the one I was using, but without the PerlAccessHandler. Huge brain fart. I need a nap. -Original Message- From: G.W. Haywood [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 09, 2001 11:44 AM To: Joseph Crotty Cc: '[EMAIL PROTECTED]' Subject: Re: PerlAccessHandler Question... Hi there, On Tue, 9 Jan 2001, Joseph Crotty wrote: open(FILE, "/tmp/dog"); Always check the status returned by a call like open(). 73, Ged.
