弹簧安全、方法安全和url安全

Question

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

我知道我可以通过在标记中定义规则来保护urls，然后我看到了一个@secure注释，它可以保护方法。然后还有其他注释来保护域(或POJO)的读取/更新。

因此，当我想要开发一个典型的权限/角色/用户web应用程序时，除了创建保护urls的规则之外，我还需要使用@secure注释来保护方法吗？

艾J。

1. 用户输入受限制的url
2. 应用程序请求登录
3. 应用程序检查角色是否可以访问url。
4. 用户选择“添加新”选项
5. 再次检查该用户是否拥有调用方法“addNew()”的权限？

或者步骤4或5中的一个是多余的。

抱歉，我的英语

Answer 1

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

也就是说，如果您能够准确地区分用户仅通过URL打算做什么，并且不需要通过不同的访问通道(例如来自队列或RMI)来保护该方法，那么您可以只保护URL。然而，尽管如此，拥有方法级的安全性还是不错的主意.有几个原因。首先，它记录了正在执行逻辑的预期角色。这可能有助于理解开发时所作的假设，这些假设有助于进行未来的增强。其次，它可以确保通过未来访问通道的安全性不会因疏忽而受到损害。

Answer 2

URL级别的安全性非常丰富，例如，通过查看fluent HttpSecurity API就可以看出这一点。但是，在Spring安全性中使用方法级安全性至少有两个原因：

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