我正在使用 PhaseListener 我可以看到我的凭据可以直接从 RESTORE_VIEW 一直到 INVOKE_APPLICATION 和 RENDER_RESPONSE。这一切都说得通。我想知道验证这些凭据时的最佳做法是什么。
我想我可以在 RESTORE_VIEW 进行验证。我很确定我不想等到 UPDATE_MODEL 因为我相信这可能是一个安全风险。虽然有点不确定我是否应该让阶段通过 APPLY_REQUEST 和 PROCESS_VALIDATIONS...
有任何想法吗?
我正在使用 PhaseListener 我可以看到我的凭据可以直接从 RESTORE_VIEW 一直到 INVOKE_APPLICATION 和 RENDER_RESPONSE。这一切都说得通。我想知道验证这些凭据时的最佳做法是什么。
我想我可以在 RESTORE_VIEW 进行验证。我很确定我不想等到 UPDATE_MODEL 因为我相信这可能是一个安全风险。虽然有点不确定我是否应该让阶段通过 APPLY_REQUEST 和 PROCESS_VALIDATIONS...
有任何想法吗?
实际上,该RESTORE_VIEW
阶段是对 JSF 资源实施访问控制的理想场所。这是页面请求生命周期的第一阶段;如果未经授权,确实没有任何理由让请求进展得更远。
除了您真的不应该为访问控制等基本服务的阶段和阶段侦听器大惊小怪之外,您可能遇到的一个问题是(在此答案时)aPhaseListener
不是注入目标. 这意味着@EJB
,@Inject
并且@ManagedProperty
不会在相位监听器上工作。除非你把它做成一个@ManagedBean
. 这意味着执行身份验证检查可能需要的服务在阶段侦听器中将不可用。JSF2.2 承诺使上下文中的所有内容都成为注入目标
虽然我不是“最佳实践”的权威,但我认为最佳实践是一种干净、可维护和可重用的解决问题的方法。IMO,对页面进行访问控制的两种干净且微创的方法是
Servlet 过滤器:这是一种经过测试且真实的 Web 资源访问控制方法,并且与 JSF 无关。您不必担心阶段或任何类似的事情以及几乎任何 J2EE。 这是保护 JSF 资源的 servlet 过滤器的一个非常简单的示例。
JSF 页面级身份验证:使用 JSFpreRenderView
事件,您可以验证对 JSF 页面的访问。这本质上是在这个RESTORE_VIEW
阶段开始的,这里有很多关于它的使用的资源:
理想情况下,您应该请求通过其正常的生命周期,这将使您能够最大限度地利用这些阶段来实现其原始目的。假设我想为某个字段引入验证器,但请求在此之前得到处理,那么我唯一的选择就是将验证器的逻辑移动到前面的代码本身中,这会变得很麻烦。
所以我的建议是让请求经历其原始生命周期。
而您的声明“我很确定我不想等到 UPDATE_MODEL,因为我认为这可能会带来安全风险。” 这句话需要一些事实,然后我们可以讨论替代解决方案。