incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cosma Colanicchia" <cosma...@gmail.com>
Subject Re: PPR and session timeout
Date Tue, 18 Jul 2006 21:39:42 GMT
Venkata,

maybe I'm not getting your point, by in my script I'm trying to avoid
a "full page refresh". As I'm trying to keep my app as "session
timeout-proof" as possible, I use full client state saving and almost
all my managed bean are request scoped. Said that, I want the original
request parameters (so including the serialized component tree state)
to pass throught the login process, and because that was a PPR
requests I cannot simply load it as it was the main page (PPR response
seems to me to be potentially incomplete, only including the required
html elements and the code to replace them in the outer window). Even
knowing exactly what makes a request a "PPR" one, I'm not sure that it
is possible to safely revert it to a full request.

So my solution was to simply have the login page showed someway, but
without breaking the usual PPR process, so the popup that submit
itself again into the _pprIFRAME. I had no full success with it,
because sometimes after the login the original action (a list sort,
for example) doesn't get executed, and the user must click again. I've
not researched the reasons of this.

Regards
Cosma

2006/7/18, venkata guddanti <venkata.guddanti@gmail.com>:
> 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
View raw message