You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Cosma Colanicchia <co...@gmail.com> on 2006/07/03 10:30:59 UTC
Re: Re: Re: Re: FORM based authentication, and session timeouts
Ok, a first workaround:
(...)
<head>
<script type="text/javascript">
function checkPPR() {
if ("_pprIFrame" == window.name) {
window.parent.location = window.location;
}
}
</script>
</head>
<body onload="checkPPR();">
(...)
With this, when a PPR request is made after a session timeout, the
login page reload itself in the parent frame instead of the hidden
iframe.
There are some problems that aren't resolved yet:
1) After the login, however, the *previous* page is redisplayed, and
the user action is discarded (for example, it does not browse to the
requested list page). Maybe this is caused by some failover of PPR
response script, which normally "expects" to be loaded inside the
iframe and to find the old page in the outer one.
2) Modified fields are also lost. It looks like a new view is being
created, so also stuff already submitted and stored in the component
tree is lost.
Another more complex workaround may look like this:
(...)
<head>
<script type="text/javascript">
function checkPPR() {
var loginForm = document.getElementById("loginForm");
if ("_pprIFrame" == window.name) {
// Reload myself in a window with a fixed name
var loginWindow = window.open(window.location,
"PPRloginWindow", "menubar=0,resizable=1,width=350,height=250");
loginForm.location = window.location;
}
if ("PPRloginWindow" == window.name) {
// Now I'm in the window, set the target back to the hidden iframe
loginForm.target = "_pprIFrame";
}
}
function checkPPRClose() {
if ("PPRloginWindow" == window.name) {
setTimeout('window.close()', 3000);
}
}
</script>
</head>
<body onload="checkPPR();">
<!-- standard action and field names for contained managed security -->
<form id="loginForm" method="POST" action="j_security_check"
onsubmit="checkPPRClose();">
(...)
This way the login page, instead of reloading itself in the parent
frame, do it in a popup window (thus leaving the old page in the outer
frame), then makes this login window submit to the hidden iframe. This
way, in theory, the normal environment of a PPR request should be
recreated. However, don't know why, problem 1) still happens, while 2)
is resolved.
Cosma
2006/6/30, Adam Winer <aw...@gmail.com>:
> It's going to be tackled by a Summer of Code developer; no
> matter what happens, we'll get it in there.
>
> -- Adam
>
>
> On 6/30/06, Cosma Colanicchia <co...@gmail.com> wrote:
> > I'll try some dirty workaround (I have to take into account that my
> > app uses frames) waiting for XmlHttpRequest :) BTW, do we have any
> > plan for this?
> >
> > Thanks for the support
> > Cosma
> >
> >
> > 2006/6/30, Adam Winer <aw...@gmail.com>:
> > > Aw, crud. You're right. _partialChange() is called via
> > > a script that's included into the iframe content by Trinidad.
> > > And, obviously, is not there in the login page.
> > >
> > > OK, so the best I can imagine now is including a
> > > small Javascript in the login page, something like:
> > >
> > > if (window != top)
> > > top.document.location = window.document.location;
> > >
> > > The good news is that *all* of this is totally fixable when
> > > we switch from iframes to XmlHttpRequest.
> > >
> > > -- Adam
> > >
> > >
> > > On 6/30/06, Cosma Colanicchia <co...@gmail.com> wrote:
> > > > Adam, the _partialChange() code doesn't get fired after session
> > > > timeout. Also note this comment:
> > > >
> > > > /**
> > > > * Onload event handler for the partial iframe
> > > > */
> > > > function _partialChange(navigationFormName)
> > > > {
> > > >
> > > > If it is true, is the PPR response that trigger the javascript to
> > > > update the parent frame. I tried debugging that javascript, and
> > > > actually my breakpoints don't trigger (they do if my session doesn't
> > > > time out). I fear that we are out of control to handle this thing.
> > > >
> > > > Cosma
> > > >
> > > >
> > > >
> > > > 2006/6/28, Adam Winer <aw...@gmail.com>:
> > > > > On 6/28/06, Cosma Colanicchia <co...@gmail.com> wrote:
> > > > > >
> > > > > > 2006/6/28, Adam Winer <aw...@gmail.com>:
> > > > > > > I should note up front that container managed authentication is
> > > > > > > a horribly broken and misdesigned part of J2EE. This has been
> > > > > > > known by the servlet EG for ages, and they've done nothing
> > > > > > > about it. There's many, many problems - the fact that it doesn't
> > > > > > > work with PPR or AJAX is just the latest.
> > > > > >
> > > > > > I definitely agree..
> > > > > >
> > > > > > > Anyway, that rant aside:
> > > > > > >
> > > > > > > On 6/28/06, Cosma Colanicchia <co...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi Adam,
> > > > > > > >
> > > > > > > > I'm doing nothing, the container is :) OC4J seems to perform a forward
> > > > > > > > to display the configured login page. I don't think there's a way to
> > > > > > > > redirect. BTW, why do you think that a redirect should work?
> > > > > > >
> > > > > > >
> > > > > > > A redirect - if it happened via a call to ServletResponse.sendRedirect()
> > > > > > -
> > > > > > > would get caught by PPR and result in special PPR.
> > > > > >
> > > > > > This is interesting. Anyway, I tried to call
> > > > > > HttpServletResponse.sendRedirect() with a scriptlet in the jsp login
> > > > > > page, redirecting to itself (with a check to avoid a loop), but this
> > > > > > hasn't worked.
> > > > >
> > > > >
> > > > > No, I guess it wouldn't, not with the current PPR implementation; we do
> > > > > detect PPR redirects, but only if you've gone through the FacesServlet
> > > > > and JSF lifecycle - which hasn't happened here, of course.
> > > > >
> > > > > When we switch to XMLHttpRequests, we'll be able to catch redirects
> > > > > on the client and at least handle that scenario cleanly.
> > > > >
> > > > > > I'm trying to understand how PPR works, and I see that it basically
> > > > > > > > set the form target to an hidden IFRAME and add some particular
> > > > > > > > parameters to the request.. on server-side the response then includes
> > > > > > > > the new rendered html and some script to update the DOM of the outer
> > > > > > > > page.. is this right? If so, how could *redirect* vs *forward* affect
> > > > > > > > this behaviour?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > See above. :)
> > > > > > >
> > > > > > > I want try to code something in the login.jsp to *see* if I'm in a
> > > > > > > > PPR, this way I could return a fake response that immediately resubmit
> > > > > > > > to the login page itself, but specifing a different target than the
> > > > > > > > hidden iframe and disabling PPR. Some problems here::::::::::
> > > > > > >
> > > > > > > 1) I see that the request parameter "partial" is set to true on PPR
> > > > > > > > requests, I want to use that value as a trigger for this logic, but
> > > > > > > > OC4J cleans out the request and put all request information in some
> > > > > > > > session attributes. I don't want to code its specific session
> > > > > > > > attribute names into my page, possibly breaking other app server
> > > > > > > > support.
> > > > > > > >
> > > > > > > > 2) Which target should I use? I can't open a popup because it would
> > > > > > > > break the stuff after the login. I'd like to find the same target in
> > > > > > > > which the parent page (the one that contains the IFRAME) is loaded..
> > > > > > > > I'm not sure if this can be done with javascript in a standard manner,
> > > > > > > > maybe someone can help me on this?
> > > > > > > >
> > > > > > > > 3) Can I safely disable PPR simply removing some request parameters? I
> > > > > > > > want to render a normal page, complete and without the special
> > > > > > > > javascript method, because I'm now going to replace the page content
> > > > > > > > itself and not the IFRAME.
> > > > > > > >
> > > > > > > >
> > > > > > > > What do you think about this approach? I think it's a mess :) there
> > > > > > > > must be someway to workaround this problem!
> > > > > > >
> > > > > > >
> > > > > > > I've got another idea: in the Javascript for handling the PPR response,
> > > > > > > if we searched to see if the content was for a container-managed
> > > > > > > authentication page - perhaps by searching for "j_security_check"?
> > > > > > > If we detect that it is, force a reload of the entire page. Not
> > > > > > > perfect, but I think it would avoid the worst of it.
> > > > > > >
> > > > > > > -- Adam
> > > > > > >
> > > > > >
> > > > > > This is exactly what I was trying to obtain "by hand" :) The three
> > > > > > problem could be solved more easily inside the Trinidad scope, but it
> > > > > > seems that the javascript that handle the PPR response is part of the
> > > > > > PPR response itself (thus missing after the login forward), isn't it?
> > > > >
> > > > >
> > > > > The Javascript that handles the response is in PPR.js, in
> > > > > _partialChange() - so that code could be modified to look for
> > > > > j_security_check, perhaps, and redirect the outer page.
> > > > >
> > > > > -- Adam
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Re: Re: Re: FORM based authentication, and session timeouts
Posted by Cosma Colanicchia <co...@gmail.com>.
Note that workaround #2 also as a big problem: the script that closes
the popup window will trigger also when login page is wrong. The
workaround of the workaround is to put
a script also in the "loginError" that, as the login one, reload
itself in a popup if it is rendered inside the _pprIFrame.
Dealing with all this stuff is really bad! :)
Cosma
2006/7/3, Cosma Colanicchia <co...@gmail.com>:
> Ok, a first workaround:
>
> (...)
> <head>
> <script type="text/javascript">
> function checkPPR() {
> if ("_pprIFrame" == window.name) {
> window.parent.location = window.location;
> }
> }
> </script>
> </head>
> <body onload="checkPPR();">
> (...)
>
> With this, when a PPR request is made after a session timeout, the
> login page reload itself in the parent frame instead of the hidden
> iframe.
>
> There are some problems that aren't resolved yet:
>
> 1) After the login, however, the *previous* page is redisplayed, and
> the user action is discarded (for example, it does not browse to the
> requested list page). Maybe this is caused by some failover of PPR
> response script, which normally "expects" to be loaded inside the
> iframe and to find the old page in the outer one.
>
> 2) Modified fields are also lost. It looks like a new view is being
> created, so also stuff already submitted and stored in the component
> tree is lost.
>
>
> Another more complex workaround may look like this:
>
> (...)
> <head>
> <script type="text/javascript">
> function checkPPR() {
> var loginForm = document.getElementById("loginForm");
> if ("_pprIFrame" == window.name) {
> // Reload myself in a window with a fixed name
> var loginWindow = window.open(window.location,
> "PPRloginWindow", "menubar=0,resizable=1,width=350,height=250");
> loginForm.location = window.location;
> }
> if ("PPRloginWindow" == window.name) {
> // Now I'm in the window, set the target back to the hidden iframe
> loginForm.target = "_pprIFrame";
> }
> }
> function checkPPRClose() {
> if ("PPRloginWindow" == window.name) {
> setTimeout('window.close()', 3000);
> }
> }
> </script>
> </head>
> <body onload="checkPPR();">
> <!-- standard action and field names for contained managed security -->
> <form id="loginForm" method="POST" action="j_security_check"
> onsubmit="checkPPRClose();">
> (...)
>
> This way the login page, instead of reloading itself in the parent
> frame, do it in a popup window (thus leaving the old page in the outer
> frame), then makes this login window submit to the hidden iframe. This
> way, in theory, the normal environment of a PPR request should be
> recreated. However, don't know why, problem 1) still happens, while 2)
> is resolved.
>
> Cosma
>
>
> 2006/6/30, Adam Winer <aw...@gmail.com>:
> > It's going to be tackled by a Summer of Code developer; no
> > matter what happens, we'll get it in there.
> >
> > -- Adam
> >
> >
> > On 6/30/06, Cosma Colanicchia <co...@gmail.com> wrote:
> > > I'll try some dirty workaround (I have to take into account that my
> > > app uses frames) waiting for XmlHttpRequest :) BTW, do we have any
> > > plan for this?
> > >
> > > Thanks for the support
> > > Cosma
> > >
> > >
> > > 2006/6/30, Adam Winer <aw...@gmail.com>:
> > > > Aw, crud. You're right. _partialChange() is called via
> > > > a script that's included into the iframe content by Trinidad.
> > > > And, obviously, is not there in the login page.
> > > >
> > > > OK, so the best I can imagine now is including a
> > > > small Javascript in the login page, something like:
> > > >
> > > > if (window != top)
> > > > top.document.location = window.document.location;
> > > >
> > > > The good news is that *all* of this is totally fixable when
> > > > we switch from iframes to XmlHttpRequest.
> > > >
> > > > -- Adam
> > > >
> > > >
> > > > On 6/30/06, Cosma Colanicchia <co...@gmail.com> wrote:
> > > > > Adam, the _partialChange() code doesn't get fired after session
> > > > > timeout. Also note this comment:
> > > > >
> > > > > /**
> > > > > * Onload event handler for the partial iframe
> > > > > */
> > > > > function _partialChange(navigationFormName)
> > > > > {
> > > > >
> > > > > If it is true, is the PPR response that trigger the javascript to
> > > > > update the parent frame. I tried debugging that javascript, and
> > > > > actually my breakpoints don't trigger (they do if my session doesn't
> > > > > time out). I fear that we are out of control to handle this thing.
> > > > >
> > > > > Cosma
> > > > >
> > > > >
> > > > >
> > > > > 2006/6/28, Adam Winer <aw...@gmail.com>:
> > > > > > On 6/28/06, Cosma Colanicchia <co...@gmail.com> wrote:
> > > > > > >
> > > > > > > 2006/6/28, Adam Winer <aw...@gmail.com>:
> > > > > > > > I should note up front that container managed authentication is
> > > > > > > > a horribly broken and misdesigned part of J2EE. This has been
> > > > > > > > known by the servlet EG for ages, and they've done nothing
> > > > > > > > about it. There's many, many problems - the fact that it doesn't
> > > > > > > > work with PPR or AJAX is just the latest.
> > > > > > >
> > > > > > > I definitely agree..
> > > > > > >
> > > > > > > > Anyway, that rant aside:
> > > > > > > >
> > > > > > > > On 6/28/06, Cosma Colanicchia <co...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Adam,
> > > > > > > > >
> > > > > > > > > I'm doing nothing, the container is :) OC4J seems to perform a forward
> > > > > > > > > to display the configured login page. I don't think there's a way to
> > > > > > > > > redirect. BTW, why do you think that a redirect should work?
> > > > > > > >
> > > > > > > >
> > > > > > > > A redirect - if it happened via a call to ServletResponse.sendRedirect()
> > > > > > > -
> > > > > > > > would get caught by PPR and result in special PPR.
> > > > > > >
> > > > > > > This is interesting. Anyway, I tried to call
> > > > > > > HttpServletResponse.sendRedirect() with a scriptlet in the jsp login
> > > > > > > page, redirecting to itself (with a check to avoid a loop), but this
> > > > > > > hasn't worked.
> > > > > >
> > > > > >
> > > > > > No, I guess it wouldn't, not with the current PPR implementation; we do
> > > > > > detect PPR redirects, but only if you've gone through the FacesServlet
> > > > > > and JSF lifecycle - which hasn't happened here, of course.
> > > > > >
> > > > > > When we switch to XMLHttpRequests, we'll be able to catch redirects
> > > > > > on the client and at least handle that scenario cleanly.
> > > > > >
> > > > > > > I'm trying to understand how PPR works, and I see that it basically
> > > > > > > > > set the form target to an hidden IFRAME and add some particular
> > > > > > > > > parameters to the request.. on server-side the response then includes
> > > > > > > > > the new rendered html and some script to update the DOM of the outer
> > > > > > > > > page.. is this right? If so, how could *redirect* vs *forward* affect
> > > > > > > > > this behaviour?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > See above. :)
> > > > > > > >
> > > > > > > > I want try to code something in the login.jsp to *see* if I'm in a
> > > > > > > > > PPR, this way I could return a fake response that immediately resubmit
> > > > > > > > > to the login page itself, but specifing a different target than the
> > > > > > > > > hidden iframe and disabling PPR. Some problems here::::::::::
> > > > > > > >
> > > > > > > > 1) I see that the request parameter "partial" is set to true on PPR
> > > > > > > > > requests, I want to use that value as a trigger for this logic, but
> > > > > > > > > OC4J cleans out the request and put all request information in some
> > > > > > > > > session attributes. I don't want to code its specific session
> > > > > > > > > attribute names into my page, possibly breaking other app server
> > > > > > > > > support.
> > > > > > > > >
> > > > > > > > > 2) Which target should I use? I can't open a popup because it would
> > > > > > > > > break the stuff after the login. I'd like to find the same target in
> > > > > > > > > which the parent page (the one that contains the IFRAME) is loaded..
> > > > > > > > > I'm not sure if this can be done with javascript in a standard manner,
> > > > > > > > > maybe someone can help me on this?
> > > > > > > > >
> > > > > > > > > 3) Can I safely disable PPR simply removing some request parameters? I
> > > > > > > > > want to render a normal page, complete and without the special
> > > > > > > > > javascript method, because I'm now going to replace the page content
> > > > > > > > > itself and not the IFRAME.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > What do you think about this approach? I think it's a mess :) there
> > > > > > > > > must be someway to workaround this problem!
> > > > > > > >
> > > > > > > >
> > > > > > > > I've got another idea: in the Javascript for handling the PPR response,
> > > > > > > > if we searched to see if the content was for a container-managed
> > > > > > > > authentication page - perhaps by searching for "j_security_check"?
> > > > > > > > If we detect that it is, force a reload of the entire page. Not
> > > > > > > > perfect, but I think it would avoid the worst of it.
> > > > > > > >
> > > > > > > > -- Adam
> > > > > > > >
> > > > > > >
> > > > > > > This is exactly what I was trying to obtain "by hand" :) The three
> > > > > > > problem could be solved more easily inside the Trinidad scope, but it
> > > > > > > seems that the javascript that handle the PPR response is part of the
> > > > > > > PPR response itself (thus missing after the login forward), isn't it?
> > > > > >
> > > > > >
> > > > > > The Javascript that handles the response is in PPR.js, in
> > > > > > _partialChange() - so that code could be modified to look for
> > > > > > j_security_check, perhaps, and redirect the outer page.
> > > > > >
> > > > > > -- Adam
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>