4

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

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

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

ej。

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

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

对不起我的英语

4

2 回答 2

5

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

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

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

于 2016-09-01T20:38:36.010 回答
2

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

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

于 2012-05-31T03:49:36.483 回答