Re: framesets/AuthCookie question
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
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
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:[EMAIL PROTECTED]]
Sent: 19 April 2002 17:44
To: Peter Bi
Cc: Fran Fabrizio; [EMAIL PROTECTED]
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
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" <[EMAIL PROTECTED]> To: "Peter Bi" <[EMAIL PROTECTED]> Cc: "Fran Fabrizio" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> 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
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
>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 ... tags will not allow the page it is used on to be displayed within a frame. This may work in your scenario. Replace ".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
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:
<!--
// Frame buster
if ( top.location != document.location ) {
top.location = document.location;
}
// -->
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:[EMAIL PROTECTED]]
Sent: 17 April 2002 23:01
To: [EMAIL PROTECTED]
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
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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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
>
>
>
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
