incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cosma Colanicchia" <cosma...@gmail.com>
Subject Re: Re: Re: Re: FORM based authentication, <af:table> and session timeouts
Date Mon, 03 Jul 2006 11:00:32 GMT
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 <cosmacol@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 <awiner@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 <cosmacol@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 <awiner@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 <cosmacol@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 <awiner@gmail.com>:
> > > > > > On 6/28/06, Cosma Colanicchia <cosmacol@gmail.com> wrote:
> > > > > > >
> > > > > > > 2006/6/28, Adam Winer <awiner@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 <cosmacol@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
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
View raw message