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 <[EMAIL PROTECTED]>:
On 6/28/06, Cosma Colanicchia <[EMAIL PROTECTED]> wrote:
>
> 2006/6/28, Adam Winer <[EMAIL PROTECTED]>:
> > 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 <[EMAIL PROTECTED]> 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
