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?
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? 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! Thank you Cosma 2006/6/28, Adam Winer <[EMAIL PROTECTED]>:
It's a bit of a tricky thing. Big question: are you doing a server-side redirect or a client-side redirect? I believe that the client-side redirect should work with PPR, while the server-side redirect won't. We spent awhile trying to do full-page DOM replacement in response to PPR and ran into an endless series of browser bugs - then gave up. -- Adam On 6/27/06, Cosma Colanicchia <[EMAIL PROTECTED]> wrote: > Am I the only one out there trying to use form-based authentication > with MyFaces/Trinidad? :) I like trying to fix things myself when I > can, but I think that the Trinidad PPR stuff is out of reach for now.. > > Any help would be very appreciated > Cosma > > > 2006/6/23, Cosma Colanicchia <[EMAIL PROTECTED]>: > > http://issues.apache.org/jira/browse/ADFFACES-37 > > > > 2006/6/23, Cosma Colanicchia <[EMAIL PROTECTED]>: > > > I put a <jsp:scriptlet> in my login page with a System.out.println... > > > well, it is being processed! But in the result page there is no trace > > > of it. The login page is completely discarded, even if the browser > > > seems to refresh the page, the same content is redisplayed (without > > > any JSF processing). > > > > > > Big, big problem.. maybe XmlHttpRequest has better support for > > > container managed security, but in the meantime? > > > > > > I'm opening a JIRA for this issue. > > > > > > Cosma > > > > > > > > > 2006/6/23, Cosma Colanicchia <[EMAIL PROTECTED]>: > > > > Hi, > > > > > > > > I need paginated <af:table>s in a webapp configured to use form based > > > > authentication. Normally, on session time outs, the container saves > > > > all the request information in session, brings me on the login page > > > > and then "replay" the original request. This usually works fine with > > > > STATE_SAVING_METHOD "client" and CLIENT_STATE_METHOD "all" and a wise > > > > usage of session-scoped managed beans. > > > > > > > > But if there was an <af:table> on the page when the session timed out, > > > > and I try to navigate on another page, something is going wrong: the > > > > same view is redisplayed, no login, no new table page. I suspected the > > > > problem was related to PPR, so I tried to set partialTrigger="false" > > > > on my <afh:body> and on <af:table>, but this didn't solved anything. > > > > > > > > If I disable the authentication in my web.xml the problems doesn't happen. > > > > > > > > The container on which I'm testing is the OC4J embedded in JDeveloper > > > > 10.1.3. Please can someone helps me with this? I'm spending much work > > > > to make the webapp session timeout tollerant, it is a strong > > > > requirement for our environment, and this is a real show stopper. > > > > > > > > Thanks in advance > > > > Cosma > > > > > > > > > >
