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
