0.簡介 Abp 本身集成了一套許可權驗證體系,通過 ASP.NET Core 的過濾器與 Castle 的攔截器進行攔截請求,併進行許可權驗證。在 Abp 框架內部,許可權分為兩塊,一個是功能(Feature),一個是許可權項(Permission),在更多的時候兩者僅僅是概念不同而已,大體處理流程還是一 ...
0.簡介
Abp 本身集成了一套許可權驗證體系,通過 ASP.NET Core 的過濾器與 Castle 的攔截器進行攔截請求,併進行許可權驗證。在 Abp 框架內部,許可權分為兩塊,一個是功能(Feature),一個是許可權項(Permission),在更多的時候兩者僅僅是概念不同而已,大體處理流程還是一樣的。
由於 Abp 本身是針對多租戶架構進行設計的,功能是相對於租戶而言,比如針對 A 租戶他每月的簡訊發送配額為 10000 條,而針對 B 租戶其配額為 5000 條,可能 C 租戶該功能都沒有開通。
本篇文章僅針對基本的驗證機制進行解析,後續文章會進行詳解。
0.1 驗證流程圖
1.啟動流程
1.1 流程圖
1.2 代碼流程
首先在註入 Abp 框架的時候,通過註入過濾器一起將許可權驗證過濾器進行了註入。
internal static class AbpMvcOptionsExtensions
{
// ... 其他代碼
private static void AddFilters(MvcOptions options)
{
// ... 其他註入的過濾器
options.Filters.AddService(typeof(AbpAuthorizationFilter));
// ... 其他註入的過濾器
}
// ... 其他代碼
}
Abp 除了攔截驗證 API 介面,同時也通過 Castle Windsor Interceptor 來驗證普通類型的方法,來檢測當前用戶是否有許可權進行調用。攔截器的註冊則是存放在 AbpBootstrapper
對象初始化的時候,通過 AddInterceptorRegistrars()
方法註入 Abp 自帶的攔截器對象。
private AbpBootstrapper([NotNull] Type startupModule, [CanBeNull] Action<AbpBootstrapperOptions> optionsAction = null)
{
Check.NotNull(startupModule, nameof(startupModule));
var options = new AbpBootstrapperOptions();
optionsAction?.Invoke(options);
// 其他初始化代碼
// 判斷用戶在啟用 Abp 框架的是時候是否禁用了所有的攔截器
if (!options.DisableAllInterceptors)
{
// 初始化攔截器
AddInterceptorRegistrars();
}
}
private void AddInterceptorRegistrars()
{
// 參數驗證攔截器註冊
ValidationInterceptorRegistrar.Initialize(IocManager);
// 審計信息記錄攔截器註冊
AuditingInterceptorRegistrar.Initialize(IocManager);
// 實體變更追蹤攔截器註冊
EntityHistoryInterceptorRegistrar.Initialize(IocManager);
// 工作單元攔截器註冊
UnitOfWorkRegistrar.Initialize(IocManager);
// 授權攔截器註冊
AuthorizationInterceptorRegistrar.Initialize(IocManager);
}
Abp 通過註入過濾器與攔截器就能夠從源頭驗證並控制許可權校驗邏輯,以上就是 Abp 在啟動時所做的操作。
2.代碼分析
總體來說,Abp 針對許可權的驗證就是攔截+檢測,整體思路即是這樣,只是實現可能略微複雜,請耐心往下看。
2.1 許可權攔截器與許可權過濾器
首先我們從入口點開始分析代碼,在上一節我們說過 Abp 通過攔截器與過濾器來實現許可權的攔截與處理,那麼在其內部是如何進行處理的呢?
其實很簡單,在許可權攔截器與許可權過濾器的內部實現都使用了 IAuthorizationHelper
的 AuthorizeAsync()
方法來進行許可權校驗。
2.1.1 許可權過濾器代碼實現
public class AbpAuthorizationFilter : IAsyncAuthorizationFilter, ITransientDependency
{
public ILogger Logger { get; set; }
// 許可權驗證類,這個才是真正針對許可權進行驗證的對象
private readonly IAuthorizationHelper _authorizationHelper;
// 異常包裝器,這個玩意兒在我的《[Abp 源碼分析]十、異常處理》有講,主要是用來封裝沒有授權時返回的錯誤信息
private readonly IErrorInfoBuilder _errorInfoBuilder;
// 事件匯流排處理器,同樣在我的《[Abp 源碼分析]九、事件匯流排》有講,在這裡用於觸發一個未授權請求引發的事件,用戶可以監聽此事件來進行自己的處理
private readonly IEventBus _eventBus;
// 構造註入
public AbpAuthorizationFilter(
IAuthorizationHelper authorizationHelper,
IErrorInfoBuilder errorInfoBuilder,
IEventBus eventBus)
{
_authorizationHelper = authorizationHelper;
_errorInfoBuilder = errorInfoBuilder;
_eventBus = eventBus;
Logger = NullLogger.Instance;
}
public async Task OnAuthorizationAsync(AuthorizationFilterContext context)
{
// 如果註入了 IAllowAnonymousFilter 過濾器則允許所有匿名請求
if (context.Filters.Any(item => item is IAllowAnonymousFilter))
{
return;
}
// 如果不是一個控制器方法則直接返回
if (!context.ActionDescriptor.IsControllerAction())
{
return;
}
// 開始使用 IAuthorizationHelper 來進行許可權校驗
try
{
await _authorizationHelper.AuthorizeAsync(
context.ActionDescriptor.GetMethodInfo(),
context.ActionDescriptor.GetMethodInfo().DeclaringType
);
}
// 如果是未授權異常的處理邏輯
catch (AbpAuthorizationException ex)
{
// 記錄日誌
Logger.Warn(ex.ToString(), ex);
// 觸發異常事件
_eventBus.Trigger(this, new AbpHandledExceptionData(ex));
// 如果介面的返回類型為 ObjectResult,則採用 AjaxResponse 對象進行封裝信息
if (ActionResultHelper.IsObjectResult(context.ActionDescriptor.GetMethodInfo().ReturnType))
{
context.Result = new ObjectResult(new AjaxResponse(_errorInfoBuilder.BuildForException(ex), true))
{
StatusCode = context.HttpContext.User.Identity.IsAuthenticated
? (int) System.Net.HttpStatusCode.Forbidden
: (int) System.Net.HttpStatusCode.Unauthorized
};
}
else
{
context.Result = new ChallengeResult();
}
}
// 其他異常則顯示為內部異常信息
catch (Exception ex)
{
Logger.Error(ex.ToString(), ex);
_eventBus.Trigger(this, new AbpHandledExceptionData(ex));
if (ActionResultHelper.IsObjectResult(context.ActionDescriptor.GetMethodInfo().ReturnType))
{
context.Result = new ObjectResult(new AjaxResponse(_errorInfoBuilder.BuildForException(ex)))
{
StatusCode = (int) System.Net.HttpStatusCode.InternalServerError
};
}
else
{
//TODO: How to return Error page?
context.Result = new StatusCodeResult((int)System.Net.HttpStatusCode.InternalServerError);
}
}
}
}
2.1.2 許可權攔截器初始化綁定
許可權攔截器在 Abp 框架初始化完成的時候就開始監聽了組件註冊事件,只要被註入的類型實現了 AbpAuthorizeAttribute
特性與 RequiresFeatureAttribute
特性都會被註入 AuthorizationInterceptor
攔截器。
internal static class AuthorizationInterceptorRegistrar
{
public static void Initialize(IIocManager iocManager)
{
// 監聽 DI 組件註冊事件
iocManager.IocContainer.Kernel.ComponentRegistered += Kernel_ComponentRegistered;
}
private static void Kernel_ComponentRegistered(string key, IHandler handler)
{
// 判斷註入的類型是否符合要求
if (ShouldIntercept(handler.ComponentModel.Implementation))
{
// 符合要求,針對該組件添加許可權攔截器
handler.ComponentModel.Interceptors.Add(new InterceptorReference(typeof(AuthorizationInterceptor)));
}
}
private static bool ShouldIntercept(Type type)
{
if (SelfOrMethodsDefinesAttribute<AbpAuthorizeAttribute>(type))
{
return true;
}
if (SelfOrMethodsDefinesAttribute<RequiresFeatureAttribute>(type))
{
return true;
}
return false;
}
private static bool SelfOrMethodsDefinesAttribute<TAttr>(Type type)
{
// 判斷傳入的 Type 有定義 TAttr 類型的特性
if (type.GetTypeInfo().IsDefined(typeof(TAttr), true))
{
return true;
}
// 或者說,該類型的所有公開的方法是否有方法標註了 TAttr 類型的特性
return type
.GetMethods(BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic)
.Any(m => m.IsDefined(typeof(TAttr), true));
}
}
2.1.3 許可權攔截器實現
Abp 框架針對許可權攔截器的實現則是簡單了許多,只是在被攔截的方法在執行的時候,會直接使用 IAuthorizationHelper
進行許可權驗證。
public class AuthorizationInterceptor : IInterceptor
{
private readonly IAuthorizationHelper _authorizationHelper;
public AuthorizationInterceptor(IAuthorizationHelper authorizationHelper)
{
_authorizationHelper = authorizationHelper;
}
public void Intercept(IInvocation invocation)
{
// 使用 IAuthorizationHelper 進行許可權驗證
_authorizationHelper.Authorize(invocation.MethodInvocationTarget, invocation.TargetType);
invocation.Proceed();
}
}
2.2 許可權特性
在 Abp 框架裡面定義了兩組特性,第一個是 AbpMvcAuthorizeAttribute
,適用於 MVC 控制器,它是直接繼承了 ASP .NET Core 自帶的許可權驗證特性 AuthorizeAttribute
,當控制器或者控制器內部的方法標註了該特性,就會進入之前 Abp 定義的許可權過濾器 AbpAuthorizationFilter
內部。
第二種特性則是 AbpAuthorizeAttribute
,該特性適用於應用服務層,也就是實現了 IApplicationService
介面的類型所使用的。
它們兩個的內部定義基本一樣,傳入一個或者多哦個具體的許可權項,以便給 IAuthorizationHelper
作驗證使用。
在 Abp 框架內部,每一個許可權其實就是一個字元串,比如說用戶資料新增,是一個許可權,那麼你可以直接創建一個 "Administration.UserManagement.CreateUser"
字元作為其許可權項,那麼代碼示例就如下:
[AbpAuthorize("Administration.UserManagement.CreateUser")]
public void CreateUser(CreateUserInput input)
{
// 如果用戶沒有 Administration.UserManagement.CreateUser 許可權,則不會進入到本方法
}
下麵是 AbpAuthorizeAttribute
許可權特性的定義,另外一個 MVC 許可權特性定義也是一樣的:
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true)]
public class AbpAuthorizeAttribute : Attribute, IAbpAuthorizeAttribute
{
// 特性擁有的許可權項集合
public string[] Permissions { get; }
// 用於確定是否需要驗證用戶是否擁有 Permission 數組內所有許可權項,如果為 True 則用戶需要擁有所有許可權才能夠操作介面,如果為 False 的話,用戶只要擁有其中一個許可權項則可以通過驗證,預設值為:False
public bool RequireAllPermissions { get; set; }
public AbpAuthorizeAttribute(params string[] permissions)
{
Permissions = permissions;
}
}
許可權特性一般都會打在你的控制器/應用服務層的類定義,或者方法之上,當你為你的 API 介面標註了許可權特性,那麼當前請求的用戶沒有所需要的許可權,則一律會被攔截器/過濾器阻止請求。
2.3 許可權驗證
當如果用戶請求的方法或者控制器是標註了授權特性的話,都會通過 IAuthorizationHelper
進行驗證,它一共有兩個公開方法。
public interface IAuthorizationHelper
{
// 判斷用戶是否擁有一組許可權特性所標註的許可權
Task AuthorizeAsync(IEnumerable<IAbpAuthorizeAttribute> authorizeAttributes);
// 判斷用戶是否擁有,被調用的方法所標註的許可權
Task AuthorizeAsync(MethodInfo methodInfo, Type type);
}
在其預設的實現當中,註入了兩個相對重要的組件,第一個是 IAbpSession
,它是 Abp 框架定義的用戶會話狀態,如果當前用戶處於登錄狀態的時候,其內部必定有值,在這裡主要用於判斷用戶是否登錄。
第二個則是 IPermissionChecker
,它則是用於具體的檢測邏輯,如果說 IAuthorizationHelper
是用來提供許可權驗證的工具,那麼 IPermissionChecker
就是許可權驗證的核心,在 IPermissionChecker
內部則是真正的對傳入的許可權進行了驗證邏輯。
IPermissionChecker
本身只有兩個方法,都返回的 bool
值,有許可權則為 true
沒有則為 false
,其介面定義如下:
// 許可權檢測器
public interface IPermissionChecker
{
// 傳入一個許可權項的值,判斷當前用戶是否擁有該許可權
Task<bool> IsGrantedAsync(string permissionName);
// 傳入一個用戶標識,判斷該用戶是否擁有制定的許可權項
Task<bool> IsGrantedAsync(UserIdentifier user, string permissionName);
}
可以看到 Abp 框架本身針對於設計來說,都考慮了各個組件的可替換性與擴展性,你可以隨時通過替換 IAuthorizationHelper
或者是 IPermissionChecker
的實現來達到自己想要的效果,這點值得我們在編寫代碼的時候學習。
說了這麼多,下麵我們來看一下 IAuthorizationHelper
的具體實現吧:
public class AuthorizationHelper : IAuthorizationHelper, ITransientDependency
{
public IAbpSession AbpSession { get; set; }
public IPermissionChecker PermissionChecker { get; set; }
public IFeatureChecker FeatureChecker { get; set; }
public ILocalizationManager LocalizationManager { get; set; }
private readonly IFeatureChecker _featureChecker;
private readonly IAuthorizationConfiguration _authConfiguration;
public AuthorizationHelper(IFeatureChecker featureChecker, IAuthorizationConfiguration authConfiguration)
{
_featureChecker = featureChecker;
_authConfiguration = authConfiguration;
AbpSession = NullAbpSession.Instance;
PermissionChecker = NullPermissionChecker.Instance;
LocalizationManager = NullLocalizationManager.Instance;
}
public virtual async Task AuthorizeAsync(IEnumerable<IAbpAuthorizeAttribute> authorizeAttributes)
{
// 判斷是否啟用了授權系統,沒有啟用則直接跳過不做驗證
if (!_authConfiguration.IsEnabled)
{
return;
}
// 如果當前的用戶會話狀態其 SessionId 沒有值,則說明用戶沒有登錄,拋出授權驗證失敗異常
if (!AbpSession.UserId.HasValue)
{
throw new AbpAuthorizationException(
LocalizationManager.GetString(AbpConsts.LocalizationSourceName, "CurrentUserDidNotLoginToTheApplication")
);
}
// 遍歷所有授權特性,通過 IPermissionChecker 來驗證用戶是否擁有這些特性所標註的許可權
foreach (var authorizeAttribute in authorizeAttributes)
{
await PermissionChecker.AuthorizeAsync(authorizeAttribute.RequireAllPermissions, authorizeAttribute.Permissions);
}
}
// 授權過濾器與授權攔截器調用的方法,傳入一個方法定義與方法所在的類的類型
public virtual async Task AuthorizeAsync(MethodInfo methodInfo, Type type)
{
// 檢測產品功能
await CheckFeatures(methodInfo, type);
// 檢測許可權
await CheckPermissions(methodInfo, type);
}
protected virtual async Task CheckFeatures(MethodInfo methodInfo, Type type)
{
var featureAttributes = ReflectionHelper.GetAttributesOfMemberAndType<RequiresFeatureAttribute>(methodInfo, type);
if (featureAttributes.Count <= 0)
{
return;
}
foreach (var featureAttribute in featureAttributes)
{
// 檢查當前用戶是否啟用了被調用方法標註上面的功能
await _featureChecker.CheckEnabledAsync(featureAttribute.RequiresAll, featureAttribute.Features);
}
}
protected virtual async Task CheckPermissions(MethodInfo methodInfo, Type type)
{
// 判斷是否啟用了授權系統,沒有啟用則直接跳過不做驗證
if (!_authConfiguration.IsEnabled)
{
return;
}
// 判斷方法或者控制器類上是否標註了匿名訪問特性,如果標註了,不做許可權驗證
if (AllowAnonymous(methodInfo, type))
{
return;
}
// 獲得方法和類上面定義的所有許可權特性數組
var authorizeAttributes =
ReflectionHelper
.GetAttributesOfMemberAndType(methodInfo, type)
.OfType<IAbpAuthorizeAttribute>()
.ToArray();
// 如果一個都不存在,跳過驗證
if (!authorizeAttributes.Any())
{
return;
}
// 傳入所有許可權特性,調用另外一個重載方法,使用 IPermissionChecker 針對這些特性進行具體驗證
await AuthorizeAsync(authorizeAttributes);
}
private static bool AllowAnonymous(MemberInfo memberInfo, Type type)
{
return ReflectionHelper
.GetAttributesOfMemberAndType(memberInfo, type)
.OfType<IAbpAllowAnonymousAttribute>()
.Any();
}
}
看完上面你似乎並沒有看到哪兒有拋出 AbpAuthorizationException
的地方,這是因為 Abp 給 IPermissionChecker
添加了一個擴展方法,叫做 AuthorizeAsync()
,看他的具體實現你就知道,它在這個擴展方法裡面才真正調用了 IPermissionChecker.IsGrantedAsync()
方法進行許可權驗證。
public static async Task AuthorizeAsync(this IPermissionChecker permissionChecker, bool requireAll, params string[] permissionNames)
{
// 這裡還是調用的一個擴展方法,其內部是遍歷傳入的許可權項集合,針對每一個許可權進行檢測
if (await IsGrantedAsync(permissionChecker, requireAll, permissionNames))
{
return;
}
// 這兒呢就是本地化許可權的名稱,用於拋出異常的時候給前端展示用的,裡面提列了你缺少的許可權項有哪些
var localizedPermissionNames = LocalizePermissionNames(permissionChecker, permissionNames);
if (requireAll)
{
throw new AbpAuthorizationException(
string.Format(
L(
permissionChecker,
"AllOfThesePermissionsMustBeGranted",
"Required permissions are not granted. All of these permissions must be granted: {0}"
),
string.Join(", ", localizedPermissionNames)
)
);
}
else
{
throw new AbpAuthorizationException(
string.Format(
L(
permissionChecker,
"AtLeastOneOfThesePermissionsMustBeGranted",
"Required permissions are not granted. At least one of these permissions must be granted: {0}"
),
string.Join(", ", localizedPermissionNames)
)
);
}
}
如果你感覺自己快被繞暈了,也不必驚慌...因為 IPermissionChecker
本身只能針對單個許可權進行檢查,所以這裡通過擴展了 IPermissionChecker
方法,使其能夠一次檢驗一個集合而已。
3.結語
本篇文章主要解析了 Abp 框架針對許可權驗證所做的基本操作,整體思路還是十分簡單的,在 Abp 基本框架沒有涉及到用戶與角色的具體許可權控制,這部分的內容是存放在 Abp.Zero 模塊當中的,下一篇文章將會結合 Abp.Zero 來進行更加詳細的講解許可權與功能的實現。