我正在学习 spring 安全性，但我对它的灵活性感到困惑 .
我知道我可以通过在标签中定义规则来保护网址然后我看到有一个@secure注释可以保护方法 . 然后还有其他注释来保护域（或POJO）的读/更新
因此，当我想开发一个典型的权限/角色/用户Web应用程序时，除了创建安全URL的规则之外，我是否还必须使用@secure注释来保护方法？
EJ .
-
用户输入受限制的URL
-
申请要求登录
-
应用程序检查角色是否可以访问该URL
-
用户选择"add new"选项
-
再次检查该用户是否有权调用方法"addNew()" ??
或者步骤4或5之一是多余的 .
抱歉我的英语
2 回答
这是最重要的事情要记住 . 您必须假设用户可以通过原始HTTP GET或POST向Web应用程序发送任何内容 . 这也称为"never trust the client."因此上面的步骤4和5并不是多余的 . 例如，如果您到达第5步，则无法确定是否发生了第3步 .
也就是说，如果你能够通过URL单独准确地区分用户打算做什么，那么无论如何都要保持方法级安全性并不是一个坏主意......原因有两个 . 首先，它记录了正在执行逻辑的预期角色 . 这有助于理解在开发时所做的假设，这些假设可以帮助进行未来的增强 . 其次，它可以确保通过未来的访问通道的安全性不会无意中受到损害 .
URL级别的安全性非常丰富，例如，通过查看流畅的API of HttpSecurity可以看到 . 但是在Spring安全性中使用方法级安全性至少有两个原因：
正如Jonathan W所指出的，您的安全逻辑可以通过http以外的连接器类型访问 . 例如，逻辑可以通过EJB公开 .
对于REST API，相同的URI可能支持具有不同授权规则的不同http方法 . 例如，
/myapi/order/{id}可以接受GET和DELETE，并且DELETE可能仅对具有超级用户角色的用户可用 . 您不能通过URL安全性指定该规则，但可以通过方法安全性来指定该规则，例如在处理DELETE的方法上使用@Secured("Supervisor").