我们一直在使用自定义 @Secure 拦截器来保护我们的支持 bean 方法，以防止对该方法的伪造调用。
但最近，如果调用该操作的组件未呈现，则这些方法无法访问。据我了解，JSF 将生成视图，如果组件不是基于权限呈现的（例如带有 isUserInRole 的 EL），那么任何以该组件为源的伪造 POST 都不会触发，因为在恢复视图。这是正确的吗？
基本上，任何伪造都必须有一个受损的当前 JSESSIONID，甚至可能是 ViewState，这取决于它们是否需要相同的视图。
有人可以确认我的假设是正确的，如果可能的话，请指出我在规范中的某个位置？
谢谢
【问题讨论】：
好的，我想我已经确认根据规范确实无法访问非渲染组件的操作。
规范第 2.2.2 节规定：
在应用请求值阶段，JSF 实现必须 调用组件的 UIViewRoot 的 processDecodes() 方法 tree.[P1-end] 这通常会导致 processDecodes() 方法 递归调用树中的每个组件，如中所述 UIComponent.processDecodes() 方法的 Javadocs。
它还指出：
在请求值的解码过程中，一些组件执行了特殊的 处理，包括：实现ActionSource的组件（如 UICommand），它识别出它们已被激活，将排队 动作事件。该事件将在申请请求结束时交付 如果组件的立即属性为真，则为阶段赋值，或者在 如果为 false，则 Invoke Application 阶段结束。
因此，ActionSource 组件只有在根据 processDecodes 处理时才会对操作进行排队。查看javadoc：
执行Apply Request所需的组件树处理 请求处理生命周期的所有方面的值阶段 此组件，此组件的所有子组件，以及此组件 本身，如下。
- 如果此 UIComponent 的渲染属性为 false，则进一步跳过 处理。
所以第一个检查必须是组件是否被渲染，如果没有，则跳过其余部分。 ActionSource 永远不会排队，操作也永远不会被调用。
还有一点需要注意的是，从 JSF 2.2 开始，ViewState 似乎只对按照规范进行的 CSFR 预防可靠：
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-869
以前的实现显然过于可预测并且没有涵盖 GET 请求。规范现在需要这个。
因此，虽然保护服务器端的安全可能仍然是一个好习惯，但似乎控制 ActionSource 组件的呈现就足够了。
【讨论】：
JSESSIONID 是绝对需要的。但是如果用户登录，就可以很容易地访问它——我说的是用户登录的情况，但据说没有访问特定方法的权限。
另一部分更棘手。如果状态存储在客户端，则可以伪造。此外，还有一些机制可以提供到动作和页面的直接链接——比如漂亮或简单的链接。如果该方法以任何这些方式公开，则应加以限制。
我会保护它们以防止将来不断监控以何种方式公开哪种方法的麻烦——想象一下，如果您想为应用程序添加 REST 或 SOA 接口。
【讨论】：