在Spring Security中，我看到URL受以下保护：
http
.authorizeRequests()
.antMatchers("/admin").hasRole("ADMIN");
我还看到了方法级别的安全性：
@PreAuthorize("hasRole('ADMIN')")
antMatchers用于保护URL，而@PreAuthorize用于保护接口吗？
如果antMatcher已保护已经调用接口的URL，那么为什么需要分别保护接口方法呢？
您是否可以在控制器上使用方法级别的安全性，如：
@PreAuthorize("hasRole('ADMIN')")
@GetMapping("/dashboard/person")
public String findEvent(Model model, HttpServletRequest request) {
....
答案 0 :(得分：6)
Web安全和方法安全是保护应用程序安全的两种不同方法，请参见Spring Security Reference：
为什么不仅仅使用web.xml安全性？
假设您正在基于Spring开发企业应用程序。您通常需要解决四个安全问题：身份验证，Web请求安全性，服务层安全性（即，实现业务逻辑的方法）和域对象实例安全性（即不同的域对象具有不同的权限）。牢记以下典型要求：
[...]
Web请求安全性： Servlet规范提供了一种保护请求URI的方法。但是，这些URI只能以Servlet规范自己的受限URI路径格式表示。 Spring Security提供了一种更为全面的方法。例如，您可以使用Ant路径或正则表达式，可以考虑URI的部分，而不仅仅是请求的页面（例如，可以考虑HTTP GET参数），并且可以实现自己的配置数据的运行时源。这意味着您的Web请求安全性可以在Webapp的实际执行过程中动态更改。
服务层和域对象安全性： Servlet规范中对服务层安全性或域对象实例安全性的缺乏支持对多层应用程序造成了严重限制。通常，开发人员要么忽略这些要求，要么在其MVC控制器代码中实现安全逻辑（或者更糟的是在视图内部）。这种方法有严重的缺点：
a。 关注点分离：授权是一个贯穿各领域的关注点，应照此实施。实施授权代码的MVC控制器或视图使测试控制器和授权逻辑更加困难，调试也更加困难，并且通常会导致代码重复。
b。 对富客户端和Web服务的支持：如果最终必须支持其他客户端类型，则嵌入在Web层中的任何授权代码都是不可重用的。应该考虑到Spring远程出口商仅出口服务层bean（而不是MVC控制器）。因此，需要在服务层中放置授权逻辑以支持多种客户端类型。
c。 分层问题：MVC控制器或视图仅仅是错误的体系结构层，无法实现有关服务层方法或域对象实例的授权决策。尽管可以将主体传递到服务层以使其能够做出授权决策，但这样做会在每个服务层方法上引入一个附加参数。一种更优雅的方法是使用ThreadLocal来容纳Principal，尽管这可能会增加开发时间，以至于仅使用专用的安全框架就变得更加经济（基于成本效益）。
d。 授权代码质量：经常提到Web框架，它们“使做正确的事变得更容易，而做错事则更难”。安全框架是相同的，因为它们以抽象的方式设计用于多种用途。从头开始编写自己的授权代码不会提供框架会提供的“设计检查”，而且内部授权代码通常将缺乏广泛部署，同行评审和新版本带来的改进。
Spring Security建议方法安全，请参见Spring Security Reference：
10.1.4请求匹配和HttpFirewall
[...]
在实践中，我们建议您在服务层使用方法安全性来控制对应用程序的访问，并且不要完全依赖于在Web应用程序级别定义的安全性约束的使用。 URL会发生变化，很难考虑应用程序可能支持的所有可能的URL以及如何处理请求。您应该尝试限制自己使用一些简单易懂的简单蚂蚁路径。始终尝试使用“默认拒绝”方法，在此方法中，您最后定义了一个全包通配符（/或），并拒绝访问。
在服务层定义的安全性更健壮，更难绕开，因此您应该始终利用Spring Security的方法安全性选项。
Spring Security建议在服务层而不是在单个Web控制器上应用方法安全性，请参见Spring Security Reference：
我已经在应用程序上下文中添加了Spring Security的元素，但是如果我在Spring MVC控制器bean（Struts操作等）中添加了安全注释，那么它们似乎没有作用。 < / p>
[...]
通常，我们建议在服务层而不是单个Web控制器上应用方法安全性。