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 10:30:59 GMT
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