java - 在 Spring 安全中使用拦截 URL

Question

在 Spring security 的 intercept-url 元素中制作模式的首选方法是什么？ 我正在创建一个 Web 服务 (RESTful)，我目前要求所有用户都已登录并具有角色 ROLE_USER。然后通过服务层上的 @PreAuthorize 注释来实现进一步的约束。但是，添加多个具有不同配置的 intercept-url 元素是否常见？

Answer 1

我应该认为“首选方式”是[必然]主观的。我有 <intercept-url>我的 security.xml 中的元素，但放弃了他们，转而支持 @RequestMapping带有 @PreAuthorize 的注释在 Controller 上。这纯粹是个人喜好(在我的情况下)，因为我更喜欢将内容保存在 Java 中而不是 XML 命名空间中，尽可能多地这样做。

您可以使用其中一个、另一个或两者，并且可以使注释增强 XML ——例如，您可以使用以下内容:

security.xml:

<intercept-url pattern="/something" access="hasRole('ROLE_USER')"/>

YourController.java:

@RequestMapping(value="/something/else")
@PreAuthorize("hasRole('ROLE_ADMIN')")
public String getSomethingElseContents(){ return "somethingelse"; }

正如我所说，这似乎只是一个偏好问题。使用 XML 命名空间的好处是基本访问规则都在一个地方，易于阅读和遵循。 @PreAuthorize 施加的规则(或其他注释变体)特别性感，因为您可以在其中调用自己的 SpEL 表达式，并根据对传递的参数或类可访问的字段(即 @PreAuthorize("@my.project.package.hasMagicPower(#power.INVISIBILITY)") )或这些的组合的访问权限做出决定。您可以将原本不可用的逻辑和动态权限应用于命名空间选项。

当然，您可以使用“和”、“或”和“!”来应用基本逻辑。命名空间中 SpEL 表达式中的连接词(您可以通过 XML 中的 @ 指示符访问外部类 [boolean] 方法)，但 XML 中指定的所有内容都必须是静态的。

---

tl;dr:个人偏好就是偏好，但如果您希望或需要动态灵活地处理权限，您必须使用注释。如果您既不想也不需要动态灵 active ，那么您可以选择(并且一个合理的论点会建议命名空间选项相对于 SoC 更好)。我更喜欢让 Java 来处理它的灵 active ，因为一旦我设置了我的 XML，我想不管它并专注于 Java。此外，对 SoC 观点有一个颇具说服力的反驳，即适当常规化的 Java 应用程序将其 Controller 放在易于查找的包中，并具有明显的控制名称。

---

还是 tl;dr:嗯。六个一个，六个另一个。我说 po-tay-to。