前言
今天我們重點(diǎn)聊聊授權(quán)方式的另外一種：基于HttpServletRequest配置權(quán)限
基于HttpServletRequest配置權(quán)限
一個(gè)典型的配置demo
http.authorizeHttpRequests(requestMatcherRegstry ->
// /admin/** 需要有AMIND角色
requestMatcherRegstry.requestMatchers("/admin/**").hasRole("ADMIN")
// /log/** 只要有AMIND、USER角色之一
.requestMatchers("/log/**").hasAnyRole("ADMIN", "USER")
// 任意請(qǐng)求 只要登錄了即可訪問
.anyRequest().authenticated()
);
從這里也可以看出，要實(shí)現(xiàn)基于RBAC，還是比較容易的。也比較容易使用。但是如果想要?jiǎng)討B(tài)的增加角色，就需要我們定制AuthorizationManager。
配置原理
HttpSecurity是負(fù)責(zé)構(gòu)建DefaultSecurityFilterChain的。而這個(gè)安全過濾器鏈，則是允許我們進(jìn)行配置的。而authorizeHttpRequests方法，正是配置AuthorizationFilter的。而我們傳入的入?yún)?lambada表達(dá)式-則是指引如何配置AuthorizationFilter的。
/**
* 這個(gè)方法是HttpSecurity的方法。
* 作用是配置AuthorizationFilter。
* 其入?yún)uthorizeHttpRequestsCustomizer正是讓我們配置AuthorizationFilter的關(guān)鍵。
* Customizer：就是定制。原理比較容易理解，就是我把你需要配置的東西丟給你，你往里面賦值。
* AuthorizeHttpRequestsConfigurer<HttpSecurity>：這個(gè)是Configurer的實(shí)現(xiàn)，負(fù)責(zé)引入過濾器的。這里明顯就是引入AuthorizationFilter
* AuthorizationManagerRequestMatcherRegistry：這個(gè)就是我們最終配置的東西。而這個(gè)配置的正是我們上面的RequestMatcherDelegatingAuthorizationManager。說白了就是往里面添加哪些路徑對(duì)應(yīng)哪些AuthorizationManager。只不過，為了方便使用，也幫我們都封裝好了。不妨繼續(xù)往后看看。
*/
public HttpSecurity authorizeHttpRequests(
Customizer<AuthorizeHttpRequestsConfigurer<HttpSecurity>.AuthorizationManagerRequestMatcherRegistry> authorizeHttpRequestsCustomizer)
throws Exception {
ApplicationContext context = getContext();
// 這里干了三個(gè)事情：
// 1. 如果當(dāng)前HttpSecurity不存在AuthorizeHttpRequestsConfigurer，則創(chuàng)建一個(gè)，并注冊(cè)到當(dāng)前的HttpSecurity對(duì)象中。
// 2. 從AuthorizeHttpRequestsConfigurer拿到他的注冊(cè)器也就是AuthorizationManagerRequestMatcherRegistry
// 3. 調(diào)用傳入的參數(shù)的customize。如此，我們傳入的lambda表達(dá)式就被調(diào)用了。
authorizeHttpRequestsCustomizer
.customize(getOrApply(new AuthorizeHttpRequestsConfigurer<>(context)).getRegistry());
return HttpSecurity.this;
}
public final class AuthorizationManagerRequestMatcherRegistry
extends AbstractRequestMatcherRegistry<AuthorizedUrl> {
/**
* 這是父類的方法
* C代表的是AuthorizedUrl
*/
public C requestMatchers(String... patterns) {
// 調(diào)用的重載方法第一個(gè)參數(shù)為HttpMethod，也就是說，我們還可以指定HTTP請(qǐng)求的方法，例如：POST、GET等
return requestMatchers(null, patterns);
}
@Override
protected AuthorizedUrl chainRequestMatchers(List<RequestMatcher> requestMatchers) {
this.unmappedMatchers = requestMatchers;
return new AuthorizedUrl(requestMatchers);
}
}
public class AuthorizedUrl {
private final List<? extends RequestMatcher> matchers;
public AuthorizationManagerRequestMatcherRegistry permitAll() {
return access(permitAllAuthorizationManager);
}
public AuthorizationManagerRequestMatcherRegistry hasRole(String role) {
return access(withRoleHierarchy(AuthorityAuthorizationManager.hasRole(role)));
}
public AuthorizationManagerRequestMatcherRegistry hasAnyAuthority(String... authorities) {
return access(withRoleHierarchy(AuthorityAuthorizationManager.hasAnyAuthority(authorities)));
}
public AuthorizationManagerRequestMatcherRegistry authenticated() {
return access(AuthenticatedAuthorizationManager.authenticated());
}
public AuthorizationManagerRequestMatcherRegistry access(
AuthorizationManager<RequestAuthorizationContext> manager) {
Assert.notNull(manager, "manager cannot be null");
return AuthorizeHttpRequestsConfigurer.this.addMapping(this.matchers, manager);
}
}
public final class AuthorizeHttpRequestsConfigurer<H extends HttpSecurityBuilder<H>>
extends AbstractHttpConfigurer<AuthorizeHttpRequestsConfigurer<H>, H> {
private AuthorizationManagerRequestMatcherRegistry addMapping(List<? extends RequestMatcher> matchers,
AuthorizationManager<RequestAuthorizationContext> manager) {
for (RequestMatcher matcher : matchers) {
this.registry.addMapping(matcher, manager);
}
return this.registry;
}
}
我們通過lambda表達(dá)式：
requestMatcherRegstry -> requestMatcherRegstry.requestMatchers("/admin/**").hasRole("ADMIN")
配置的正是AuthorizationManagerRequestMatcherRegistry
requestMachers方法，構(gòu)建出AuthorizedUrl，然后通過這個(gè)類的hasRole方法注冊(cè)當(dāng)前路徑所對(duì)應(yīng)的權(quán)限/角色。這個(gè)對(duì)應(yīng)關(guān)系由RequestMatcherEntry保存。key：RequestMatcher requestMatcher；value: AuthorizationManager。
值得一提的是，這個(gè)lambda表達(dá)式以及其鏈?zhǔn)秸{(diào)用看起來簡(jiǎn)單方便，但是其內(nèi)部涉及多個(gè)類的方法調(diào)用，實(shí)在很容易犯迷糊，這是我覺得比較詬病的地方。在我看來，鏈?zhǔn)秸{(diào)用還是同一個(gè)返回值（每次都返回this）才能做到在方便至于也能清晰明了，容易理解。
而這里在lambda表達(dá)式內(nèi)部：
- 第一個(gè)方法是
requestMatcherRegstry.requestMatchers
是AbstractRequestMatcherRegistry，也就是我們的AuthorizationManagerRequestMatcherRegistry的父類。方法返回值是AuthorizedUrl。 - 第二個(gè)方法是
AuthorizedUrl.hasRole
而該方法的返回值為AuthorizationManagerRequestMatcherRegistry。
發(fā)現(xiàn)什么了嗎？鏈?zhǔn)秸{(diào)用還能玩起遞歸，又回到最開始的第一個(gè)方法了。而要是我們配置HttpSecurity，直接一連串的鏈?zhǔn)秸{(diào)用，那更是沒譜了。經(jīng)常就是，你只能看著別人這樣配置，然后照貓畫虎。這個(gè)鏈?zhǔn)秸{(diào)用咋調(diào)回來的，一頭霧。因?yàn)橹虚g可能跨越好幾個(gè)不同的類。。。
PS：可能官方也有些意識(shí)到這點(diǎn)，所以sample工程都是類似于本文開頭的那樣，傳入一個(gè)基于lambda表達(dá)式的Customizer。一個(gè)方法配置一個(gè)過濾器的SecurityConfigurer。但，如果你翻看源碼，你看到的就是一連串的鏈?zhǔn)秸{(diào)用。最為明顯的一個(gè)證明就是HttpSecurity#and方法過期了。因此個(gè)人推薦大家用文章開頭的那種方法，相對(duì)清晰易理解。
我想說，這么玩是深怕別人搞明白了是嗎？？？更絕的是，即便你知曉了原理也沒有辦法直接注冊(cè)對(duì)應(yīng)關(guān)系，除非你使用反射！
這里給大家提個(gè)醒，如果你想搞明白你在使用SpringSecurity究竟在配置些什么，那么你就必須要搞明白上面的套路。
設(shè)計(jì)方案
Spring Security在5.5版本之后，在鑒權(quán)架構(gòu)上，進(jìn)行了較大的改動(dòng)。以至于官方也出了遷移指南
| 組件 | 5.5之前 | 5.5之后 |
|---|---|---|
| 過濾器 | FilterSecurityInterceptor | AuthorizationFilter |
| 鑒權(quán)管理器 | AccessDecisionManager | AuthorizationManager |
| 訪問決策投票員 | AccessDecisionVoter | - |
而原來的設(shè)計(jì)方案，相較于新的方案，更為復(fù)雜。這里給大家一張官方的UML感受感受：
除卻過濾器外，還需要三個(gè)組件來構(gòu)建完整的鑒權(quán)：
AccessDecisionManager 、AccessDecisionVoter 、ConfigAttribute。
感興趣的同學(xué)可以自己琢磨琢磨，但已經(jīng)廢棄的方案，這里就不討論了。
5.6之后的新方案
新方案只有一個(gè)包羅萬象、且極具擴(kuò)展性的AuthorizationManager
我們前面的配置demo，本質(zhì)上都是在配置RequestMatcherDelegatingAuthorizationManager。他主要是記錄每一個(gè)路徑對(duì)應(yīng)的AuthorizationManager<HttpServletRequest>。當(dāng)有請(qǐng)求過來時(shí)，只需要遍歷每一個(gè)路徑，當(dāng)找到匹配者就委托該AuthorizationManager<HttpServletRequest>進(jìn)行鑒權(quán)。
在我們的配置demo中，對(duì)應(yīng)的是AuthoriztyAuthorizationManager和AuthenticatedAuthorizationManager。前者，意味著我們配置的是角色/權(quán)限，后者對(duì)應(yīng)的是authenticated()這個(gè)方法。
如果你認(rèn)真看了這個(gè)關(guān)系圖，那么一定會(huì)發(fā)現(xiàn)右邊的4個(gè)實(shí)現(xiàn)類正是我們?cè)谏弦晃闹v述基于方法配置權(quán)限中所使用到的。
鑒權(quán)源碼分析
權(quán)限過濾的入口：AuthorizationFilter
public class AuthorizationFilter extends GenericFilterBean {
@Override
public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain)
throws ServletException, IOException {
// 類型轉(zhuǎn)換
HttpServletRequest request = (HttpServletRequest) servletRequest;
HttpServletResponse response = (HttpServletResponse) servletResponse;
// 是否需要執(zhí)行鑒權(quán)
if (this.observeOncePerRequest && isApplied(request)) {
chain.doFilter(request, response);
return;
}
// /error和異步請(qǐng)求不處理
if (skipDispatch(request)) {
chain.doFilter(request, response);
return;
}
// 是否已經(jīng)執(zhí)行過鑒權(quán)邏輯了
String alreadyFilteredAttributeName = getAlreadyFilteredAttributeName();
request.setAttribute(alreadyFilteredAttributeName, Boolean.TRUE);
try {
// 從SecurityContextHolder中獲取憑證，并通過AuthorizationManager做出決策
AuthorizationDecision decision = this.authorizationManager.check(this::getAuthentication, request);
// 發(fā)布鑒權(quán)事件
this.eventPublisher.publishAuthorizationEvent(this::getAuthentication, request, decision);
if (decision != null && !decision.isGranted()) {
// 拒絕訪問異常
throw new AccessDeniedException("Access Denied");
}
// 正常執(zhí)行后續(xù)業(yè)務(wù)邏輯
chain.doFilter(request, response);
}
finally {
// 處理完業(yè)務(wù)邏輯后，為當(dāng)前請(qǐng)求清理標(biāo)識(shí)
request.removeAttribute(alreadyFilteredAttributeName);
}
}
}
RequestMatcherDelegatingAuthorizationManager
public final class RequestMatcherDelegatingAuthorizationManager implements AuthorizationManager<HttpServletRequest> {
@Override
public AuthorizationDecision check(Supplier<Authentication> authentication, HttpServletRequest request) {
// 遍歷每一個(gè)已經(jīng)登錄好的路徑，找到對(duì)應(yīng)的AuthorizationManager<RequestAuthorizationContext>>
for (RequestMatcherEntry<AuthorizationManager<RequestAuthorizationContext>> mapping : this.mappings) {
RequestMatcher matcher = mapping.getRequestMatcher();
// 匹配當(dāng)前請(qǐng)求
MatchResult matchResult = matcher.matcher(request);
if (matchResult.isMatch()) {
// 找到匹配的AuthorizationManager就直接調(diào)用check方法并返回鑒權(quán)結(jié)果
AuthorizationManager<RequestAuthorizationContext> manager = mapping.getEntry();
return manager.check(authentication,
new RequestAuthorizationContext(request, matchResult.getVariables()));
}
}
// 沒有匹配的AuthorizationManager則返回拒絕當(dāng)前請(qǐng)求
return DENY;
}
}
可見，在沒有匹配的AuthorizationManager的情況下，默認(rèn)是拒絕請(qǐng)求的。
總結(jié)
-
我們?cè)谂渲弥信渲玫膗rl被封裝成RequestMatcher，而hasRole被封裝成AuthorityAuthorizationManager。進(jìn)行注冊(cè)，在請(qǐng)求過來時(shí)，便通過遍歷所有注冊(cè)好的RequestMatch進(jìn)行匹配，存在匹配就調(diào)用
AuthorizationManager<RequestAuthorizationContext>#check方法。 -
配置的鏈?zhǔn)秸{(diào)用，會(huì)跨越多個(gè)不同的類，最終又回到第一個(gè)對(duì)象的類型。文章來源：http://www.zghlxwxcb.cn/news/detail-847816.html
后記
本文我們聊了基于HttpRequest配置權(quán)限的方方面面。相信這里有一個(gè)點(diǎn)應(yīng)該會(huì)引起大家的注意：配置。下一次，我們聊聊Spring Security的配置體系。文章來源地址http://www.zghlxwxcb.cn/news/detail-847816.html
到了這里，關(guān)于Spring Security之基于HttpRequest配置權(quán)限的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
