點擊上方藍字關注我們

0.簡介

承接上篇文章我們會在這篇文章詳細解說一下 Abp 是如何結合?IPermissionChecker?與?IFeatureChecker?來實現一個完整的多租戶系統的權限校驗的。

1.多租戶的概念

多租戶系統又被稱之為?Saas?，比如阿里云就是一個典型的多租戶系統，用戶本身就是一個租戶，可以在上面購買自己的 ECS 實例，并且自己的數據與其他使用者(租戶)所隔絕，兩者的數據都是不可見的。

那么 Abp 是如何實現數據隔離的呢？

1.1 單部署-單數據庫

如果你的軟件系統僅部署一個實例，并且所有租戶的數據都是存放在一個數據庫里面的，那么可以通過一個?TenantId?(租戶 Id) 來進行數據隔離。那么當我們執行 SELECT 操作的時候就會附加上當前登錄用戶租戶 Id 作為過濾條件，那么查出來的數據也僅僅是當前租戶的數據，而不會查詢到其他租戶的數據。

1.2 單部署-多數據庫

Abp 還提供了另外一種方式，即為每一個租戶提供一個單獨的數據庫，在用戶登錄的時候根據用戶對應的租戶 ID，從一個數據庫連接映射表獲取到當前租戶對應的數據庫連接字符串，并且在查詢數據與寫入數據的時候，不同租戶操作的數據庫是不一樣的。

2.多租戶系統的權限驗證

從上一篇文章我們知道了在權限過濾器與權限攔截器當中，最終會使用?IFeatureChecker?與?IPermissionChecker?來進行權限校驗，并且它還持久一個用戶會話狀態?IAbpSession?用于存儲識別當前訪問網站的用戶是誰。

2.1 用戶會話狀態

基本做過網站程序開發的同學都知道用于區分每一個用戶，我們需要通過 Session 來保存當前用戶的狀態，以便進行權限驗證或者其他操作。而 Abp 框架則為我們定義了一個統一的會話狀態接口?IAbpSession?，用于標識當前用戶的狀態。在其接口當中主要定義了三個重要的屬性，第一個?UserId?(用戶 Id)，第二個就是?TenantId?(租戶 Id)，以及用于確定當前用戶是租戶還是租主的?MultiTenancySides?屬性。

除此之外，還擁有一個?Use()?方法，用戶在某些時候臨時替換掉當前用戶的?UserId?與?TenantId?的值，這個方法在我的?《Abp + Grpc 如何實現用戶會話狀態傳遞》?文章當中有講到過。

而針對這個方法的實現又可以扯出一大堆知識，這塊我們放在后面再進行精講，這里我們還是主要通篇講解一下多租戶體系下的數據過濾與權限驗證。

2.1.1 默認會話狀態的實現

IAbpSession?當中的值默認是從 JWT 當中取得的，這取決于它的默認實現?ClaimsAbpSession，它還繼承了一個抽象父類?AbpSessionBase?，這個父類主要是實現了?Use()?方法，這里略過。

在其默認實現里面，重載了?UserId?與?TenantId?的獲取方法。

