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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]> 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 <[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
> >
> >
>
