2

I have a login page that is not protected and is accessible via different navigation-cases.

The problem: many users access that login page and leave it open for a while before then sign in again. Boom! The terrible ViewExpiredException occurs! I would like to avoid the ViewExpiredException let them sign in again anyway. I don't want a workaround for all the views, but only the sign on page.

I can't migrate to JSF2 (for budget reasons).

I have this configuration: 

javax.faces.STATE_SAVING_METHOD = server

that I can't change (we have a limited bandwith and mechanisms that block http request bigger than a small form page with very limited input fields.

Any idea?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
pmartin8
  • 1,545
  • 1
  • 20
  • 36
  • 2
    If you're using Mojarra (not MyFaces), you can only configure it for the entire application (not a single page) by setting context param `com.sun.faces.enableRestoreView11Compatibility` to `true`. Is this acceptable? – BalusC Mar 04 '16 at 15:28
  • Well, maybe! What will happen in other pages when the view is expired? Will I get some 'WTF' experience as you said in a previous post ? – pmartin8 Mar 04 '16 at 15:44
  • 1
    Only if you're relying on view scoped state, but in JSF 1.x the "view scope" already doesn't exist as a managed bean scope. If you're using something like Tomahawk's to simluate the JSF 2.x view scope, then it may end up in "WTF" experience because the bean referenced by will be reconstructed from scratch instead of reused when the view expires (so instead of an error page, you get a fresh new bean) – BalusC Mar 04 '16 at 15:51
  • Ok, funny thing with enableRestoreView11Compatibility is it re-renders the login page instead of following the navigation-rule defined in my application. So I end up on my login page again..but without the ViewExpiredException :( – pmartin8 Mar 04 '16 at 16:24
  • JSF 1.2 is been a looong time ago, so I may not recall things correctly, but a theoretical cause would be that the rebuilt view doesn't match the submitted view. Try giving form, input and button components a fixed ID if not already done. – BalusC Mar 04 '16 at 16:25
  • Digging in the old JSF code, I can see that when restoring the view "the JSF 1.1 way" it goes straight to rendering the response (it mark the response as "to be rendered"). Then it renders the viewId included in the context (which in this case is my login page). It wont go to the "invoke application" phase. Maybe I should add a listener after the phase just to hack this ?! – pmartin8 Mar 04 '16 at 16:33
  • 1
    Hmm. Another way would be to leave it and use a plain HTML
    in combination with a simple servlet.
     – BalusC Mar 04 '16 at 16:35

1 Answers1

1

I couldn't get my login page out of the JSF context because there is a whole bunch of behaviors in my login page that depend on the JSF context.

I finally worked around the problem with a dirty hack. In a RestoreViewPhase listener, I detected that the current view has expired and I get all the parameters out of the HTTP request and into a session managed bean.

Then, when I get back to the login page, some javascript automatically resubmit the form along with a fresh view.

Pretty hacky but it works.

pmartin8
  • 1,545
  • 1
  • 20
  • 36