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:27:14 GMT
Sorry I mean window.top.location :)



On 7/18/06, venkata guddanti <venkata.guddanti@gmail.com> wrote:
>
>  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