在Spring安全中使用拦截网址

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

您可以使用其中一个，另一个或两者兼而有之，并且可以使批注增强 XML -- 例如，您可以拥有如下所示的内容：

安全性.xml：

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

您的控制器.java：

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

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

当然，您可以使用命名空间中 SpEL 表达式中的“and”、“or”和 '！' 连接词应用基本逻辑（并且您可以通过 XML 中的指示符访问外部类 [布尔] 方法），但 XML 中指定的所有内容都必须是静态的。@

tl;dr：个人偏好是偏好，但是如果您希望或需要在权限处理中具有动态灵活性，则必须使用注释。如果您既不想要也不需要动态灵活性，则可以选择（并且合理的参数表明命名空间选项相对于SoC更好）。我更喜欢让Java处理它以获得灵活性，因为一旦我设置了我的XML，我就想让它独自一人，专注于Java。此外，SoC观点还有一个有点令人信服的反驳，即一个正确约定的Java应用程序将使其控制器位于易于查找的包中，并具有明显的名称控制。

还是：嗯。一打六，一打六。我说po-tay-to。

大多数使用Spring Security的Web应用程序只有几个，因为它们只有非常基本的安全要求。您需要对登录和登录错误屏幕以及公共站点的某些方面进行未经身份验证的访问，以便可以有一些URL模式。然后通常有一个管理部分，然后其他所有内容都是 。intercept-urlROLE_USER

如果需要更多角色，则通常将它们与顶级 URL 路径组件相关联。尽管这不是必需的，但它可以更轻松地确保资源得到适当保护。

<http realm="Contacts Realm" use-expressions="false">
    <intercept-url pattern="/index.jsp" access="IS_AUTHENTICATED_ANONYMOUSLY"/>
    <intercept-url pattern="/login.jsp*" access="IS_AUTHENTICATED_ANONYMOUSLY"/>
    <intercept-url pattern="/admin/*" access="ROLE_ADMIN"/>
    <intercept-url pattern="/secret/*" access="ROLE_SECRET"/>
    <intercept-url pattern="/**" access="ROLE_USER,ROLE_ADMIN,ROLE_SECRET"/>
    <http-basic/>
</http>

您必须根据您的使用案例决定是否允许人们拥有多个角色。在应用中管理起来有点困难，因此大多数具有简单安全性的人都会对其进行设置，以便用户只有一个角色，然后他们允许多个角色访问受保护的内容。当然，另一种方法是每个URL模式一个角色，并为人们提供多个角色。

无论如何，您的问题的答案（或者至少是我认为您正在问的问题）是，通常要做的是每个角色一个顶级路径组件，以保护具有相同安全限制的所有资源。当然，您也在该路径前缀下对功能进行分组，因此有些人讨厌这种结构，有些人只是喜欢在代码中使用注释。我喜欢我的安全性，我可以在一个地方看到它，并且只需查看URL即可轻松分辨出安全期望是什么。