0

i am using a PhaseListener And i can see that my credentials is available directly from the RESTORE_VIEW all the way up to INVOKE_APPLICATION and RENDER_RESPONSE. Which all makes sense. I wonder what the best practice is when it comes to validating these credentials.

I am thinking of i could validate at the RESTORE_VIEW. I am pretty sure i dont want to wait until the UPDATE_MODEL since i believe that might be a security risk. Though a little more uncertain if i should let the phase run through the APPLY_REQUEST and PROCESS_VALIDATIONS...

Any ideas?

Beau Johnny Bekkestad
  • 371
  • 5
  • 13
  • _i can see that my credentials is available directly from the RESTORE_VIEW_ You mean when you hit the login page for the first time and when the component tree is created for the first time, your credentials are available?? – Vikas V Jun 10 '13 at 08:37
  • Well, i hit the login page, credentials is null. After the login submit is pressed the credentials is loaded and then i see it in the RESTORE_VIEW – Beau Johnny Bekkestad Jun 10 '13 at 14:08
  • Do not use a JSF phase listener for this at all! – BalusC Jun 11 '13 at 12:47

2 Answers2

4

In practice, the RESTORE_VIEW phase is the ideal place to enforce access control to a JSF resource. It's the first phase of the request lifecycle for the page; there really isn't any reason to let a request progress any further than that if it's not authorized.

Apart from the fact that you really shouldn't be fussing about phases and phaselisteners for such a basic service as access control, one problem you might run into is the fact that(as at the time of this answer) a PhaseListener is not an injection target. What this means is that @EJB, @Inject and @ManagedProperty will not work on a phaselistener. Unless you make it a @ManagedBean. This means that services that might be necessary to perform the authentication check will not be available in a phaselistener. JSF2.2 promises to make everything within the context an injection target though

While I'm not the authority on "Best Practice", my idea of best practice is a clean, maintainable and reusable approach to solving problems. IMO, the two clean and minimally invasive methods of access control to a page are

  1. Servlet Filter: This is a tested and true method of web resource access control and is JSF-independent. You needn't worry about phases or anything of the sort and pretty much any J2EE. This is a pretty straightforward example of a servlet filter protecting a JSF resource.

  2. JSF Page level authentication: Using the JSF preRenderView event, you could validate access to a JSF page. This inherently kicks in during the RESTORE_VIEW phase and there are a bunch of resources on here with regard to its use:

Community
  • 1
  • 1
kolossus
  • 20,559
  • 3
  • 52
  • 104
  • Agreed. I've used both approaches and I like to use approach number 2 which pops up a modal window for login when necessary. – Catfish Oct 14 '13 at 18:59
0

Ideally you should the request pass through its normal lifecycle, this will give you the advantage of utilizing the stages at the max for their original purpose. Say I want to introduce a validator for a certain field, but the request gets processed before that, then the only option I will have will be to move the logic of the validator in the previous code itself, which will make it cumbersome.

So my suggestion would be let the request go through its original lifecycle.

And your statement "I am pretty sure i dont want to wait until the UPDATE_MODEL since i believe that might be a security risk." would require some facts for this quote then can we discuss the alternative solution.

Himanshu Bhardwaj
  • 4,038
  • 3
  • 17
  • 36
  • What i meant was that since i want to intercept the form login, i should do what ever i need to do, prior to the UPDATE_MODEL, If it is done after that it will be to late and therefor it could be seen as a risk. – Beau Johnny Bekkestad Jun 10 '13 at 14:10