You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Fran Fabrizio <ff...@mmrd.com> on 2002/04/18 00:01:27 UTC
framesets/AuthCookie question
I'm using AuthCookie and as some of you know, if it determines your
session to be invalid it redirects to a login page instead by way of a
FORBIDDEN response coupled with a custom error page.
My app has a frameset (navigation on the left, and two data frames on
the right). I know the evils of framesets, but in our case, it's the
best way to present our particular data.
What ends up happening is that if the session expires, AuthCookie
displays the login page inside whatever frameset you were clicking in,
while the other two remain on whatever they were on previously.
I made a quick solution...I told AuthCookie that my login page was
login.html. login.html had javascript which called /real/login (a
mod_perl handler) and targeted it to the top frame. All is well and now
the entire browser window gets cleared and replaced with the login page.
However...I then thought it'd be neat to include on the /real/login page
a message to tell them how they got there ("Your session has expired",
"Your account has logged on from another location", "Invalid
username/password combination", whatever...).
At first I thought I could accomplish this by simply doing
$r->notes('LOGINFAILMSG' => 'Your session has expired') if AuthCookie
detected it to be thus, and then in my handler I could retrieve it and
display it.
However, it's failing of course because I added the extra redirection of
the login.html w/ the javascript, which makes a round trip to the client
and back, so it looks like a brand new request to mod_perl, thus, no
notes() any more. Is there a solution to breaking out of the frameset
AND propagating the reason for the logout to the /real/login page?
I'd appreciate and and all ideas. Thanks!
-Fran
Re: mod_perl Basic Authentication problem using PerlAuthenHandler
Posted by Jason <jt...@cartmanager.net>.
Thank you... cant believe I missed that... was to excited about the ability to do my own auth program....
I added
allow from x.x.x.x
and it worked great....
Thank you.
----- Original Message -----
From: "Geoffrey Young" <ge...@modperlcookbook.org>
To: "Jason" <jt...@cartmanager.net>
Cc: <mo...@apache.org>
Sent: Wednesday, April 17, 2002 6:21 PM
Subject: Re: mod_perl Basic Authentication problem using PerlAuthenHandler
>
>
> Jason wrote:
>
> > In httpd.conf i have
> > <Location /~jter>
>
>
> [snip]
>
>
> > Deny from all
> > </Location>
>
>
> [snip]
>
>
> >
> > It warns to the log file and returns.... But the problem is, why does my browser come up "forbidden"
>
> I suspect "Deny from all" is the issue...
>
> the PerlAccessHandler will run before the apache default mod_access gets the
> chance to implement the Deny rule. on a successful login, your
> PerlAccessHandler will return OK, which is then denied by mod_access, resulting
> in a FORBIDDEN message.
>
> unlike with the PerlAuthenHandler, which immediately terminates on the first OK,
> the PerlAccessHandler will keep going in search of failure.
>
> > Has anybody gotten this to sucessfully work?
>
> yes :)
>
> you may be interested in chapter 13 of the cookbook, which should help clarify
> things somewhat.
>
> --Geoff
Re: mod_perl Basic Authentication problem using PerlAuthenHandler
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Jason wrote:
> In httpd.conf i have
> <Location /~jter>
[snip]
> Deny from all
> </Location>
[snip]
>
> It warns to the log file and returns.... But the problem is, why does my browser come up "forbidden"
I suspect "Deny from all" is the issue...
the PerlAccessHandler will run before the apache default mod_access gets the
chance to implement the Deny rule. on a successful login, your
PerlAccessHandler will return OK, which is then denied by mod_access, resulting
in a FORBIDDEN message.
unlike with the PerlAuthenHandler, which immediately terminates on the first OK,
the PerlAccessHandler will keep going in search of failure.
> Has anybody gotten this to sucessfully work?
yes :)
you may be interested in chapter 13 of the cookbook, which should help clarify
things somewhat.
--Geoff
mod_perl Basic Authentication problem using PerlAuthenHandler
Posted by Jason <jt...@cartmanager.net>.
In httpd.conf i have
<Location /~jter>
PerlAccessHandler ApacheAuthentication
PerlSetVar Intranet "65.103.229.188 => joe, 10.10.10.2 => userB"
PerlAuthenHandler ApacheAuthentication
AuthName realm
AuthType Basic
Require valid-user
Order deny,allow
Deny from all
</Location>
And my module is
package ApacheAuthentication;
#use strict;
use Apache::Constants qw(:common);
use Apache::URI;
use Apache::File;
sub handler {
my $r = shift;
# get user's authentication credentials
my ($res, $sent_pw) = $r->get_basic_auth_pw;
return $res if $res != OK;
my $user = $r->connection->user;
# authenticate through DBI
my $reason = authen_dbi($r, $user, $sent_pw);
if ($reason) {
$r->note_basic_auth_failure;
$r->log_reason($reason, $r->uri);
return AUTH_REQUIRED;
}
warn "FINISHED $user $sent_pw";
return OK;
}
It warns to the log file and returns.... But the problem is, why does my browser come up "forbidden"
Has anybody gotten this to sucessfully work?
Server Version: Apache/1.3.22 (Unix) PHP/4.0.6 mod_perl/1.26 mod_ssl/2.8.5 OpenSSL/0.9.6b
Thanks in advance
Re: framesets/AuthCookie question
Posted by Peter Bi <mo...@att.net>.
Michael:
It is great to see custom_error(). Last time, it took me a few hours in
hacking the whole module. :-(
>
> However, I dont think it will work for his problem because his javascript
code
> seems to launch a NEW REQUEST, thus loosing anything that was stored away
in
> $r->subprocess_env(). So the only viable option is to pass the error
codes in
> they url (as part of the query string) I think.
>
An extra cookie is another solution.
Peter Bi
----- Original Message -----
From: "Michael Schout" <ms...@gkg.net>
To: "Peter Bi" <mo...@att.net>
Cc: "Fran Fabrizio" <ff...@mmrd.com>; <mo...@apache.org>
Sent: Friday, April 19, 2002 9:44 AM
Subject: Re: framesets/AuthCookie question
> On Wed, 17 Apr 2002, Peter Bi wrote:
>
> > Fran:
> >
> > You may need to 1) add a few lines of code in AuthCookie to make your
error
> > code aware to other methods, and 2) have a dynamic login page that can
> > interpret the code. Alternatively, you may try AccessCookie I posted.
:-)
>
> The CVS version of AuthCookie has a custom_errors() hook in it that does
this
> sort of thing.
>
> However, I dont think it will work for his problem because his javascript
code
> seems to launch a NEW REQUEST, thus loosing anything that was stored away
in
> $r->subprocess_env(). So the only viable option is to pass the error
codes in
> they url (as part of the query string) I think.
>
> Mike
>
>
RE: framesets/AuthCookie question
Posted by Jeff Armstrong <je...@bircholme.com>.
I'm just a budding modperlie - is notes info maintained
across a server redirect?
$r->internal_redirect('/login?message=dont+go+there');
Jeff
-----Original Message-----
From: Michael Schout [mailto:mschout@gkg.net]
Sent: 19 April 2002 17:44
To: Peter Bi
Cc: Fran Fabrizio; modperl@apache.org
Subject: Re: framesets/AuthCookie question
On Wed, 17 Apr 2002, Peter Bi wrote:
> Fran:
>
> You may need to 1) add a few lines of code in AuthCookie to make your
error
> code aware to other methods, and 2) have a dynamic login page that
can
> interpret the code. Alternatively, you may try AccessCookie I posted.
:-)
The CVS version of AuthCookie has a custom_errors() hook in it that does
this
sort of thing.
However, I dont think it will work for his problem because his
javascript code
seems to launch a NEW REQUEST, thus loosing anything that was stored
away in
$r->subprocess_env(). So the only viable option is to pass the error
codes in
they url (as part of the query string) I think.
Mike
Re: framesets/AuthCookie question
Posted by Michael Schout <ms...@gkg.net>.
On Wed, 17 Apr 2002, Peter Bi wrote:
> Fran:
>
> You may need to 1) add a few lines of code in AuthCookie to make your error
> code aware to other methods, and 2) have a dynamic login page that can
> interpret the code. Alternatively, you may try AccessCookie I posted. :-)
The CVS version of AuthCookie has a custom_errors() hook in it that does this
sort of thing.
However, I dont think it will work for his problem because his javascript code
seems to launch a NEW REQUEST, thus loosing anything that was stored away in
$r->subprocess_env(). So the only viable option is to pass the error codes in
they url (as part of the query string) I think.
Mike
Re: framesets/AuthCookie question
Posted by Peter Bi <mo...@att.net>.
Fran:
You may need to 1) add a few lines of code in AuthCookie to make your error
code aware to other methods, and 2) have a dynamic login page that can
interpret the code. Alternatively, you may try AccessCookie I posted. :-)
In AccessCookie, you simply "return $error" from authenticate(), let login
page() catch the code and display corresponding instruction. I haven't
tested it in a frame set, but it should appear a login page with custom
instructions in the last window the user visited before the expiration time.
The user re-types login/password, then is redirected to the page he tried
before.
Peter Bi
----- Original Message -----
From: "Fran Fabrizio" <ff...@mmrd.com>
To: <mo...@apache.org>
Sent: Wednesday, April 17, 2002 3:01 PM
Subject: framesets/AuthCookie question
>
> I'm using AuthCookie and as some of you know, if it determines your
> session to be invalid it redirects to a login page instead by way of a
> FORBIDDEN response coupled with a custom error page.
>
> My app has a frameset (navigation on the left, and two data frames on
> the right). I know the evils of framesets, but in our case, it's the
> best way to present our particular data.
>
> What ends up happening is that if the session expires, AuthCookie
> displays the login page inside whatever frameset you were clicking in,
> while the other two remain on whatever they were on previously.
>
> I made a quick solution...I told AuthCookie that my login page was
> login.html. login.html had javascript which called /real/login (a
> mod_perl handler) and targeted it to the top frame. All is well and now
> the entire browser window gets cleared and replaced with the login page.
>
> However...I then thought it'd be neat to include on the /real/login page
> a message to tell them how they got there ("Your session has expired",
> "Your account has logged on from another location", "Invalid
> username/password combination", whatever...).
>
> At first I thought I could accomplish this by simply doing
> $r->notes('LOGINFAILMSG' => 'Your session has expired') if AuthCookie
> detected it to be thus, and then in my handler I could retrieve it and
> display it.
>
> However, it's failing of course because I added the extra redirection of
> the login.html w/ the javascript, which makes a round trip to the client
> and back, so it looks like a brand new request to mod_perl, thus, no
> notes() any more. Is there a solution to breaking out of the frameset
> AND propagating the reason for the logout to the /real/login page?
>
> I'd appreciate and and all ideas. Thanks!
>
> -Fran
>
>
>
Re: framesets/AuthCookie question
Posted by Michael Schout <ms...@gkg.net>.
On Mon, 22 Apr 2002, Fran Fabrizio wrote:
> It seems that even if AuthCookie returns a FORBIDDEN with a custom_error
> page set, the $r->notes() don't propagate. Does apache consider the
> display of the custom_response page to be a completely new request?
Its a subrequest, so the notes shold be in $r->prev->notes().
Mike
Re: framesets/AuthCookie question
Posted by Fran Fabrizio <ff...@mmrd.com>.
Followup from last week:
> I'm using AuthCookie and as some of you know, if it determines your
> session to be invalid it redirects to a login page instead by way of a
> FORBIDDEN response coupled with a custom_response error page.
[snip]
>...I then thought it'd be neat to include on the login page handler output
> a message to tell them how they got there ("Your session has expired",
> "Your account has logged on from another location", "Invalid
> username/password combination", whatever...).
>
> At first I thought I could accomplish this by simply doing
> $r->notes('LOGINFAILMSG' => 'Your session has expired') if AuthCookie
> detected it to be thus, and then in my handler I could retrieve it and
> display it.
New observations....
It seems that even if AuthCookie returns a FORBIDDEN with a custom_error
page set, the $r->notes() don't propagate. Does apache consider the
display of the custom_response page to be a completely new request?
-Fran
RE: framesets/AuthCookie question
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
>Is there a solution to breaking out of the frameset
>AND propagating the reason for the logout to the /real/login page?
>
>I'd appreciate and and all ideas. Thanks!
Well, if you're not against using a little JavaScript, the following
code within your <head> ... </head> tags will not allow the page it is
used on to be displayed within a frame. This may work in your scenario.
<script type="text/javascript"><!--
/* FrameBuster */
if (self.parent.frames.length != 0) {
self.parent.location="xxxxxxxx.xxx"; }
// end FrameBuster...
--></script>
Replace "xxxxxxxx.xxx" with the url of the page.
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
http://wypug.digital-word.com/
RE: framesets/AuthCookie question
Posted by Jeff <ja...@aquabolt.com>.
Sounds to me like your Javascript should be smarter?
ie it should ask top to open the full url including
any optional message.
Why not include this in your real login page:
<SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript">
<!--
// Frame buster
if ( top.location != document.location ) {
top.location = document.location;
}
// -->
</SCRIPT>
and your authentication should do a server redirect to
something like
/login?message=Inactivity+timeout
and the page can taint-check and display message
I no longer use this simple framebuster, as most of my
websites use multiple windows, so I have to cope with
/login being opened in a child window, and/or a frame.
For this I use a home-brewed openWindow() function and
a window naming scheme.
Regards
Jeff
PS I don't have much mod_perl yet, so excuse me if I err.
There may be a better mod_perilsh way.
-----Original Message-----
From: Fran Fabrizio [mailto:ffabrizio@mmrd.com]
Sent: 17 April 2002 23:01
To: modperl@apache.org
Subject: framesets/AuthCookie question
I'm using AuthCookie and as some of you know, if it determines your
session to be invalid it redirects to a login page instead by way of a
FORBIDDEN response coupled with a custom error page.
My app has a frameset (navigation on the left, and two data frames on
the right). I know the evils of framesets, but in our case, it's the
best way to present our particular data.
What ends up happening is that if the session expires, AuthCookie
displays the login page inside whatever frameset you were clicking in,
while the other two remain on whatever they were on previously.
I made a quick solution...I told AuthCookie that my login page was
login.html. login.html had javascript which called /real/login (a
mod_perl handler) and targeted it to the top frame. All is well and now
the entire browser window gets cleared and replaced with the login page.
However...I then thought it'd be neat to include on the /real/login page
a message to tell them how they got there ("Your session has expired",
"Your account has logged on from another location", "Invalid
username/password combination", whatever...).
At first I thought I could accomplish this by simply doing
$r->notes('LOGINFAILMSG' => 'Your session has expired') if AuthCookie
detected it to be thus, and then in my handler I could retrieve it and
display it.
However, it's failing of course because I added the extra redirection of
the login.html w/ the javascript, which makes a round trip to the client
and back, so it looks like a brand new request to mod_perl, thus, no
notes() any more. Is there a solution to breaking out of the frameset
AND propagating the reason for the logout to the /real/login page?
I'd appreciate and and all ideas. Thanks!
-Fran