public override long? UserId {get{// ... 其他代碼var userIdClaim = PrincipalAccessor.Principal?.Claims.FirstOrDefault(c => c.Type == AbpClaimTypes.UserId);// ... 其他代碼long userId;if (!long.TryParse(userIdClaim.Value, out userId)) return null;return userId;} }

可以看到這里是通過?PrincipalAccessor?從當前請求的請求頭中獲取 Token ，并從?Claims?里面獲取 Type 值為?AbpClaimTypes.UserId?的對象，將其轉換為?long?類型的?UserId，這樣就拿到了當前用戶登錄的 Id 了。

2.1.2 獲取當前請求的用戶狀態

這里的?PrincipalAccessor?是一個?IPrincipalAccessor?接口，在 ASP .NET Core 庫當中他的實現名字叫做?AspNetCorePrincipalAccessor。其實你應該猜得到，在這個類的構造函數當中，注入了?HttpContext?的訪問器對象?IHttpContextAccessor，這樣?IAbpSession?就可以輕而易舉地獲得當前請求上下文當中的具體數據了。

public class AspNetCorePrincipalAccessor : DefaultPrincipalAccessor {public override ClaimsPrincipal Principal => _httpContextAccessor.HttpContext?.User ?? base.Principal;private readonly IHttpContextAccessor _httpContextAccessor;public AspNetCorePrincipalAccessor(IHttpContextAccessor httpContextAccessor){_httpContextAccessor = httpContextAccessor;} }

2.1.3 小結

所以，Abp 通過?IAbpSession?可以輕松地知道我們當前用戶的狀態，包括用戶 Id 與租戶 Id，它只需要知道這兩個東西，就可以很簡單的在?IFeatureChecker?和?IPermissionChecker?當中來查詢用戶所綁定的權限來進行驗證。

2.2 功能(Feature)

首先我們的思緒回到上一章所講的?AuthorizationHelper?類，在其?AuthorizeAsync()?方法當中，使用?IFeatureChecker?來檢測用戶是否擁有某種功能。

public virtual async Task AuthorizeAsync(MethodInfo methodInfo, Type type) {// 檢測功能await CheckFeatures(methodInfo, type);// 檢測權限await CheckPermissions(methodInfo, type); }

然后呢，在?IFeatureChecker.CheckFeatures()?方法的內部，跟?IPermissionChecker?的套路一樣，這里仍然是一個擴展方法，遍歷方法/類上標記的?[RequiresFeatureAttribute]?特性，調用?IFeatureChecker?的?GetValueAsync()?方法傳入功能的名稱，然后將其值與?"true"?相比較，為真則是啟用了該功能，其他值則說明沒有啟用。

public static async Task<bool> IsEnabledAsync(this IFeatureChecker featureChecker, string featureName) {// 檢查是否啟用return string.Equals(await featureChecker.GetValueAsync(featureName), "true", StringComparison.OrdinalIgnoreCase); }

IFeatureChecker?的定義：

public interface IFeatureChecker {// 傳入功能名字，獲取真這對于當前租戶其默認值Task<string> GetValueAsync(string name);// 傳入租戶 Id 與功能名字，獲取針對于指定 Id 租戶的默認值Task<string> GetValueAsync(int tenantId, string name); }

到這一步我們仍然是跟?IFeatureChecker?打交道，那么他的具體實現是怎樣的呢？

先來看一下這個?IFeatureChecker?的依賴關系圖：

目前看起來還是比較簡單，他擁有一個默認實現?FeatureChecker?，其中?IFeatureValueStore?從名字就可以知道它是用來存儲功能列表的，而?IFeatureManager?則是用來管理這些功能的，Feature?則是這些功能的定義。

結合之前在?IsEnabledAsync()?方法的調用，可以看到它先進入的?GetValueAsync(string name)?方法，判斷當前用戶的租戶 Id 是否有值，如果沒有值則直接拋出異常，中斷權限驗證。如果有值得話，傳入當前登錄用戶的租戶 Id ，從?IFeatureManager?當中獲取到定義的權限，之后呢從?IFeatureValueStore?當中拿到功能具體的值，因為功能是針對租戶而言的，所以一個功能針對于多個租戶的值肯定是不同的，所以在這里查詢具體值的時候需要傳入租戶 Id。

public class FeatureChecker : IFeatureChecker, ITransientDependency {public IAbpSession AbpSession { get; set; }public IFeatureValueStore FeatureValueStore { get; set; }private readonly IFeatureManager _featureManager;public FeatureChecker(IFeatureManager featureManager){_featureManager = featureManager;FeatureValueStore = NullFeatureValueStore.Instance;AbpSession = NullAbpSession.Instance;}public Task<string> GetValueAsync(string name){// 判斷當前登錄的用戶是否擁有租戶 IDif (!AbpSession.TenantId.HasValue){throw new AbpException("FeatureChecker can not get a feature value by name. TenantId is not set in the IAbpSession!");}// 傳入當前登錄用戶的租戶 Id ，獲取其值return GetValueAsync(AbpSession.TenantId.Value, name);}public async Task<string> GetValueAsync(int tenantId, string name){// 從功能管理器根據名字查詢用戶定義的功能var feature = _featureManager.Get(name);// 獲得功能的值，如果沒有值則返回其默認值var value = await FeatureValueStore.GetValueOrNullAsync(tenantId, feature);if (value == null){return feature.DefaultValue;}return value;} }

聰明的你肯定猜到功能其實是用戶在代碼當中定義的，而功能的值則是存放在數據庫當中，每個租戶其值都是不一樣的。這是不是讓你想到了系列文章?《[Abp 源碼分析]五、系統設置》?SettingProvider?的實現呢？

So,這里的?IFeatureStore?的默認實現肯定是從數據庫進行配置咯~

2.2.1 功能的定義

首先功能、權限都是樹形結構，他們都可以擁有自己的子節點，這樣可以直接實現針對父節點賦值而擁有其子節點的所有權限。這里先來看一下功能的的基本定義：

public class Feature {// 附加數據的一個索引器public object this[string key]{get => Attributes.GetOrDefault(key);set => Attributes[key] = value;}// 功能的附加數據public IDictionary<string, object> Attributes { get; private set; }// 父級功能public Feature Parent { get; private set; }// 功能的名稱public string Name { get; private set; }// 功能的展示名稱，這是一個本地化字符串public ILocalizableString DisplayName { get; set; }// 功能的描述，一樣的是一個本地化字符串public ILocalizableString Description { get; set; }// 功能的輸入類型public IInputType InputType { get; set; }// 功能的默認值public string DefaultValue { get; set; }// 功能所適用的范圍public FeatureScopes Scope { get; set; }// 如果當前功能的子節點的不可變集合public IReadOnlyList<Feature> Children => _children.ToImmutableList();private readonly List<Feature> _children;public Feature(string name, string defaultValue, ILocalizableString displayName = null, ILocalizableString description = null, FeatureScopes scope = FeatureScopes.All, IInputType inputType = null){Name = name ?? throw new ArgumentNullException("name");DisplayName = displayName;Description = description;Scope = scope;DefaultValue = defaultValue;InputType = inputType ?? new CheckboxInputType();_children = new List<Feature>();Attributes = new Dictionary<string, object>();}public Feature CreateChildFeature(string name, string defaultValue, ILocalizableString displayName = null, ILocalizableString description = null, FeatureScopes scope = FeatureScopes.All, IInputType inputType = null){var feature = new Feature(name, defaultValue, displayName, description, scope, inputType) { Parent = this };_children.Add(feature);return feature;}public override string ToString(){return string.Format("[Feature: {0}]", Name);} }

這玩意兒光看著頭還是有點疼的，其實就是關于功能的基礎定義，他為啥附帶了一個附加描述字典，因為可以存儲一些額外的信息，比如說一個短信功能，他的配額和到期時間，至于他的?Scope?則說明了它的生效范圍。

2.2.2 功能管理器

接著看看?GetValueAsync(int tenantId, string name)?方法的第一句：

var feature = _featureManager.Get(name);

emmm，我要從?IFeatureManager?根據權限名稱取得一個具體的?Feature?對象，那我們繼續來看一下?IFeatureManager?接口。

public interface IFeatureManager {// 根據名稱獲得一個具體的功能，這個名稱應該是唯一的Feature Get(string name);// 根據一個名稱獲得一個具體的功能，如果沒找到則返回 NULLFeature GetOrNull(string name);// 獲得所有定義的功能IReadOnlyList<Feature> GetAll(); }

2.2.3 功能管理器實現

在看具體實現的時候，我們先不慌，先看一下它實現類所繼承的東西。

internal class FeatureManager : FeatureDefinitionContextBase, IFeatureManager, ISingletonDependency

WTF，他又繼承了什么奇奇怪怪的東西。我們又在此來到?FeatureDefinitionContextBase?，經過一番探查總算知道這玩意兒實現自?IFeatureDefinitionContext,看看他的定義：

// 功能定義上下文，主要功能是提供給 FeatureProvider 來創建功能的 public interface IFeatureDefinitionContext {// 創建一個功能Feature Create(string name, string defaultValue, ILocalizableString displayName = null, ILocalizableString description = null, FeatureScopes scope = FeatureScopes.All, IInputType inputType = null);// 根據名稱獲得一個功能Feature GetOrNull(string name);// 移除一個功能void Remove(string name); }

所以，你要把這些功能存放在哪些地方呢？

其實看到這個玩意兒 name-value，答案呼之欲出，其實現內部肯定是用的一個字典來存儲數據的。

接著我們來到了?FeatureDefinitionContextBase?的默認實現?FeatureDefinitionContextBase，然后發現里面也是別有洞天，Abp 又把字典再次封裝了一遍，這次字典的名字叫做?FeatureDictionary，你只需要記住他只提供了一個作用，就是將字典內部的所有功能項與其子功能項按照平級關系存放在字典當中。

除了內部封裝了一個字典之外，在這個上下文當中，實現了創建，獲取，和移除功能的方法，然后就沒有了。我們再次回到功能管理器，

功能管理器集成了這個上下文基類，集合之前?IFeatureManager?所定義的接口，它就具備了隨時可以修改功能集的權力。那么這些功能是什么時候被定義的，而又是什么時候被初始化到這個字典的呢？

在前面我們已經說過，Feature 的增加與之前文章所講的系統設置是一樣的，他們都是通過集成一個 Provider ，然后在模塊預加載的時候，通過一個?IFeatureConfiguration?的東西被添加到 Abp 系統當中的。所以在?FeatureManager?內部注入了?IFeatureConfiguration?用來拿到用戶在模塊加載時所配置的功能項集合。

public interface IFeatureConfiguration {/// <summary>/// Used to add/remove <see cref="FeatureProvider"/>s./// </summary>ITypeList<FeatureProvider> Providers { get; } }

下面給你演示一下如何添加一個功能項：

public class AppFeatureProvider : FeatureProvider {public override void SetFeatures(IFeatureDefinitionContext context){var sampleBooleanFeature = context.Create("SampleBooleanFeature", defaultValue: "false");sampleBooleanFeature.CreateChildFeature("SampleNumericFeature", defaultValue: "10");context.Create("SampleSelectionFeature", defaultValue: "B");} }

不用猜測?FeatureProvier?的實現了，他就是一個抽象類，定義了一個?SetFeatures?方法好讓你實現而已。

之后我又在模塊的預加載方法吧?AppFeatureProvider?添加到了IFeatureConfiguration?里面：

public class XXXModule : AbpModule {public override void PreInitialize(){Configuration.Features.Providers.Add<AppFeatureProvider>();} }

而功能管理器則是在 Abp 核心模塊?AbpKernalModule?初始化的時候，跟著權限管理器和系統設置管理器，一起被初始化了。

public override void PostInitialize() {RegisterMissingComponents();// 這里是系統的設置的管理器IocManager.Resolve<SettingDefinitionManager>().Initialize();// 功能管理器在這里IocManager.Resolve<FeatureManager>().Initialize();// 權限管理器IocManager.Resolve<PermissionManager>().Initialize();IocManager.Resolve<LocalizationManager>().Initialize();IocManager.Resolve<NotificationDefinitionManager>().Initialize();IocManager.Resolve<NavigationManager>().Initialize();if (Configuration.BackgroundJobs.IsJobExecutionEnabled){var workerManager = IocManager.Resolve<IBackgroundWorkerManager>();workerManager.Start();workerManager.Add(IocManager.Resolve<IBackgroundJobManager>());} }

看看功能管理器的定義就知道了：

public void Initialize() {foreach (var providerType in _featureConfiguration.Providers){using (var provider = CreateProvider(providerType)){provider.Object.SetFeatures(this);}}Features.AddAllFeatures(); }

波瀾不驚的我早已看透一切，可以看到這里他通過遍歷注入的?FeatureProvider?集合，傳入自己，讓他們可以向自己注入定義的功能項。

2.2.4 功能的存儲

繼續看?IFeatureChecker?的代碼，最后從功能管理器拿到了功能項之后，就要根據租戶的 Id 取得它具體的值了。值還能存在哪兒，除了數據庫最合適放這種東西，其他的你愿意也可以存在 TXT 里面。

public interface IFeatureValueStore {// 很簡潔，你傳入當前用戶的租戶 Id 與 當前需要校驗的功能項，我給你他的值Task<string> GetValueOrNullAsync(int tenantId, Feature feature); }

廢話不多說，來到 Zero 關于這個功能存儲類的定義?AbpFeatureValueStore<TTenant,TUser>，你先不著急看那兩個泛型參數，這兩個泛型就是你的用戶與租戶實體，我們先看看這玩意兒繼承了啥東西：

public class AbpFeatureValueStore<TTenant, TUser> :IAbpZeroFeatureValueStore,ITransientDependency,IEventHandler<EntityChangedEventData<Edition>>,IEventHandler<EntityChangedEventData<EditionFeatureSetting>>where TTenant : AbpTenant<TUser>where TUser : AbpUserBase

可以看到它首先繼承了?IAbpZeroFeatureValueStore?接口，這里的?IAbpZeroFeatureValueStore?接口一樣的繼承的?IFeatureValueStore，所以在 Abp 底層框架能夠直接使用。

其次我們還看到它監聽了兩個實體變更事件，也就是 Edition 與 EditFeatureSettings 表產生變化的時候，會進入到本類進行處理，其實這里的處理就是發生改變之后，拿到改變實體的 Id，從緩存清除掉臟數據而已。

然后我們直奔主題，找到方法的實現：

public virtual Task<string> GetValueOrNullAsync(int tenantId, Feature feature) {return GetValueOrNullAsync(tenantId, feature.Name); }

發現又是一個空殼子，繼續跳轉：

public virtual async Task<string> GetValueOrNullAsync(int tenantId, string featureName) {// 首先從租戶功能值表獲取功能的值var cacheItem = await GetTenantFeatureCacheItemAsync(tenantId);// 獲得到值var value = cacheItem.FeatureValues.GetOrDefault(featureName);// 不等于空，優先獲取租戶的值而忽略掉版本的值if (value != null){return value;}// 如果租戶功能值表的緩存說我還有版本 Id，那么就去版本級別的功能值表查找功能的值if (cacheItem.EditionId.HasValue){value = await GetEditionValueOrNullAsync(cacheItem.EditionId.Value, featureName);if (value != null){return value;}}return null; }

這才是真正的獲取功能值的地方，其余方法就不再詳細講述，這兩個從緩存獲取的方法，都分別有一個工廠方法從數據庫拿去數據的，所以你也不用擔心緩存里面不存在值的情況。

2.2.5 小結

總的來說功能是針對租戶的一個權限，Abp 建議一個父母功能一般定義為?布爾功能。只有父母功能可用時，子功能才可用。ABP不強制這樣做，但是建議這樣做。

在一個基于 Abp 框架的系統功能權限是可選的，具體使用還是取決于你所開發的業務系統是否有這種需求。

2.3 權限(Permission)

2.3.1 權限的定義

權限的定義與 Feature 一樣，都是存放了一些基本信息，比如說權限的唯一標識，權限的展示名稱與描述，只不過少了 Feature 的附加屬性而已。下面我們就會加快進度來說明一下權限相關的知識。

2.3.2 權限檢測器

權限相比于功能，權限更加細化到了用戶與角色，角色通過與權限關聯，角色就是一個權限組的集合，用戶再跟角色進行關聯。看看權限管理器的定義吧：

public abstract class PermissionChecker<TRole, TUser> : IPermissionChecker, ITransientDependency, IIocManagerAccessorwhere TRole : AbpRole<TUser>, new()where TUser : AbpUser<TUser>

還是相對而言比較簡單的，在這里你只需要關注兩個東西：

public virtual async Task<bool> IsGrantedAsync(string permissionName) {return AbpSession.UserId.HasValue && await _userManager.IsGrantedAsync(AbpSession.UserId.Value, permissionName); }public virtual async Task<bool> IsGrantedAsync(long userId, string permissionName) {return await _userManager.IsGrantedAsync(userId, permissionName); }

這就是權限校驗的實現，第一個是傳入當前用戶的 Id 扔到?_userManager?進行校驗，而第二個則扔一個用戶制定的 Id 進行校驗。

看到這里，我們又該到下一節了，講解一下這個?_userManager?是何方神圣。

2.3.3 用戶管理器

如果讀者接觸過 ASP.NET Core MVC 的 Identity 肯定對于?UserManager<,>?不會陌生，沒錯，這里的?_userManager?就是繼承自?UserManager<TUser, long>,?實現的?AbpUserManager<TRole, TUser>。

繼續我們還是看關鍵方法?IsGrantedAsync()。

public virtual async Task<bool> IsGrantedAsync(long userId, string permissionName) {// 傳入用戶 ID 與需要檢測的權限,通過權限管理器獲得 Permission 對象return await IsGrantedAsync(userId,_permissionManager.GetPermission(permissionName)); }

還是個空殼子，繼續跳轉：

public virtual async Task<bool> IsGrantedAsync(long userId, Permission permission) {// 首先檢測當前用戶是否擁有租戶信息if (!permission.MultiTenancySides.HasFlag(GetCurrentMultiTenancySide())){return false;}// 然后檢測權限依賴的功能，如果功能沒有啟用，一樣的是沒權限的if (permission.FeatureDependency != null && GetCurrentMultiTenancySide() == MultiTenancySides.Tenant){FeatureDependencyContext.TenantId = GetCurrentTenantId();if (!await permission.FeatureDependency.IsSatisfiedAsync(FeatureDependencyContext)){return false;}}// 獲得當前用戶所擁有的權限，沒有權限一樣滾蛋var cacheItem = await GetUserPermissionCacheItemAsync(userId);if (cacheItem == null){return false;}// 檢測當前用戶是否被授予了特許權限，沒有的話則直接跳過，有的話說明這是個特權用戶，擁有這個特殊權限if (cacheItem.GrantedPermissions.Contains(permission.Name)){return true;}// 檢測禁用權限名單中是否擁有本權限，如果有，一樣的不通過if (cacheItem.ProhibitedPermissions.Contains(permission.Name)){return false;}// 檢測用戶角色是否擁有改權限foreach (var roleId in cacheItem.RoleIds){if (await RoleManager.IsGrantedAsync(roleId, permission)){return true;}}return false; }

這里我們沒有講解權限管理器與權限的注入是因為他們兩個簡直一毛一樣好吧，你可以看看權限的定義：

public class MyAuthorizationProvider : AuthorizationProvider {public override void SetPermissions(IPermissionDefinitionContext context){var administration = context.CreatePermission("Administration");var userManagement = administration.CreateChildPermission("Administration.UserManagement");userManagement.CreateChildPermission("Administration.UserManagement.CreateUser");var roleManagement = administration.CreateChildPermission("Administration.RoleManagement");} }

是不是感覺跟功能的 Provider 很像...

2.3.4 小結

權限僅僅會與用于和角色掛鉤，與租戶無關，它和功能的實現大同小異，但是也是值得我們借鑒學習的。

3.多租戶數據過濾

租戶與租戶之間是如何進行數據過濾的呢？

這里簡單講一下單部署-單數據庫的做法吧，在 EF Core 當中針對每一個實體都提供了一個全局過濾的方法?HasQueryFilter，有了這個東西，在每次 EF Core 進行查詢的時候都會將查詢表達式附加上你自定義的過濾器一起進行查詢。

在 Abp 內部定義了一個借口，叫做?IMustHaveTenant，這玩意兒有一個必須實現的屬性?TenantId，所以只要在你的實體繼承了該接口，肯定就是會有?TenantId?字段咯，那么 Abp 就可以先判斷你當前的實體是否實現了?IMusHaveTenant?接口，如果有的話，就給你創建了一個過濾器拼接到你的查詢表達式當中。

protected override void OnModelCreating(ModelBuilder modelBuilder) {// DbContext 模型創建的時候base.OnModelCreating(modelBuilder);// 遍歷所有 DbContext 定義的實體foreach (var entityType in modelBuilder.Model.GetEntityTypes()){ConfigureGlobalFiltersMethodInfo.MakeGenericMethod(entityType.ClrType).Invoke(this, new object[] { modelBuilder, entityType });} }protected void ConfigureGlobalFilters<TEntity>(ModelBuilder modelBuilder, IMutableEntityType entityType) where TEntity : class {// 判斷實體是否實現了租戶或者軟刪除接口，實現了則添加一個過濾器if (entityType.BaseType == null && ShouldFilterEntity<TEntity>(entityType)){var filterExpression = CreateFilterExpression<TEntity>();if (filterExpression != null){modelBuilder.Entity<TEntity>().HasQueryFilter(filterExpression);}} }// 數據過濾用的查詢表達式構建 protected virtual Expression<Func<TEntity, bool>> CreateFilterExpression<TEntity>()where TEntity : class {Expression<Func<TEntity, bool>> expression = null;if (typeof(ISoftDelete).IsAssignableFrom(typeof(TEntity))){/* This condition should normally be defined as below:* !IsSoftDeleteFilterEnabled || !((ISoftDelete) e).IsDeleted* But this causes a problem with EF Core (see https://github.com/aspnet/EntityFrameworkCore/issues/9502)* So, we made a workaround to make it working. It works same as above.*/Expression<Func<TEntity, bool>> softDeleteFilter = e => !((ISoftDelete)e).IsDeleted || ((ISoftDelete)e).IsDeleted != IsSoftDeleteFilterEnabled;expression = expression == null ? softDeleteFilter : CombineExpressions(expression, softDeleteFilter);}if (typeof(IMayHaveTenant).IsAssignableFrom(typeof(TEntity))){/* This condition should normally be defined as below:* !IsMayHaveTenantFilterEnabled || ((IMayHaveTenant)e).TenantId == CurrentTenantId* But this causes a problem with EF Core (see https://github.com/aspnet/EntityFrameworkCore/issues/9502)* So, we made a workaround to make it working. It works same as above.*/Expression<Func<TEntity, bool>> mayHaveTenantFilter = e => ((IMayHaveTenant)e).TenantId == CurrentTenantId || (((IMayHaveTenant)e).TenantId == CurrentTenantId) == IsMayHaveTenantFilterEnabled;expression = expression == null ? mayHaveTenantFilter : CombineExpressions(expression, mayHaveTenantFilter);}if (typeof(IMustHaveTenant).IsAssignableFrom(typeof(TEntity))){/* This condition should normally be defined as below:* !IsMustHaveTenantFilterEnabled || ((IMustHaveTenant)e).TenantId == CurrentTenantId* But this causes a problem with EF Core (see https://github.com/aspnet/EntityFrameworkCore/issues/9502)* So, we made a workaround to make it working. It works same as above.*/Expression<Func<TEntity, bool>> mustHaveTenantFilter = e => ((IMustHaveTenant)e).TenantId == CurrentTenantId || (((IMustHaveTenant)e).TenantId == CurrentTenantId) == IsMustHaveTenantFilterEnabled;expression = expression == null ? mustHaveTenantFilter : CombineExpressions(expression, mustHaveTenantFilter);}return expression; }

上面就是實現了，你每次使用 EF Core 查詢某個表的實體都會應用這個過濾表達式。

3.1 禁用過濾

但是可以看到在創建表達式的時候這里還有一些諸如?IsSoftDeleteFilterEnabled?的東西，這個就是用于你在某些時候需要禁用掉軟刪除過濾器的時候所需要用到的。

看看是哪兒來的：

protected virtual bool IsSoftDeleteFilterEnabled => CurrentUnitOfWorkProvider?.Current?.IsFilterEnabled(AbpDataFilters.SoftDelete) == true;

可以看到這個玩意兒是使用當前的工作單元來進行控制的，檢測當前工作單元的過濾器是否被啟用，如果實體被打了軟刪除接口，并且被啟用的話，那么就執行過濾，反之亦然。

這些過濾器都是放在?AbpDataFilters?當中的，現在有以下幾種定義：

public static class AbpDataFilters {public const string SoftDelete = "SoftDelete";public const string MustHaveTenant = "MustHaveTenant";public const string MayHaveTenant = "MayHaveTenant";public static class Parameters{public const string TenantId = "tenantId";} }

而這些過濾器是在?AbpKernelModule?的預加載方法當中被添加到 UOW 的默認配置當中的。

public override void PreInitialize() {// ... 其他代碼AddUnitOfWorkFilters();// ... 其他代碼 }private void AddUnitOfWorkFilters() {Configuration.UnitOfWork.RegisterFilter(AbpDataFilters.SoftDelete, true);Configuration.UnitOfWork.RegisterFilter(AbpDataFilters.MustHaveTenant, true);Configuration.UnitOfWork.RegisterFilter(AbpDataFilters.MayHaveTenant, true); }

這些東西被添加到了?IUnitOfWorkDefaultOptions?之后，每次初始化一個工作單元，其自帶的 Filiters 都是從這個?IUnitOfWorkDefaultOptions?拿到的，除非用戶顯式指定 UowOptions 配置。

作者：myzony

出處：https://www.cnblogs.com/myzony/p/9472483.html

公眾號“碼俠江湖”所發表內容注明來源的，版權歸原出處所有（無法查證版權的或者未注明出處的均來自網絡，系轉載，轉載的目的在于傳遞更多信息，版權屬于原作者。如有侵權，請聯系，筆者會第一時間刪除處理！

掃描二維碼

獲取更多精彩

碼俠江湖

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的[Abp 源码分析]多租户体系与权限验证的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。