弹簧安全，方法安全和网址安全答案

【问题标题】：spring security, method secure and url secure弹簧安全，方法安全和网址安全
【发布时间】：2012-06-05 06:47:34
【问题描述】：

我正在学习 Spring Security，但我对它的灵活性感到困惑..

我知道我可以通过在标签中定义规则来保护 url 然后我看到有一个 @secure 注释可以保护方法。然后还有其他注释来保护按域（或 POJO）读取/更新的安全

所以当我想开发一个典型的权限/角色/用户 Web 应用程序时，除了创建规则来保护 url 之外，我是否还必须使用 @secure 注释来保护方法？

ej。

用户输入受限网址
应用程序要求登录
应用检查角色是否可以访问url
用户选择“添加新”选项
再次检查该用户是否有权调用方法“addNew()”？？

或步骤 4 或 5 之一是多余的。

对不起我的英语

【问题讨论】：

标签： spring spring-security

【解决方案1】：

URL 级别的安全性相当丰富，例如通过查看流畅的API of HttpSecurity 可以看出。但是在 Spring security 中使用方法级安全至少有两个原因：

正如 Jonathan W 所指出的，您的安全逻辑可以通过 http 以外的连接器类型访问。例如，可以通过 EJB 公开逻辑。
对于 REST API，同一个 URI 可能支持具有不同授权规则的不同 http 方法。例如/myapi/order/{id} 可以接受 GET 和 DELETE，而 DELETE 可能仅对具有主管角色的用户可用。您不能通过 URL 安全性指定该规则，但可以通过方法安全性来指定，例如在处理 DELETE 的方法上使用 @Secured("Supervisor")。

【讨论】：

【解决方案2】：

这是要记住的最重要的事情。您必须假设用户可以通过原始 HTTP GET 或 POST 将任何内容发送到您的 Web 应用程序。这也被称为“永远不要相信客户”。所以上面的步骤 4 和 5 不是多余的。例如，如果您到达第 5 步，则无法确定第 3 步是否发生。

也就是说，如果您可以仅通过 URL 准确区分用户打算做什么并且您不需要通过不同的访问通道（例如从队列或RMI），您只需保护 URL 即可。但是，无论如何，拥有方法级别的安全性仍然不是一个坏主意……出于几个原因。首先，它记录了正在执行逻辑的预期角色。这有助于理解在开发时做出的假设，这有助于做出未来的改进。其次，它可以确保未来访问通道的安全性不会被无意中破坏。

【讨论】：

谢谢你的回答。所以如果我保护每个方法/类，我还需要保护 URL 吗？或者也许只结合匿名/用户/管理员模式的简单规则
如果您的 URL 大致按角色分组，那么通过 URL 保护可能会更容易（例如，需要 ROLE_ADMIN 的 'admin/**' URL）。但通常你要么不能以这种方式构建你的应用程序，要么角色比这更复杂，要么 URL 本身根本不提供太多信息（即，大部分信息都在请求正文中）。但最好在 URL 级别设置一些全面的信息，尤其是对于非 Java 文件（如果您有任何文件并在 Web 应用程序中提供这些文件）。