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:53:54 GMT
Hi Cosma,

I am sorry I did not understand the problem fully. Can you take the content
of the IFrame document and put it in the main page document in case of a
failure  instead of doing a full page refresh?

Venkata

On 7/18/06, Cosma Colanicchia <cosmacol@gmail.com> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message