which phase should i use to intercept the login at

2019-09-09 05:27发布

问题:

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?

回答1:

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:

    • Execute backing bean action on load?
    • where to put filter like logic in JSF2
    • ViewParam vs @ManagedProperty(value = "#{param.id}")
    • What can <f:metadata>, <f:viewParam> and <f:viewAction> be used for?


回答2:

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.