我应该在哪个阶段拦截JSF中的登录尝试 [英] which phase should i use to intercept the login attempt in JSF
问题描述
我正在使用PhaseListener 而且我可以看到,从RESTORE_VIEW一直到INVOKE_APPLICATION和RENDER_RESPONSE都可以直接使用我的凭据.这一切都说得通. 我想知道验证这些凭据的最佳实践是什么.
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.
我正在考虑可以在RESTORE_VIEW上进行验证.我很确定我不想等到UPDATE_MODEL,因为我认为这可能会带来安全风险. 虽然还不确定我是否应该让该阶段贯穿APPLY_REQUEST和PROCESS_VALIDATIONS ...
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...
有什么想法吗?
推荐答案
在实践中,RESTORE_VIEW
阶段是对JSF资源实施访问控制的理想场所.这是页面请求生命周期的第一阶段;除了未经授权的请求外,没有任何理由让请求进一步处理.
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.
除了您实际上不应该对诸如访问控制之类的基本服务的阶段和阶段侦听器大惊小怪之外,您可能会遇到的一个问题是(如在回答此问题时)a @EJB
,@Inject
和@ManagedProperty
在相位侦听器上将不起作用.除非您将其设置为@ManagedBean
.这意味着执行鉴权检查可能必需的服务在阶段侦听器中将不可用. JSF2.2承诺将上下文中的所有内容都作为注入目标
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
虽然我不是最佳实践"的权威,但我的最佳实践想法是一种解决问题的干净,可维护和可重用的方法. IMO,对页面的访问控制的两种干净且微创的方法是
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
-
Servlet过滤器:这是经过测试的真实的Web资源访问控制方法,与JSF无关.您无需担心阶段或任何种类的问题,几乎不必担心任何J2EE. 这非常简单保护JSF资源的servlet过滤器示例.
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.
JSF页面级身份验证:使用JSF preRenderView
事件,您可以验证对JSF页面的访问.这在RESTORE_VIEW
阶段会固有地起作用,有关其用法,这里有很多资源:
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:
- 在加载时执行后备bean操作?
- 在JSF2中将类似逻辑的过滤器放置在何处
- ViewParam与@ManagedProperty(值=#{param.id}"")
- >什么可以< f:metadata> ;,< f: viewParam>和< f:viewAction>用于吗?
- 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?
这篇关于我应该在哪个阶段拦截JSF中的登录尝试的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!