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/06/23 08:32:48 UTC
FORM based authentication, and session timeouts
Hi,
I need paginated <af:table>s in a webapp configured to use form based
authentication. Normally, on session time outs, the container saves
all the request information in session, brings me on the login page
and then "replay" the original request. This usually works fine with
STATE_SAVING_METHOD "client" and CLIENT_STATE_METHOD "all" and a wise
usage of session-scoped managed beans.
But if there was an <af:table> on the page when the session timed out,
and I try to navigate on another page, something is going wrong: the
same view is redisplayed, no login, no new table page. I suspected the
problem was related to PPR, so I tried to set partialTrigger="false"
on my <afh:body> and on <af:table>, but this didn't solved anything.
If I disable the authentication in my web.xml the problems doesn't happen.
The container on which I'm testing is the OC4J embedded in JDeveloper
10.1.3. Please can someone helps me with this? I'm spending much work
to make the webapp session timeout tollerant, it is a strong
requirement for our environment, and this is a real show stopper.
Thanks in advance
Cosma
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
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Re: Re: Re: FORM based authentication, and session timeouts
Posted by 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
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Re: Re: Re: FORM based authentication, and session timeouts
Posted by 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: FORM based authentication, and session timeouts
Posted by Cosma Colanicchia <co...@gmail.com>.
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: FORM based authentication, and session timeouts
Posted by 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: FORM based authentication, and session timeouts
Posted by Cosma Colanicchia <co...@gmail.com>.
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: FORM based authentication, and session timeouts
Posted by 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: FORM based authentication, and session timeouts
Posted by Cosma Colanicchia <co...@gmail.com>.
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.
> 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?
Re: Re: FORM based authentication, and session timeouts
Posted by 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.
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.
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
Re: Re: FORM based authentication, and session timeouts
Posted by Cosma Colanicchia <co...@gmail.com>.
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?
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?
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!
Thank you
Cosma
2006/6/28, Adam Winer <aw...@gmail.com>:
> It's a bit of a tricky thing. Big question: are you doing a
> server-side redirect or a client-side redirect? I believe that
> the client-side redirect should work with PPR, while the
> server-side redirect won't. We spent awhile trying to do
> full-page DOM replacement in response to PPR and ran
> into an endless series of browser bugs - then gave up.
>
> -- Adam
>
>
> On 6/27/06, Cosma Colanicchia <co...@gmail.com> wrote:
> > Am I the only one out there trying to use form-based authentication
> > with MyFaces/Trinidad? :) I like trying to fix things myself when I
> > can, but I think that the Trinidad PPR stuff is out of reach for now..
> >
> > Any help would be very appreciated
> > Cosma
> >
> >
> > 2006/6/23, Cosma Colanicchia <co...@gmail.com>:
> > > http://issues.apache.org/jira/browse/ADFFACES-37
> > >
> > > 2006/6/23, Cosma Colanicchia <co...@gmail.com>:
> > > > I put a <jsp:scriptlet> in my login page with a System.out.println...
> > > > well, it is being processed! But in the result page there is no trace
> > > > of it. The login page is completely discarded, even if the browser
> > > > seems to refresh the page, the same content is redisplayed (without
> > > > any JSF processing).
> > > >
> > > > Big, big problem.. maybe XmlHttpRequest has better support for
> > > > container managed security, but in the meantime?
> > > >
> > > > I'm opening a JIRA for this issue.
> > > >
> > > > Cosma
> > > >
> > > >
> > > > 2006/6/23, Cosma Colanicchia <co...@gmail.com>:
> > > > > Hi,
> > > > >
> > > > > I need paginated <af:table>s in a webapp configured to use form based
> > > > > authentication. Normally, on session time outs, the container saves
> > > > > all the request information in session, brings me on the login page
> > > > > and then "replay" the original request. This usually works fine with
> > > > > STATE_SAVING_METHOD "client" and CLIENT_STATE_METHOD "all" and a wise
> > > > > usage of session-scoped managed beans.
> > > > >
> > > > > But if there was an <af:table> on the page when the session timed out,
> > > > > and I try to navigate on another page, something is going wrong: the
> > > > > same view is redisplayed, no login, no new table page. I suspected the
> > > > > problem was related to PPR, so I tried to set partialTrigger="false"
> > > > > on my <afh:body> and on <af:table>, but this didn't solved anything.
> > > > >
> > > > > If I disable the authentication in my web.xml the problems doesn't happen.
> > > > >
> > > > > The container on which I'm testing is the OC4J embedded in JDeveloper
> > > > > 10.1.3. Please can someone helps me with this? I'm spending much work
> > > > > to make the webapp session timeout tollerant, it is a strong
> > > > > requirement for our environment, and this is a real show stopper.
> > > > >
> > > > > Thanks in advance
> > > > > Cosma
> > > > >
> > > >
> > >
> >
>
Re: Re: FORM based authentication, and session timeouts
Posted by Adam Winer <aw...@gmail.com>.
It's a bit of a tricky thing. Big question: are you doing a
server-side redirect or a client-side redirect? I believe that
the client-side redirect should work with PPR, while the
server-side redirect won't. We spent awhile trying to do
full-page DOM replacement in response to PPR and ran
into an endless series of browser bugs - then gave up.
-- Adam
On 6/27/06, Cosma Colanicchia <co...@gmail.com> wrote:
> Am I the only one out there trying to use form-based authentication
> with MyFaces/Trinidad? :) I like trying to fix things myself when I
> can, but I think that the Trinidad PPR stuff is out of reach for now..
>
> Any help would be very appreciated
> Cosma
>
>
> 2006/6/23, Cosma Colanicchia <co...@gmail.com>:
> > http://issues.apache.org/jira/browse/ADFFACES-37
> >
> > 2006/6/23, Cosma Colanicchia <co...@gmail.com>:
> > > I put a <jsp:scriptlet> in my login page with a System.out.println...
> > > well, it is being processed! But in the result page there is no trace
> > > of it. The login page is completely discarded, even if the browser
> > > seems to refresh the page, the same content is redisplayed (without
> > > any JSF processing).
> > >
> > > Big, big problem.. maybe XmlHttpRequest has better support for
> > > container managed security, but in the meantime?
> > >
> > > I'm opening a JIRA for this issue.
> > >
> > > Cosma
> > >
> > >
> > > 2006/6/23, Cosma Colanicchia <co...@gmail.com>:
> > > > Hi,
> > > >
> > > > I need paginated <af:table>s in a webapp configured to use form based
> > > > authentication. Normally, on session time outs, the container saves
> > > > all the request information in session, brings me on the login page
> > > > and then "replay" the original request. This usually works fine with
> > > > STATE_SAVING_METHOD "client" and CLIENT_STATE_METHOD "all" and a wise
> > > > usage of session-scoped managed beans.
> > > >
> > > > But if there was an <af:table> on the page when the session timed out,
> > > > and I try to navigate on another page, something is going wrong: the
> > > > same view is redisplayed, no login, no new table page. I suspected the
> > > > problem was related to PPR, so I tried to set partialTrigger="false"
> > > > on my <afh:body> and on <af:table>, but this didn't solved anything.
> > > >
> > > > If I disable the authentication in my web.xml the problems doesn't happen.
> > > >
> > > > The container on which I'm testing is the OC4J embedded in JDeveloper
> > > > 10.1.3. Please can someone helps me with this? I'm spending much work
> > > > to make the webapp session timeout tollerant, it is a strong
> > > > requirement for our environment, and this is a real show stopper.
> > > >
> > > > Thanks in advance
> > > > Cosma
> > > >
> > >
> >
>
Re: FORM based authentication, and session timeouts
Posted by Cosma Colanicchia <co...@gmail.com>.
Am I the only one out there trying to use form-based authentication
with MyFaces/Trinidad? :) I like trying to fix things myself when I
can, but I think that the Trinidad PPR stuff is out of reach for now..
Any help would be very appreciated
Cosma
2006/6/23, Cosma Colanicchia <co...@gmail.com>:
> http://issues.apache.org/jira/browse/ADFFACES-37
>
> 2006/6/23, Cosma Colanicchia <co...@gmail.com>:
> > I put a <jsp:scriptlet> in my login page with a System.out.println...
> > well, it is being processed! But in the result page there is no trace
> > of it. The login page is completely discarded, even if the browser
> > seems to refresh the page, the same content is redisplayed (without
> > any JSF processing).
> >
> > Big, big problem.. maybe XmlHttpRequest has better support for
> > container managed security, but in the meantime?
> >
> > I'm opening a JIRA for this issue.
> >
> > Cosma
> >
> >
> > 2006/6/23, Cosma Colanicchia <co...@gmail.com>:
> > > Hi,
> > >
> > > I need paginated <af:table>s in a webapp configured to use form based
> > > authentication. Normally, on session time outs, the container saves
> > > all the request information in session, brings me on the login page
> > > and then "replay" the original request. This usually works fine with
> > > STATE_SAVING_METHOD "client" and CLIENT_STATE_METHOD "all" and a wise
> > > usage of session-scoped managed beans.
> > >
> > > But if there was an <af:table> on the page when the session timed out,
> > > and I try to navigate on another page, something is going wrong: the
> > > same view is redisplayed, no login, no new table page. I suspected the
> > > problem was related to PPR, so I tried to set partialTrigger="false"
> > > on my <afh:body> and on <af:table>, but this didn't solved anything.
> > >
> > > If I disable the authentication in my web.xml the problems doesn't happen.
> > >
> > > The container on which I'm testing is the OC4J embedded in JDeveloper
> > > 10.1.3. Please can someone helps me with this? I'm spending much work
> > > to make the webapp session timeout tollerant, it is a strong
> > > requirement for our environment, and this is a real show stopper.
> > >
> > > Thanks in advance
> > > Cosma
> > >
> >
>
Re: FORM based authentication, and session timeouts
Posted by Cosma Colanicchia <co...@gmail.com>.
http://issues.apache.org/jira/browse/ADFFACES-37
2006/6/23, Cosma Colanicchia <co...@gmail.com>:
> I put a <jsp:scriptlet> in my login page with a System.out.println...
> well, it is being processed! But in the result page there is no trace
> of it. The login page is completely discarded, even if the browser
> seems to refresh the page, the same content is redisplayed (without
> any JSF processing).
>
> Big, big problem.. maybe XmlHttpRequest has better support for
> container managed security, but in the meantime?
>
> I'm opening a JIRA for this issue.
>
> Cosma
>
>
> 2006/6/23, Cosma Colanicchia <co...@gmail.com>:
> > Hi,
> >
> > I need paginated <af:table>s in a webapp configured to use form based
> > authentication. Normally, on session time outs, the container saves
> > all the request information in session, brings me on the login page
> > and then "replay" the original request. This usually works fine with
> > STATE_SAVING_METHOD "client" and CLIENT_STATE_METHOD "all" and a wise
> > usage of session-scoped managed beans.
> >
> > But if there was an <af:table> on the page when the session timed out,
> > and I try to navigate on another page, something is going wrong: the
> > same view is redisplayed, no login, no new table page. I suspected the
> > problem was related to PPR, so I tried to set partialTrigger="false"
> > on my <afh:body> and on <af:table>, but this didn't solved anything.
> >
> > If I disable the authentication in my web.xml the problems doesn't happen.
> >
> > The container on which I'm testing is the OC4J embedded in JDeveloper
> > 10.1.3. Please can someone helps me with this? I'm spending much work
> > to make the webapp session timeout tollerant, it is a strong
> > requirement for our environment, and this is a real show stopper.
> >
> > Thanks in advance
> > Cosma
> >
>
Re: FORM based authentication, and session timeouts
Posted by Cosma Colanicchia <co...@gmail.com>.
I put a <jsp:scriptlet> in my login page with a System.out.println...
well, it is being processed! But in the result page there is no trace
of it. The login page is completely discarded, even if the browser
seems to refresh the page, the same content is redisplayed (without
any JSF processing).
Big, big problem.. maybe XmlHttpRequest has better support for
container managed security, but in the meantime?
I'm opening a JIRA for this issue.
Cosma
2006/6/23, Cosma Colanicchia <co...@gmail.com>:
> Hi,
>
> I need paginated <af:table>s in a webapp configured to use form based
> authentication. Normally, on session time outs, the container saves
> all the request information in session, brings me on the login page
> and then "replay" the original request. This usually works fine with
> STATE_SAVING_METHOD "client" and CLIENT_STATE_METHOD "all" and a wise
> usage of session-scoped managed beans.
>
> But if there was an <af:table> on the page when the session timed out,
> and I try to navigate on another page, something is going wrong: the
> same view is redisplayed, no login, no new table page. I suspected the
> problem was related to PPR, so I tried to set partialTrigger="false"
> on my <afh:body> and on <af:table>, but this didn't solved anything.
>
> If I disable the authentication in my web.xml the problems doesn't happen.
>
> The container on which I'm testing is the OC4J embedded in JDeveloper
> 10.1.3. Please can someone helps me with this? I'm spending much work
> to make the webapp session timeout tollerant, it is a strong
> requirement for our environment, and this is a real show stopper.
>
> Thanks in advance
> Cosma
>