security - 保护 JSF 应用程序的安全

Question

我的一位自由职业者 friend 邀请我加入他的 JSF 2.0 项目，我正在慢慢加快速度并将各个部分整合在一起。来自 Windows 窗体 .NET 世界，至少可以说，我还有很多东西需要学习。

我主要担心的是对于如何保护 JSF 应用程序缺乏明显的共识。

这里已经在 SO 上提出了一些方法，包括使用 Spring 安全性、Seam 安全性、自定义阶段监听器，或者简单地使用 rendered="#{...}" 属性来显示/隐藏基于用户身份验证的组件。

我尝试实现其中一些方法，例如 Spring security，却发现它很容易被转发到 View 而不是重定向的 JSF 导航机制击败。换句话说，如果用户直接输入安全页面的 URL，Spring 安全性将正常工作，但如果 h:commandButton 的操作将他带到那里，则不然。

有鉴于此，有人建议使用"faces-redirect=true"强制重定向，但我们认为这可能会成为性能问题，因为这会导致浏览器发出 2 个请求每次。

另一方面，在出现这么多缺少依赖项的错误后，我放弃了实现 Seam 安全性的尝试。

到目前为止，我找到的最佳解决方案是来自 Duncan Mills - Effective Page Authorization In JavaServer Faces 的自定义相位监听器，但我并不 100% 相信这应该用于面向公众的 JSF 应用程序。

最后，这给我们留下了什么？我知道这是一个非常开放的问题，但老实说我不知道​​下一步该去哪里。我很确定我已经严格遵循了不同的教程，例如 Spring 教程，但我仍然对其工作方式不满意。

任何人都可以至少确认/确认 Spring 安全性应该跨 JSF 转发工作这一事实，因为我已经看到其他人有相同问题的许多帖子？这至少会给我一个继续前进的方向。

谢谢。

Answer 1

用于页面验证的 servlet 过滤器(应用于 faces servlet)、身份 session bean(存储用户属性，例如角色、登录 ID)和一些用于权利检查的方法(例如 isAdmin()、canViewRecord(recordID))的组合贯穿整个页面。

你看，当涉及到安全性时，我选择不将其交给其他人。另外，我在几个地方进行了验证(隐藏组件不会阻止人们伪造正确的 POST 请求来触发特定的 bean 方法，所以要小心)。