incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "venkata guddanti" <venkata.gudda...@gmail.com>
Subject Re: PPR and session timeout
Date Tue, 18 Jul 2006 21:25:27 GMT
Can't the checkPPR function do the following:


 if ("_pprIFrame" == window.name) {

    var replaceUrl = window.location.href;

    window.location.replace(replaceUrl);

}

to do a full page refresh?

Venkata



On 7/18/06, Scott O'Bryan <darkarena@gmail.com> wrote:
>
> I'll take a look at the thread, but have you thought about linking
> something in through the filter?
>
> Cosma Colanicchia wrote:
> > Scott,
> >
> > that would be the solution, but I haven't found a way to implement it,
> > and I doubt that it exists. You can read the details in the thread I
> > linked in my last reply.. anyway the problem is that the servlet
> > container, after a session timeout, forwards any requests to the login
> > page *without* triggering any filter or servlet. So, there is just no
> > way to "get in the middle" and abort the PPR request for a full page
> > one. No hooks with servlets, filters, phaselisteners etc.
> >
> > The fact that the current implementation of PPR is based on hidden
> > IFRAMEs makes thing more difficult, because it assumes that the
> > returned page (the one loaded into the hidden iframe) will contain the
> > logic to update the outer frame DOM. The user action only fires a
> > request with some "magic" parameters to activate PPR and then forget
> > about it. No hooks on the page that invokes the PPR request to "see"
> > what the response is. But when a session timeout occours, the returned
> > page will be the login one and, of course, the PPR update logic will
> > not be executed. Se no hooks in the PPR response logic neither..
> >
> > Due to the questionable design of container managed security (no API),
> > I see only two solutions: the first is to put some special logic on
> > the login page (my workaround), the other is to change the
> > implementation of PPR so that the "invoking page" script will not
> > forget about its request, but instead wait for the response, look into
> > it and update the DOM. That logic could then also check if the
> > returned page is a "login" and take some action. This could be
> > obtained switching to XMLHttpRequest instead of the hidden IFRAME to
> > perform PPR, and it seems that this will be done in a near future.
> >
> > Regards
> > Cosma
> >
> >
> > 2006/7/18, Scott O'Bryan <darkarena@gmail.com>:
> >> Can't we just do a full-page refresh if the session is timed out?
> >>
> >> Cosma Colanicchia wrote:
> >> > There was a discussion about this problem, see this thread in the
> >> > archives for the details:
> >> >
> >>
> http://mail-archives.apache.org/mod_mbox/incubator-adffaces-dev/200606.mbox/browser
> >>
> >> >
> >> >
> >> > I've found a tricky workaround, that involves putting some javascript
> >> > in your login page to make it open itself in a popup window when its
> >> > loaded in the ppr iframe:
> >> >
> >> >  <script type="text/javascript">
> >> >
> >> >    // NOTE this is a workaround for an issue when using Trinidad
> >> >    // PPR requests and container-managed security
> >> >
> >> >    // This is a temporary workaround while waiting for Trinidad to
> use
> >> >    // XmlHTTPRequest instead of hidden IFRAMEs for partial page
> >> rendering
> >> >
> >> >    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() {
> >> >      // This script trigger also when the login is wrong.. so the
> >> >      // "login failed" page must also do something to show
> >> >      // itself outside of the hidden iframe.
> >> >      if ("_pprLoginWindow" == window.name) {
> >> >        // The timeout is required to allow performing
> >> >        // the form submit before closing the window
> >> >        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();">
> >> >
> >> >
> >> > Far from perfect, but it allows the user to escape from the lock that
> >> > would occours otherwise. If you come up with a better solution please
> >> > share it.
> >> >
> >> >
> >> > regards
> >> > Cosma
> >> >
> >> > 2006/7/18, Jeantine Mankelow <jeantine@corp.peace.com>:
> >> >> We are using adf's ppr features in our web based product.  This all
> >> >> works fine until the session times out and the users tries to do
> >> >> something which would cause a ppr on the already loaded page.  To
> the
> >> >> user if appears as if nothing happens, when in fact what is
> >> happening is
> >> >> the login page is getting rendered in the iFrame.
> >> >>
> >> >> Any ideas on how we can direct the page the user can see to the
> login
> >> >> page?
> >> >>
> >> >> Thanks,
> >> >> Jeantine
> >> >>
> >> >
> >>
> >>
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message