弹簧安全，方法安全和URL安全

Question

我正在学习弹簧安全性，但我对它的灵活性感到困惑。

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

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

EJ。

1. 用户输入受限制的网址
2. 申请要求登录
3. 应用程序检查角色是否可以访问网址
4. 用户选择“添加新”选项
5. 再次检查该用户是否有权调用方法“addNew（）”??

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

抱歉我的英文

Answer 1

网址级安全性非常丰富，例如，通过查看流畅的API of HttpSecurity可以看到。 但是在Spring安全性中使用方法级安全性至少有两个原因：

1. 正如Jonathan W所指出的，您的安全逻辑可以通过http以外的连接器类型访问。例如，逻辑可以通过EJB公开。

2. 对于REST API，相同的URI可能支持具有不同授权规则的不同http方法。例如，/myapi/order/{id}可以接受GET和DELETE，并且DELETE可能仅对具有超级用户角色的用户可用。您不能通过URL安全性指定该规则，但您可以通过方法安全性来执行此操作，例如在处理DELETE的方法上使用@Secured("Supervisor")。

Answer 2

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

也就是说，如果您可以通过单独的网址和准确区分用户打算做什么，则无需通过不同的访问渠道（例如从队列或RMI），你可以放弃只保护URL。但是，出于几个原因，无论如何都拥有方法级安全性仍然不是一个坏主意。首先，它记录了正在执行逻辑的预期角色。这有助于理解在开发时所做的假设，这些假设可以帮助进行未来的增强。其次，它可以确保通过未来的访问渠道的安全性不会无意中受到损害。