使用 Spring Security,我如何使用 HTTP 方法(例如 GET、PUT、POST)来区分特定 URL 模式的安全性?
Spring Security 参考文献指出:
可以使用多个元素来定义不同的 不同组 URL 的访问要求,但它们将 按列出的顺序进行评估,并将使用第一个匹配项。所以你 必须将最具体的匹配项放在顶部。您还可以添加一个 method 属性将匹配限制为特定的 HTTP 方法(GET、 发布、放置等)。如果一个请求匹配多个模式, 无论顺序如何,特定于方法的匹配都将优先。
如何配置 Spring Security,以便根据用于访问 URL 模式的 HTTP 方法来不同地保护对特定 URL 模式的访问?
The Spring Security reference states:
You can use multiple elements to define different
access requirements for different sets of URLs, but they will be
evaluated in the order listed and the first match will be used. So you
must put the most specific matches at the top. You can also add a
method attribute to limit the match to a particular HTTP method (GET,
POST, PUT etc.). If a request matches multiple patterns, the
method-specific match will take precedence regardless of ordering.
How can I configure Spring Security so that access to particular URL patterns are secured differently depending on the HTTP method used to access the URL pattern?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
对于那些喜欢基于 Java 注解的配置的人,请将此类放入您的应用程序中。
使用以下 Maven 依赖项(早期版本的 Spring-Security 也应该可以工作):
For those that prefer Java annotation-based configuration, drop this class into your application.
Using the following Maven dependencies (earlier versions of Spring-Security should work also):
这只是关于配置。它表示将在配置文件的
标记中从上到下评估
元素:在上面的示例中,我们试图只允许经过身份验证的用户访问所有内容,当然,登录页面除外(用户必须首先登录,对吧?!)。但是,根据文档,这行不通,因为不太具体的匹配位于顶部。因此,实现此示例目标的正确配置(之一)是:
将更具体的匹配放在顶部。
引用的最后一件事是关于 HTTP 方法的。您可以使用它来指定匹配,因此:
在第二个示例中,要通过 GET 访问
/client/edit
,用户只需要进行身份验证,但要访问/client/edit< /code> 通过 POST(比如说,提交编辑表单),用户需要具有
EDITOR
角色。在某些地方可能不鼓励使用该 url 模式,但这只是一个示例。This is only about configuration. It says that the
<intercept-url>
elements will be evaluated from top to bottom in your<http />
tag of your configuration file:In the above example, we're trying to allow only authenticated users access everything, except, of course, the login page (the user must first log in, right?!). But this, according to the documentation, won't work, because the less specific match are on top. So, (one of) the right configuration to accomplish this example's objective is:
Placing the more specific match on top.
The last thing the quote says is about the HTTP method. You can use it to specify the match, so:
In this second example, to access
/client/edit
via GET the user only needs to be authenticated, but to access/client/edit
via POST (lets say, submitting the edit form) the user needs to have theEDITOR
role. That url pattern may be not encouraged in some places but it was just an example.