目录
1、数据库迁移记录表(__efmigrationshistory)
7、实体属性值变化表(AbpEntityPropertyChanges)
10、租户和功能特性关联表(AbpFeatureValues)
11、连接外部身份验证提供程序用户与Abp系统用户之间关联(AbpLinkUsers)
12、组织机构与角色关联表(AbpOrganizationUnitRoles)
13、组织机构表(AbpOrganizationUnits)
14、具体权限授权记录表(AbpPermissionGrants)
20、应用程序定义设置表(AbpSettingDefinitions)
22、租户连接字符串信息表(AbpTenantConnectionStrings)
25、用户委派操作表(AbpUserDelegations)
26、第三方登录的用户关联信息表(AbpUserLogins)
27、用户组织机构关联表(AbpUserOrganizationUnits)
31、OpenIddict应用信息表(OpenIddictApplications)
32、OpenIddict授权信息表(OpenIddictAuthorizations)
33、OpenIddict的Scope信息表(OpenIddictScopes)
34、OpenIddict内部使用令牌(OpenIddictTokens)
一、引言
当我们通过ABP CLI初始化一个项目后,直接进行数据库迁移,即可得到一组基础的数据表,那么这些数据表都有什么用呢,本文将以“Abpvnext 7.4+OpenIddict”简单给大家梳理一下,梳理得不准确的,还望大家在评论区给予纠正。数据库迁移后的数据表如下:
二、理解
1、数据库迁移记录表(__efmigrationshistory)
该表的用途是记录Entity Framework Core的迁移历史,也就是记录数据库结构的变化历史。
该表只有两个字段:MigrationId
和ProductVersion
。其中,MigrationId
表示每个迁移的唯一标识符,ProductVersion
表示迁移所使用的Entity Framework Core版本。
__efmigrationshistory表与其他表没有直接的关联,但是它与应用程序的数据库结构密切相关。每次更改数据库结构时,Entity Framework Core都会自动将__efmigrationshistory表更新为最新版本的迁移标识符和Entity Framework Core版本号。因此,__efmigrationshistory表建议不要手动修改或删除。
2、操作详细信息表(AbpAuditLogactions)
字段结构如下:
字段名 | 数据类型 | 描述 |
---|---|---|
Id | bigint | 主键 |
AuditLogId | bigint | 关联的审计日志Id |
ServiceName | nvarchar(256) | 执行操作的服务名称 |
MethodName | nvarchar(256) | 执行操作的方法名称 |
Parameters | nvarchar(Max) | 执行操作的参数 |
ReturnValue | nvarchar(Max) | 执行操作的返回值 |
ExecutionTime | datetime | 执行操作的时间 |
ExecutionDuration | int | 执行操作的持续时间 |
ExtraProperties | nvarchar(Max) | 执行操作时其他的一些属性 |
AbpAuditLogActions表用于记录每一次执行操作的详细信息,包括操作的服务名称、方法名称、参数、返回值、执行时间、持续时间等。它是与AbpAuditLogs表相关联的,AbpAuditLogs表记录了每一次的审计日志,而AbpAuditLogActions表则记录了每一次操作的详细信息。其中,AuditLogId是AbpAuditLogs表的外键。
该表与其他表的关系如下:
- AbpAuditLogs表:该表与AbpAuditLogActions表存在一对多的关系,每一个AbpAuditLogs记录对应多个AbpAuditLogActions记录。
- AbpUsers表:该表与AbpAuditLogs表存在多对一的关系,每一个AbpAuditLogs记录对应一个AbpUser记录,表示该记录是由哪个用户操作产生的。
3、审计日志表(AbpAuditlogs)
AbpAuditLogs表是ABP框架自带的审计日志表,主要用于记录系统中的操作日志信息,包括创建、修改、删除等操作。该表的结构如下:
列名 | 数据类型 | 描述 |
---|---|---|
Id | bigint | 主键 |
ApplicationName | nvarchar(96) | 应用程序名称 |
TenantId | int? | 租户Id |
UserId | bigint? | 用户Id |
ServiceName | nvarchar(256) | 服务名称 |
MethodName | nvarchar(128) | 方法名称 |
Parameters | nvarchar(max) | 参数 |
ReturnValue | nvarchar(max) | 返回值 |
ExecutionTime | datetime | 执行时间 |
ExecutionDuration | int | 执行持续时间(毫秒) |
ClientIpAddress | nvarchar(64) | 客户端IP地址 |
ClientName | nvarchar(256) | 客户端名称 |
BrowserInfo | nvarchar(512) | 浏览器信息 |
Exception | nvarchar(max) | 异常信息 |
AbpAuditLogs表的作用是记录系统中发生的操作日志信息,用于追踪和排查问题。同时,该表也可以用于数据统计和分析,例如分析系统中各个服务的调用情况、用户操作行为等。
AbpAuditLogs表与其他表的关系是:它与AbpUsers和AbpTenants表关联,通过UserId和TenantId两个外键分别连接这两个表。这样,在记录操作日志时,系统可以自动获取当前用户和租户的信息,并将它们记录在AbpAuditLogs表中。
4、异步后台任务表(AbpBackgroundJobs)
AbpBackgroundJobs是ABP框架提供的一个用于存储异步后台任务的表。该表的主要作用是记录一些异步后台任务的信息,如任务的类型、参数、状态、优先级等。该表是ABP用来实现后台任务管理的核心表之一。
下面是在Abp vnext 7.4中使用表格展示AbpBackgroundJobs表的字段结构说明:
字段名称 | 数据类型 | 可空性 | 备注 |
---|---|---|---|
Id | bigint | Not Null | 主键 |
JobType | nvarchar(512) | Not Null | 任务类型 |
JobArgs | nvarchar(max) | Null | 任务参数 |
TryCount | tinyint | Not Null | 尝试次数 |
NextTryTime | datetime | Not Null | 下次尝试时间 |
LastTryTime | datetime | Null | 上次尝试时间 |
IsAbandoned | bit | Not Null | 是否已废弃 |
Priority | smallint | Not Null | 任务优先级 |
CreationTime | datetime | Not Null | 创建时间 |
CreatorUserId | bigint | Null | 创建人 |
TenantId | int | Null | 租户编号 |
该表与其他表有如下关系:
- AbpBackgroundJobs与AbpTenants表是多对一的关系,即一个后台任务只属于一个租户;
- AbpBackgroundJobs与AbpUsers表是多对一的关系,即一个后台任务只由一个用户创建;
- AbpBackgroundJobs与AbpEditions表是多对一的关系,即一个后台任务只属于一个版本。
5、声明类型表(AbpClaimTypes)
AbpClaimTypes表是ABP框架自带的一张数据库表,用于存储声明类型(ClaimType)的信息,它的结构如下:
列名 | 数据类型 | 说明 |
---|---|---|
Id | int | 主键 |
Name | nvarchar(256) | 声明类型的名称 |
Required | bit | 是否必须 |
IsStatic | bit | 是否为静态声明 |
Regex | nvarchar(512) | 判断声明的正则表达式 |
其中,每一行记录表示一个声明类型。Name表示声明类型的名称,Required表示是否必须,IsStatic表示是否为静态声明(静态声明是预定义的,不能被删除/修改),Regex表示用于验证该声明类型值的正则表达式。
AbpClaimTypes表的作用是提供一种管理声明类型(ClaimType)的方式,为声明(Claim)的处理提供支持。它是其他与声明相关的表的参考源,其中最主要的是AbpUserClaims表。AbpUserClaims表存储每个用户的声明信息,其中的ClaimType必须来自于AbpClaimTypes表中的一个声明类型。通过这两张表的关联,我们可以为用户定义自定义声明类型,并将其存储在用户声明中。
总之,AbpClaimTypes表是ABP框架中非常重要的一张表,它为声明(Claim)提供了定义、管理和验证声明类型的支持,并为用户声明(UserClaim)提供了必要的参考。
6、实体变更记录表(AbpEntityChanges)
AbpEntityChanges表是ABP框架中存储实体变更历史记录的表。它记录了实体的创建、修改和删除操作,包括实体属性的变化。该表的字段结构包括:
字段名 | 数据类型 | 描述 |
---|---|---|
Id | int | 主键 |
ChangeTime | datetime2 | 变更时间 |
ChangeType | int | 变更类型(0:新增,1:修改,2:删除) |
EntityChangeSetId | int | 关联的实体变更集合Id |
EntityId | string | 实体Id |
EntityTypeFullName | string | 实体类型全名 |
PropertyChanges | longblob | 实体属性变更内容(序列化后的JSON字符串,记录变更前后的属性值) |
AbpEntityChanges表与其他表的关系如下:
- AbpEntityChanges表与AbpUsers表关联,记录实体变更操作的用户信息。
- AbpEntityChanges表与AbpTenants表关联,记录实体的租户信息。
该表的作用是帮助开发人员追踪实体数据的变化历史,便于诊断和解决数据问题。同时,它还提供了数据审计功能,可以记录实体操作历史以供审计使用。
7、实体属性值变化表(AbpEntityPropertyChanges)
AbpEntityPropertyChanges表是ABP框架中的一张表,用于记录实体属性值的变化历史。该表的字段结构如下:
字段名 | 数据类型 | 说明 |
---|---|---|
Id | Guid | 主键 |
EntityChangeId | Guid | 对应实体变动的Id |
NewValue | string | 变化后的属性值 |
OriginalValue | string | 变化前的属性值 |
PropertyName | string | 属性名称 |
PropertyTypeFullName | string | 属性数据类型的完整名称 |
该表的用途和作用是记录实体属性值的变化历史,包括变化前的值、变化后的值、属性名称和属性数据类型的完整名称等。在实体变动日志记录中,通过这张表可以查看实体属性的变化历史。
该表与其他表的关系如下:
- AbpEntityChanges:AbpEntityPropertyChanges表是AbpEntityChanges表的从表,通过EntityChangeId字段与AbpEntityChanges表关联。
- AbpAuditLogs:AbpAuditLogs表是AbpEntityChanges表的从表,通过EntityId和EntityTypeFullName字段与AbpAuditLogs表关联。
8、功能组信息(AbpFeatureGroups)
AbpFeatureGroups表的字段结构如下:
字段名 | 类型 | 描述 |
---|---|---|
Id | Guid | 主键 |
TenantId | Guid? | 租户Id(可空) |
Name | string | 功能组名称 |
DisplayName | string | 功能组显示名称 |
ParentId | Guid? | 父级功能组Id(可空) |
Discriminator | string | 类型鉴别器 |
该表的用途和作用是存储功能组信息。它记录了所有的功能组,可以通过功能组对功能进行分类和管理。
“功能组”是指对系统中的功能按照一定的规则或分类进行分组管理的一种方式,常见于企业级应用开发中。以一个电商系统为例,设想该系统存在以下功能:商品管理、订单管理、用户管理、广告管理、统计分析等。可以将这些功能进行分组,如将商品管理和订单管理分为“交易管理”功能组,将用户管理和广告管理分为“系统管理”功能组,将统计分析单独分为一个“数据分析”功能组。这样的好处是方便用户在功能繁多的情况下快速找到需要的功能,同时也方便开发人员进行权限管理和代码维护。
该表与其他表的关系如下:
- 与AbpTenant表关联:TenantId字段关联AbpTenant表的Id字段,表示该功能组属于哪个租户。
- 与自身关联:ParentId字段关联自身的Id字段,表示当前功能组的父级功能组。
9、功能信息表(AbpFeatures)
AbpFeatures表是ABP框架中的一个表,用于存储系统中所有功能(feature)的信息。它的表格结构如下:
列名 | 数据类型 | 说明 |
---|---|---|
Name | nvarchar | 功能名称 |
Value | nvarchar | 功能的值 |
CreationTime | datetime | 功能创建时间 |
CreatorUserId | bigint | 创建者用户ID,如果为空则表明是匿名创建的 |
Discriminator | nvarchar | 此记录的类型 |
EditionId | int | 此功能所属的版本ID,如果为空则表明适用于所有版本 |
TenantId | int | 所属租户ID,如果为空则表明适用于所有租户 |
IsEnabled | bit | 功能是否启用 |
LastModifierUserId | bigint | 最近修改者用户ID,如果为空则表明是匿名修改的 |
LastModificationTime | datetime | 最近修改时间 |
MultiTenancySides | tinyint | 多租户支持类型(枚举值:Host, Tenant or Both) |
该表用于实现ABP框架中的功能管理及控制。通过该表记录每个功能的名称、所属版本、所属租户、是否启用等信息,在系统中对功能进行增加、修改、删除、启用或禁用等操作时,只需要修改该表的记录即可,而无需修改代码。
Abp框架中的功能(feature)是指系统具有的某个特定的功能、业务或模块,包括但不限于UI界面上的具体操作、服务方法、文件路径等。这种功能与我们平时理解的系统上的功能菜单、操作是有区别的。具体来说,区别主要体现在以下几个方面:
1. 定义层次不同:功能是系统中的一个概念,是依赖于后端代码和数据库的,而功能菜单、操作则是前端UI界面的一部分,是UI层的概念。在系统架构上,功能应该比功能菜单、操作更为基础。
2. 功能与权限的关系不同:在ABP框架中,功能与权限是分开的,功能只是一个标记,而权限则代表着用户对功能的访问权限。而在传统的系统中,菜单和功能操作通常作为权限的一部分,并且进行了更多的UI层面控制。
3. 维护方式不同:在ABP框架中,功能的维护是通过修改AbpFeatures表中的记录完成的,而功能菜单、操作的维护则需要改变UI层的代码和配置文件。
总的来说,功能(feature)是一个更为底层和抽象的概念,而功能菜单、操作则是对功能的UI呈现。在ABP框架中,将这些概念分离并进行统一管理,可以更好地解耦业务和UI,增加系统的灵活性和可维护性。
在ABP框架中,前端界面上的功能菜单和操作可以通过应用程序模块(Application Module)和Menu等相关类来定义和管理。这些类可以定义菜单和操作,还可以控制其显隐和访问权限等。因此,一般情况下不需要单独建表来管理前端界面上的功能菜单和操作。
如果需要与AbpFeatures表关联,可以利用Abp模块提供的功能,将菜单和操作定义成一个具有标识符的功能,再在AbpFeatures表中存储对应的功能标识符。这样可以将前端界面的菜单和操作与后端的管理功能对应起来,方便管理和维护。
需要注意的是,AbpFeatures表中的标识符是系统级别的,而菜单和操作则是应用程序级别的。因此,在将菜单和操作的功能标识符存储到AbpFeatures表中时,需要在标识符前加上应用程序模块的命名空间前缀。否则,可能会出现不同模块或应用程序之间的冲突。
ABP框架中,应用程序模块(Application Module)和Menu类是定义前端界面上的功能菜单和操作的重要类。下面是它们的简单介绍和使用方法:
1、应用程序模块(Application Module) 应用程序模块是一个类,它用来组织和定义应用程序中的功能和服务。在ABP框架中,每个应用程序模块都必须实现IAbpModule接口,并在启动时注册到ABP框架中。应用程序模块可以定义一系列服务、事件处理程序、领域事件订阅处理程序和菜单等内容。
定义应用程序模块的代码示例如下:
[DependsOn(typeof(AbpIdentityModule))]
public class MyModule : AbpModule
{
public override void ConfigureServices(ServiceConfigurationContext context)
{
// 添加自定义服务
context.Services.AddMyService();
// 定义菜单
Configure<AbpNavigationOptions>(options =>
{
options.MenuContributors.Add(new MyModuleMenuContributor());
});
}
// 实现菜单添加类
public class MyModuleMenuContributor : IMenuContributor
{
public virtual void AddContributions(MenuContributorContext context)
{
// 添加菜单项
context.Menu.AddItem(
new ApplicationMenuItem(
"MyModule",
L("Menu:MyModule"),
url: "/my-module",
icon: "fa fa-globe"
).AddItem(
new ApplicationMenuItem(
"MyModule.SubMenu",
L("Menu:MyModule.SubMenu")
)
)
);
}
}
在上面的代码中,我们定义一个名为“MyModule”的应用程序模块,它依赖于ABP框架中的身份验证模块(AbpIdentityModule)。在ConfigureServices方法中,我们添加了一个自定义服务,并通过Configure方法定义了一个菜单贡献器(MenuContributor),这个菜单贡献器可以贡献一个自定义的菜单项,包括菜单项的名称、URL、图标等信息。
2、Menu类 Menu类用来定义前端界面上的菜单和操作。在ABP框架中,每个菜单和操作都由一个Menu实例表示,并且可以通过一系列属性来定义菜单和操作的名称、URL、权限等信息。
定义菜单的示例如下:
var menuDefinition = new ApplicationMenuDefinition(
"MyMenu", // 菜单名称
L("Menu:MyMenu"), // 菜单显示名称
"~/MyMenu", // 菜单对应的URL
icon: "fa fa-globe", // 菜单图标
order: 0, // 菜单排序
requiredPermissionName: "MyApp.MyMenu" // 该菜单项所需权限
);
var subMenuDefinition = new ApplicationMenuDefinition(
"MySubMenu",
L("Menu:MySubMenu"),
"~/MyMenu/SubMenu",
order: 1,
requiredPermissionName: "MyApp.MySubMenu"
);
menuDefinition.Items.Add(subMenuDefinition);
在上面的代码中,我们定义了一个名为“MyMenu”的菜单,包含一个名为“MySubMenu”的子菜单。我们可以通过ApplicationMenuDefinition类的属性来定义菜单的相关信息,例如菜单名称、显示名称、URL、图标、排序、所需权限等信息。最后,我们将定义好的菜单添加到菜单项集合(Items)中。
通过使用上述应用程序模块和Menu类,我们可以方便地定义和管理前端界面上的菜单和操作。同时,我们可以通过定义所需权限来控制菜单和操作的访问权限,提高系统的安全性。
AbpFeatures表与其他表的关系如下:
- 与AbpEditions表的关系:该表用于记录某个功能所属版本,其EditionId列与AbpEditions表中的Id列相对应。
- 与AbpTenants表的关系:该表用于记录某个功能所属租户,其TenantId列与AbpTenants表中的Id列相对应。
- 与AbpFeaturesValue表的关系:该表用于存储ABP应用程序中已启用的功能的当前值,其Name列与AbpFeatures表中的Name列相对应。
10、租户和功能特性关联表(AbpFeatureValues)
AbpFeatureValues表是ABP框架中的一个表,用于存储租户和功能特性之间的关联关系,表结构如下:
字段名称 | 字段类型 | 说明 |
---|---|---|
Id | int | 主键 |
TenantId | int | 租户ID |
FeatureName | nvarchar(128) | 功能特性名称 |
Value | nvarchar(max) | 功能特性值 |
其中,租户ID (TenantId) 和功能特性名称 (FeatureName) 是该表的组合主键。
该表的作用是为租户提供功能特性的配置,即租户可以根据自己的需要来启用或禁用不同的功能特性。例如,在一个多租户的系统中,某些租户可能需要某些高级功能,而另一些租户可能并不需要这些功能。通过AbpFeatureValues表,系统管理员可以为各个租户配置不同的功能特性,从而实现更加个性化的服务。
AbpFeatureValues表与其他表的关系如下:
- 与AbpTenants表关联,通过租户ID (TenantId) 字段进行关联。
- 与AbpFeatures表关联,通过功能特性名称 (FeatureName) 字段进行关联。
11、连接外部身份验证提供程序用户与Abp系统用户之间关联(AbpLinkUsers)
AbpLinkUsers表的字段结构:
字段名 | 类型 | 说明 |
---|---|---|
TenantId | int | 租户ID |
UserId | long | 用户ID |
UserName | nvarchar(max) | 用户名 |
ExternalUserId | nvarchar(max) | 外部用户ID |
ExternalTenantId | nvarchar(max) | 外部租户ID |
LoginProvider | nvarchar(max) | 登录提供者名称 |
AbpLinkUsers表的用途和作用是用于存储连接外部身份验证提供程序(如Facebook,Google等)的用户与Abp系统用户之间的关联。当用户首次使用外部身份验证登录时,将创建此表的记录。该表列出了连接外部身份验证提供程序的用户的详细信息,以及将其关联到Abp系统用户的相关信息,如用户ID、用户名和登录提供商名称等。
AbpLinkUsers表与其他表的关系如下:
- AbpUsers表:AbpLinkUsers表中的“UserId”列是AbpUsers表的“Id”列的外键。
- AbpTenants表:AbpLinkUsers表中的“TenantId”列是AbpTenants表的“Id”列的外键。
12、组织机构与角色关联表(AbpOrganizationUnitRoles)
该表用于管理组织机构与角色之间关联关系的。其主要作用如下:
1. 组织机构成员角色分配:通过该数据表,可以为特定的组织机构成员分配不同的角色,从而实现对组织内部成员的权限管理和控制。
2. 组织机构角色管理:该数据表还可以用于管理组织机构所拥有的角色,包括新增、修改、删除等操作。
3. 组织机构与角色关系维护:基于该数据表,可以实现组织机构与所属角色之间的关系维护,包括角色的继承、转移等操作。
4. 组织架构管理:该数据表还可以被用于组织架构的管理,通过将组织机构关联到特定的角色上,可以实现组织架构的层级划分和管理。
总之,AbpOrganizationUnitRoles数据表是ABP框架中非常重要的一张数据表,对于组织单位和角色之间的关系管理和权限控制起到了关键的作用。具体数据表结构如下:
字段名称 | 类型 | 说明 |
RoleId | guid | 角色的唯一标识符,与AbpRoles数据表中的Id字段对应 |
OrganizationUnitId | guid | 组织机构的唯一标识符,与AbpOrganizationUnits数据表中的Id字段对应 |
TenantId | guid? | 租户Id,可为空 |
CreationTime | datetim | |
CreatorId | guid |
13、组织机构表(AbpOrganizationUnits)
组织架构信息,表字段结构如下图:
字段名称 | 类型 | 说明 |
Id | guid | 主键,自增长 |
TenantId | guid? | 租户Id,可为空 |
ParentId | guid? | 父节点Id,可为空,表示该节点为根节点 |
Code | varchar | 组织架构编码,用于识别该节点,必填,如:0005.0001 |
DisplayName | varchar | 组织架构显示名称,必填 |
EntityVersion | int | |
IsDeleted | bit | 该节点是否已删除,用于软删除,bool类型,默认为false |
DeleterId | guid? | 删除该节点的用户Id,可为空 |
DeletionTime | datetime? | 删除时间,可为空 |
LastModificationTime | datetime | 最后修改时间 |
LastModifierId | guid? | 最后修改该节点的用户Id,可为空 |
CreationTime | guid | 创建时间 |
CreatorId | guid? | 创建该节点的用户Id,可为空 |
14、具体权限授权记录表(AbpPermissionGrants)
AbpPermissionGrants表是ABP框架中用于存储授权信息的数据表,它记录了用户、角色和组织机构等实体与权限之间的关系。主要用途是支持权限授权和权限检查,确保系统中的资源只能被授权的用户、角色或组织机构访问。
记录某个指定角色、或者用户ID对应的具体权限表。具体权限记录的设计思路并非唯一,用户可以绑定角色,同时用户也可以单独授予角色以外的权限,此表将角色权限绑定表 和 用户权限绑定表融合成了一张表。
AbpPermissionGrants与其他表的关系如下:
- AbpRoles:AbpPermissionGrants中的RoleId与AbpRoles中的Id关联,表示一个角色拥有哪些权限。
- AbpUsers:AbpPermissionGrants中的UserId与AbpUsers中的Id关联,表示一个用户拥有哪些权限。
- AbpOrganizationUnits:AbpPermissionGrants中的OrganizationUnitId与AbpOrganizationUnits中的Id关联,表示一个组织机构拥有哪些权限。
- AbpPermissions:AbpPermissionGrants中的PermissionId与AbpPermissions中的Id关联,表示哪些权限被授权给了用户、角色或组织机构。
总之,AbpPermissionGrants是ABP框架中重要的权限管理数据表,用于实现系统的权限授权和权限检查功能,同时与其他实体关联,以实现更多的业务需求。
表字段结构如下图:
字段 | 类型 | 说明 |
Id | guid | 主键,自增长 |
TenantId | guid? | 租户Id,可为空 |
Name | nvarchar | 权限名称 |
ProviderName | nvarchar | 权限提供者的名称 |
ProviderKey | nvarchar | 权限提供者的键值。 键值是动态生成的,具体取决于应用程序中所使用的模块和插件。一般来说,ProviderKey 字段的键值由权限提供者的名称和版本号组成,例如:
需要注意的是,ProviderName 和 ProviderKey 两个字段的值必须同时匹配才能生效,否则该权限将不会被授予。因此,在进行权限控制时,需要确保 ProviderName 和 ProviderKey 的取值正确且唯一。 |
GrantTime | datetime | 授权时间 |
CreatorId | bigint | 创建人ID |
15、权限组信息(AbpPermissionGroups)
AbpPermissionGroups表是ABP框架中的一个权限相关的表,用于存储权限组信息。该表用途是将系统中的权限按照一定规则分组,方便管理和授权。权限分组可以在系统中对角色进行授权。
在使用ABP vNext框架开发应用程序的过程中,常常需要用到权限管理,其中权限分组就是其中比较重要的一个概念。通过了解AbpPermissionGroups表的结构和作用,可以更好地在应用程序中使用权限管理功能。
AbpPermissionGroups表与其他表的关系如下:
- AbpPermissions表:AbpPermissionGroups表和AbpPermissions表是多对多关系,通过AbpPermissionGroups表中的Id与AbpPermissions表中的PermissionGroupId进行关联。
- AbpRoles表:AbpPermissionGroups表和AbpRoles表之间没有直接关联。但是,在对角色进行授权的时候,可以选择对角色授权某些权限分组,从而达到对角色进行授权的目的。
数据表结构如下:
字段 | 类型 | 说明 |
Id | Guid | 权限分组ID |
TenantId | Guid | 租户ID |
Name | nvarchar(128) | 权限分组名称 |
DisplayName | nvarchar(128) | 权限分组显示名称 |
Description | nvarchar(512) | 权限分组描述 |
CreateTime | datetime | 创建时间 |
UpdateTime | datetime | 更新时间 |
16、权限信息表(AbpPermissions)
AbpPermissions数据表是ABP框架中用于存储权限信息的表,用于记录用户或角色所拥有的权限信息。
该表与其他表的关系和意义如下:
- AbpRolePermissions:记录角色与权限之间的关系
- AbpUserPermissions:记录用户与权限之间的关系
- AbpOrganizationUnitRoles:记录组织机构中角色的关系
通过AbpPermissions表,我们可以查询用户或角色所拥有的权限信息,这是权限系统实现的基础。同时,该表与其他表的关系可以帮助我们更好地理解ABP框架中的权限模块。
表结构如下:
字段 | 类型 | 说明 |
Id | bigint | 权限唯一标识 |
GroupName | nvarchar | 权限组名称,AbpPermissionGroups.Name |
Name | nvarchar | 权限名称 |
ParentName | nvarchar | 父级名称,NULL为顶级 |
DisplayName | nvarchar | 显示名称 |
IsEnabled | bigint | 是否启用 |
Providers | nvarchar | |
MultiTenancySide | int | 多租户访问方式(1=主机访问,2=租户访问) |
StateCheckers | nvarchar | |
17、角色声明信息表(AbpRoleClaims)
用于存储和管理角色的声明信息。使用场景主要是在权限管理、授权、资源访问控制等方面。通过在角色中添加声明,可以定义该角色对于特定资源的访问权限,从而实现对资源进行授权和访问控制。另外,该表还可以用于在业务逻辑中对角色授权进行操作。通过对AbpRoleClaims表的添加、删除、更新等操作,可以方便地管理和维护角色的声明信息,保证系统的安全性。
与其他数据表的关系如下:
- AbpRoleClaims表与AbpRoles表为一对多的关系,即一个角色可以拥有多个声明。
- AbpRoleClaims表与AbpTenants表为多对一的关系,即多个角色声明可以属于同一个租户。
表结构如下:
字段 | 类型 | 说明 |
Id | bigint | 主键ID,自增 |
TenantId | int | 租户ID |
RoleId | bigint | 角色ID,外键关联AbpRoles表的Id字段 |
ClaimType | nvarchar(450) | 声明类型 |
ClaimValue | nvarchar(max) | 声明值 |
18、角色表(AbpRoles)
用于存储角色(Role)相关的数据。具体作用和用途如下:
- 存储系统内所有角色的基本信息,包括角色ID、名称、租户ID、创建时间、最后修改时间等。这些信息对权限管理和角色授权都非常重要。
- 为系统内所有用户定义角色,分配角色权限和资源访问权限。通过与AbpUserRoles和AbpRoleClaims数据表的关联,可以快速找到拥有特定角色的用户以及该角色所包含的权限信息。
- 为角色提供一些基本操作方法,如创建、更新、删除角色等。
可以说,AbpRoles数据表是Abp vnext框架不可或缺的一部分,涵盖了系统内角色管理的核心内容。
记录各种角色信息,表字段结构如下图:
字段 | 类型 | 说明 |
Id | bigint | 主键ID |
ConcurrencyStamp | nvarchar(256) | 并发戳 |
CreationTime | datetime2(7) | 创建时间 |
CreatorId | bigint | 创建者ID |
DisplayName | nvarchar(64) | 显示名称 |
IsDeleted | bit | 是否已删除 |
DeleterId | bigint | 删除者ID |
DeletionTime | datetime2(7) | 删除时间 |
LastModificationTime | datetime2(7) | 最后修改时间 |
LastModifierId | bigint | 最后修改者ID |
Name | nvarchar(32) | 角色名称 |
NormalizedName | nvarchar(32) | 角色名称(大写) |
19、安全日志信息表(AbpSecurityLogs)
该表用于记录安全日志信息,包括应用程序名称、用户标识、操作、用户ID、租户ID、客户端IP地址、客户端名称、浏览器信息等内容。通过该表记录的安全日志信息,可以进行安全审计、监控用户行为等安全管理操作。
字段结构说明如下:
字段 | 类型 | 说明 |
Id | bigint | 主键ID |
ApplicationName | nvarchar(96) | 应用程序名称 |
Identity | nvarchar(96) | 用户标识 |
Action | nvarchar(96) | 安全日志处理的操作 |
UserId | bigint | 用户ID |
TenantId | int | 租户ID |
ClientIpAddress | nvarchar(64) | 客户端IP地址 |
ClientName | nvarchar(196) | 客户端名称 |
BrowserInfo | nvarchar(512) | 浏览器信息 |
CreationTime | datetime2(7) | 创建时间 |
20、应用程序定义设置表(AbpSettingDefinitions)
AbpSettingDefinitions表是ABP框架中的一个预定义表,用于存储应用程序定义的所有设置(设置名称、默认值、描述等),以及它们的类型信息(bool、string、int等)。它的作用是作为应用程序中所有设置的中央注册处,使得应用程序中的所有部分都能够轻松地获取应用程序定义的所有设置信息。
与AbpSettingDefinitions表相关的其他表包括:
- AbpSettings表:存储应用程序中所有设置的值。
- AbpTenants表:存储租户及其相关信息。
- AbpEntityChanges表:存储实体更改历史记录,其中可能包含ABP设置更改历史记录。
- AbpAuditLogs表:存储审核日志,其中可能包含ABP设置更改历史记录。
字段结构如下:
字段名 | 类型 | 描述 |
---|---|---|
Id | Guid | 主键 |
Name | String | 设置名称 |
Value | String | 默认值 |
Description | String | 描述 |
IsDeleted | bool | 是否删除 |
TenantId | Guid | 租户ID |
ProviderName | String | 提供程序名称 |
ProviderKey | String | 提供程序关键字 |
21、系统设置表(AbpSettings)
AbpSettings表的用途和作用是存储系统和应用程序的一些设置,例如,存储应用程序的URL地址、SMTP服务器设置、默认语言设置等。该表与其他表的关系是通过ProviderName和ProviderKey两个字段进行关联。如:TenantSpecificSetting和UserSetting表中的TenantId和UserId是通过ProviderName和ProviderKey与AbpSettings表关联的。
AbpSettings表的字段结构如下:
字段名 | 数据类型 | 说明 |
---|---|---|
Id | int | 唯一标识符 |
Name | nvarchar(256) | 设置项名称 |
Value | nvarchar(max) | 设置项的值 |
ProviderName | nvarchar(64) | 提供程序名称 |
ProviderKey | nvarchar(64) | 提供程序键 |
22、租户连接字符串信息表(AbpTenantConnectionStrings)
该表的用途和作用是存储每个租户的连接字符串信息。在多租户应用程序中,每个租户通常需要连接到不同的数据库,因此需要为每个租户存储一个连接字符串。该表允许应用程序动态管理多个租户的数据库连接。
该表与其他表的关系:
- AbpTenants表:使用TenantId字段连接到AbpTenants表,表示该连接字符串属于哪个租户。
- AbpUsers表:使用CreatorId和LastModifierId字段连接到AbpUsers表,表示创建和修改该连接字符串的用户。
字段结构如下:
字段名 | 数据类型 | 描述 |
---|---|---|
Id | bigint | 记录的唯一标识符 |
TenantId | int | 租户的唯一标识符 |
Name | nvarchar(256) | 连接字符串的名称 |
Value | nvarchar(MAX) | 连接字符串的值 |
CreationTime | datetime | 记录的创建时间 |
CreatorId | bigint | 创建记录的用户的唯一标识符 |
LastModificationTime | datetime | 记录的最后修改时间 |
LastModifierId | bigint | 最后修改记录的用户的唯一标识符 |
23、租户信息表(AbpTenants)
AbpTenants表的用途是存储系统中多租户相关信息,包括租户名称、是否激活、版本信息、连接字符串等。该表的作用是支持系统中的多租户功能,使得系统可以为不同的租户提供不同的服务和数据存储。同时,该表还记录了每个租户的创建和修改信息,方便系统管理员管理和维护系统。
AbpTenants表与其他表的关系:
- AbpEditions表:AbpTenants表中的EditionId字段与AbpEditions表中的Id字段关联,表示租户所使用的版本信息。
- AbpTenantFeatures表:AbpTenants表与AbpTenantFeatures表通过租户ID关联,用于记录租户的功能开关信息。
- AbpTenantConnectionStrings表:AbpTenants表与AbpTenantConnectionStrings表通过租户ID关联,用于记录租户的数据库连接字符串信息。
字段结构说明:
字段 | 类型 | 描述 |
---|---|---|
Id | int | 主键ID |
Name | varchar | 租户名称 |
IsActive | bit | 是否激活 |
EditionId | int | 版本ID |
ConnectionString | nvarchar | 连接字符串 |
IsDeleted | bit | 是否删除 |
DeletionTime | datetime? | 删除时间 |
DeleterUserId | long? | 删除者ID |
LastModificationTime | datetime? | 最后修改时间 |
LastModifierUserId | long? | 最后修改者ID |
CreationTime | datetime | 创建时间 |
CreatorUserId | long? | 创建者ID |
24、用户声明信息表(AbpUserClaims)
AbpUserClaims表是AspNetCore.Identity框架中的一个表,用于存储用户相关的声明(Claim)信息。在ABP框架中,它被用于存储用户额外的声明信息,例如用户的角色、权限等。该表的结构如下:
列名 | 数据类型 | 描述 |
---|---|---|
Id | int | 用户声明ID |
TenantId | int? | 租户ID |
UserId | int | 用户ID |
ClaimType | nvarchar | 用户声明类型 |
ClaimValue | nvarchar | 用户声明值 |
CreationTime | datetime | 声明创建时间 |
CreatorId | int? | 创建者ID |
ModifierId | int? | 最后修改者ID |
ModificationTime | datetime | 最后修改时间 |
AbpUserClaims表与AbpUsers表是一对多关系,一个用户可以拥有多个声明信息,而AbpUserClaims表与AbpTenants表也是一对多关系,在多租户的情况下,在同一个用户下可以拥有不同租户之间的声明信息。同时,AbpUserClaims表与其他表也有关联,例如AbpRoles表、AbpPermissions表等。
25、用户委派操作表(AbpUserDelegations)
AbpUserDelegations表是Abp框架中用于委派(Delegate)操作的表格,其字段结构如下:
字段名称 | 数据类型 | 描述 |
---|---|---|
Id | bigint | 委派操作的唯一编号 |
SourceUserId | bigint | 委派操作发起人的用户编号 |
TargetUserId | bigint | 委派操作目标用户的用户编号 |
StartTime | datetime | 委派操作的开始时间 |
EndTime | datetime | 委派操作的结束时间 |
该表的用途和作用是允许一个用户将自己在系统中的某些权限或角色委派给另一个用户,在指定的时间内另一个用户可以代替自己执行相关操作。这种委派机制可以提高系统的灵活性和安全性。
该表与其他表的关系如下:
- AbpUsers表:AbpUserDelegations表中的SourceUserId和TargetUserId字段分别对应AbpUsers表中的Id字段,表示委派操作的发起人和目标用户。
- AbpRoles表和AbpPermissions表:AbpUserDelegations表并不直接关联这两个表格,但是委派操作涉及到的权限和角色都在这两个表格中定义,所以委派操作的实际影响和限制是由这些表格定义的。
26、第三方登录的用户关联信息表(AbpUserLogins)
表格展示AbpUserLogins表的字段结构如下:
列名 | 数据类型 | 描述 |
---|---|---|
LoginProvider | nvarchar(128) | 提供者名称(如“微信”,“QQ”等) |
ProviderKey | nvarchar(256) | 提供者标识(如用户在微信公众号中的OpenId) |
ProviderDisplayName | nvarchar(128) | 提供者显示名称 |
TenantId | int | 租户Id |
UserId | bigint | 用户Id |
AbpUserLogins表的用途和作用:该表存储了登录提供者(如微信、QQ等)和用户的关联信息。当用户使用第三方登录时,系统会在该表中记录用户和提供者的关联信息,便于后续用户使用第三方账号进行登录时,系统可以通过该表快速查找用户信息。
该表与其他表的关系: AbpUserLogins表与AbpUsers表通过UserId列建立了外键关系,表示一个用户可以有多个登录提供者与之关联。同时,如果系统是多租户模式,则该表中的TenantId列也与AbpTenants表建立了外键关系,表示一个租户可以有多个用户使用第三方账号进行登录。
可以使用以下步骤存储第三方用户信息及系统用户关系和授权:
-
创建一个自定义的身份验证提供程序来实现第三方用户登录。例如,可以创建一个名为MyAuth的类,实现IExternalAuthManager接口。
-
在MyAuth类中,重写AuthenticateAsync方法,以实现自定义身份验证逻辑。在此方法中,可以使用第三方身份验证提供程序(例如Microsoft、Facebook、Google等)提供的API验证用户信息,并创建一个新的系统用户(如果用户尚未在系统中注册。存储在AbpUsers表)。
-
在MyAuth类中,重写CreateOrUpdateExternalUserAsync方法,以创建或更新系统用户和第三方用户之间的关系。
-
创建一个新的数据表来存储第三方用户信息。例如,可以创建一个名为MyExternalUsers的表格,其字段结构包含第三方用户信息和系统用户ID(外键)。
-
在CreateOrUpdateExternalUserAsync方法中,将第三方用户信息存储在MyExternalUsers表格中,并创建一个系统用户和第三方用户之间的关系。
-
如果需要实现第三方用户授权,可以创建一个新的数据表来存储系统用户和第三方用户之间的授权关系。例如,可以创建一个名为MyExternalUserPermissions的表格,其字段结构包括系统用户ID和第三方用户ID。
-
在MyAuth类中,重写CheckPermissionsAsync方法,以实现自定义用户权限逻辑。在此方法中,可以查询系统用户和第三方用户之间的授权关系,并检查用户是否具有所需权限。
通过这些步骤,可以实现第三方用户登录、存储第三方用户信息和系统用户关系、以及实现第三方用户授权。
27、用户组织机构关联表(AbpUserOrganizationUnits)
AbpUserOrganizationUnits表是ABP框架中的一个核心表,用于存储用户和组织单位之间的关联关系。它的作用是将ABP中的用户与组织单位进行关联,方便对用户进行权限管理和组织架构管理。
表格展示AbpUserOrganizationUnits表的字段结构如下:
字段名 | 数据类型 | 描述 |
---|---|---|
Id | int | 编号 |
TenantId | int | 租户Id |
UserId | long | 用户Id |
OrganizationUnitId | long | 组织单位Id |
该表与其他表的关系如下:
- AbpUsers表:AbpUserOrganizationUnits表通过UserId字段与AbpUsers表进行关联,实现用户与组织单位之间的关联。
- AbpOrganizationUnits表:AbpUserOrganizationUnits表通过OrganizationUnitId字段与AbpOrganizationUnits表进行关联,实现组织单位与用户之间的关联。
28、用户角色表(AbpUserRoles)
AbpUserRoles表是ABP框架中用来存储用户角色关联关系的表格,其字段结构如下:
Column Name | Data Type | Description |
---|---|---|
Id | bigint | 主键ID |
TenantId | int(Nullable) | 租户ID |
UserId | bigint | 用户ID |
RoleId | int | 角色ID |
CreationTime | datetime2(7) | 创建时间 |
CreatorId | bigint(Nullable) | 创建者用户ID |
该表的作用是存储用户和角色之间的关联关系。当需要确定用户是否具有特定角色的权限时,AbpUserRoles表是重要的数据源。例如,在用户登录系统后,需要检查他们的角色以确定他们是否可以执行特定的操作。
AbpUserRoles表与其他表的关系如下:
- AbpUsers表:与AbpUsers表通过UserId外键关联
- AbpRoles表:与AbpRoles表通过RoleId外键关联
通过这些连接,ABP框架能够准确地跟踪用户与角色之间的关系,从而帮助开发人员设计和实现权限管理系统。
29、用户表(AbpUsers)
AbpUsers表是ABP框架中用来存储用户信息的表格,其字段结构如下:
Column Name | Data Type | Description |
---|---|---|
Id | bigint | 主键ID |
TenantId | int(Nullable) | 租户ID |
UserName | nvarchar(256) | 用户名 |
nvarchar(256) | 电子邮箱 | |
EmailConfirmed | bit | 电子邮箱是否已经确认 |
PhoneNumber | nvarchar(16) | 电话号码 |
PhoneNumberConfirmed | bit | 电话号码是否已经确认 |
Password | nvarchar(max) | 密码 |
Name | nvarchar(64) | 姓名 |
Surname | nvarchar(64) | 姓氏 |
LastLoginTime | datetime2(7) | 最后登录时间 |
IsActive | bit | 是否启用 |
NormalizedUserName | nvarchar(256) | 用户名大写 |
NormalizedEmailAddress | nvarchar(256) | 邮箱大写 |
ConcurrencyStamp | nvarchar(256) | 并发戳 |
SecurityStamp | nvarchar(max) | 安全戳 |
DeleterId | bigint(Nullable) | 删除者用户ID |
DeletionTime | datetime2(7)(Nullable) | 删除时间 |
LastModificationTime | datetime2(7) | 最后修改时间 |
LastModifierUserId | bigint(Nullable) | 最后修改者用户ID |
CreationTime | datetime2(7) | 创建时间 |
CreatorId | bigint(Nullable) | 创建者用户ID |
该表的作用是存储系统中的用户信息,包括用户名、电子邮箱、电话号码、密码等。AbpUsers表是ABP框架中最为核心的数据表之一,它在整个系统中扮演着至关重要的角色,是其他表格的外键(如AbpUserRoles表、AbpUserClaims表等)。
如果要实现第三方用户登录,用户信息可能存储在不同的数据表中。在ASP.NET Core中,可以通过Identity框架和第三方身份验证提供程序(例如Microsoft、Facebook、Google等)来实现第三方用户登录,而第三方用户信息可以存储在外部身份验证提供程序中。在ABP框架中,可以通过开发自定义的身份验证提供程序来实现第三方用户登录,并根据需要将用户信息存储在自定义数据表中。
30、用户token信息表(AbpUserTokens)
AbpUserTokens表的字段结构如下:
字段名 | 数据类型 | 描述 |
---|---|---|
Id | long | 主键 |
TenantId | int? | 租户Id |
UserId | long | 用户Id |
LoginProvider | nvarchar | 用户的登录提供方 |
Name | nvarchar | 用户的token名称 |
Value | nvarchar | 用户的token值 |
CreationTime | datetime | 创建时间 |
ExpiresAt | datetime? | token过期时间,如果是null,表示token永不过期 |
该表的用途和作用是存储用户的token信息。当用户使用第三方登录(如微信、QQ)时,Abp会将第三方授权登录的token信息存储在该表中。当用户进行需要鉴权的操作时,Abp会从该表中取出相应的token信息进行验证。
该表与其他表的关系如下:
- AbpUsers表:AbpUserTokens表中的UserId字段与AbpUsers表中的Id字段关联,表示该token信息对应于哪个用户。
- AbpTenants表:AbpUserTokens表中的TenantId字段与AbpTenants表中的Id字段关联,表示该token信息所属的租户。如果该字段为null,表示该token信息属于全局租户。
- AbpUserLogins表:AbpUserTokens表中的LoginProvider字段与AbpUserLogins表中的LoginProvider字段关联,表示该token信息是由哪个第三方平台提供的授权登录信息。AbpUserTokens表中的Name字段与AbpUserLogins表中的ProviderKey字段关联,表示该token信息对应于哪个授权登录信息。
31、OpenIddict应用信息表(OpenIddictApplications)
OpenIddictApplications表的字段结构如下:
字段名 | 数据类型 | 描述 |
---|---|---|
Id | nvarchar | 主键,一般是应用的ClientId |
ClientId | nvarchar | 应用标识 |
ClientSecretHash | nvarchar | 应用密码的哈希值 |
ConsentType | nvarchar | 同意授权类型。默认值是“explicit” |
DisplayName | nvarchar | 应用名称 |
DisplayNames | ntext | 应用名称,支持多语言,以JSON格式字符串存储。 |
Permissions | ntext | 应用授权所需的权限,以JSON格式字符串存储。 |
PostLogoutRedirectUris | ntext | 登出后跳转的URL |
RedirectUris | ntext | 应用跳转URL列表。 |
Requirements | ntext | 其他应用要求,以JSON格式字符串存储。 |
Type | nvarchar | 应用类型。默认值是“confidential” |
UserType | nvarchar | 应用用户类型,默认为null |
CreatedAt | datetime | 应用创建时间 |
ClientType | nvarchar | 应用客户类型。默认值是“Confidential” |
ConcurrencyToken | varchar | 用于并发控制的token |
该表的用途和作用是存储OpenIddict应用的信息,包括应用程序的标识、密码哈希值、名称、授权类型、跳转URL等等。
该表与其他表的关系如下:
- AbpTenant表:OpenIddictApplications表中的TenantId字段与AbpTenants表中的Id字段关联,表示该应用所属的租户。如果该字段为null,表示该应用属于全局租户。
- AbpUser表:OpenIddictApplications表中的UserId字段与AbpUsers表中的Id字段关联,表示该应用所属的用户。
- OpenIddictAuthorization表:OpenIddictApplications表和OpenIddictAuthorization表之间是一对多关系。表示该应用下的授权信息。
- OpenIddictTokens表:OpenIddictApplications表和OpenIddictTokens表之间是一对多关系。表示该应用下的token信息。
该表对应到IdentityServer机制中的Client表。
32、OpenIddict授权信息表(OpenIddictAuthorizations)
OpenIddictAuthorizations表的字段结构如下:
字段名 | 数据类型 | 描述 |
---|---|---|
Id | int | 主键 |
ApplicationId | nvarchar | 外键,关联OpenIddictApplications表的Id字段,表示该授权信息所属的应用程序ID |
Scope | nvarchar | 授权范围 |
Status | nvarchar | 授权状态 |
Subject | nvarchar | 授权主题 |
Type | nvarchar | 授权类型 |
ConcurrencyToken | varchar | 用于并发控制的token |
CreationDate | datetime | 授权创建时间 |
ExpirationDate | datetime | 授权过期时间 |
Payload | ntext | 授权的其他信息,以JSON格式字符串存储 |
该表的用途和作用是存储OpenIddict授权的信息,包括所属的应用程序ID、授权范围、授权状态、授权主题、授权类型等等。
该表与其他表的关系如下:
- OpenIddictApplications表:OpenIddictAuthorizations表中的ApplicationId字段与OpenIddictApplications表中的Id字段关联,表示该授权信息所属的应用程序ID。
- AbpUser表:OpenIddictAuthorizations表中的Subject字段与AbpUsers表中的Id字段关联,表示该授权信息所属的用户。
- OpenIddictTokens表:OpenIddictAuthorizations表和OpenIddictTokens表之间是一对多关系。表示该授权信息下的token信息。
该表与IdentityServer机制中的表没有直接对应关系。但是,OpenIddict是IdentityServer的扩展组件,并且OpenIddictAuthorizations表可以存储与IdentityServer中AuthorizationCode和DeviceCode概念相对应的数据。
33、OpenIddict的Scope信息表(OpenIddictScopes)
OpenIddictScopes表的字段结构如下:
字段名称 | 类型 | 描述 |
---|---|---|
Id | string | Scope的唯一标识 |
Name | string | Scope的名称 |
DisplayName | string | Scope的显示名称 |
Description | string | Scope的描述 |
Resources | string | Scope所涉及的资源 |
ConsumedResources | string | Scope消耗的资源 |
Properties | string | Scope的属性 |
OpenIddictScopes表的用途和作用是存储OpenIddict中的Scope信息,Scope是OAuth 2.0和OpenID Connect的一个重要概念,用于定义客户端可以请求的权限范围。在OpenIddict中,Scope是可选的,可以让开发者根据自己的需要自定义Scope。Scope可以关联到客户端和用户授权请求中,以控制对资源的访问权限。
OpenIddictScopes表与其他表的关系如下:
- OpenIddictApplications表:一对多关系,一个Scope可以关联到多个应用程序,一个应用程序可以拥有多个Scope。
- OpenIddictAuthorizations表:多对多关系,一个Authorization请求可以包含多个Scope,一个Scope也可以关联到多个Authorization请求。
在IdentityServer机制中,OpenIddictScopes表与IdentityServer的Scope有对应的概念。但是,OpenIddict是一个独立的授权服务器,与IdentityServer并不直接相关。如果需要在Abp vnext中使用IdentityServer,需要使用IdentityServer4模块。在IdentityServer4中,Scope的相关信息是存储在ApiResources表和IdentityResources表中。
34、OpenIddict内部使用令牌(OpenIddictTokens)
OpenIddictTokens表的字段结构如下:
列名 | 类型 | 描述 |
---|---|---|
Id | nvarchar(450) | Token的唯一标识 |
ApplicationId | nvarchar(450) | 发放Token的客户端应用程序的标识符 |
CreationDate | datetimeoffset(7) | Token创建的时间 |
ExpirationDate | datetimeoffset(7) | Token的过期时间 |
Payload | ntext | Token的负载,它可以是任何序列化对象 |
Properties | ntext | Token的属性,可以是任何序列化对象 |
ReferenceId | nvarchar(450) | 引用令牌的唯一标识 |
Status | nvarchar(50) | Token状态:'valid','expired', 'revoked', 或者 'invalidated' |
Subject | nvarchar(450) | 与Token相关的主题,可以是用户或者客户端 |
Type | nvarchar(450) | Token的类型 |
OpenIddictTokens表用于存储OpenIddict内部使用的令牌,在OAuth 2.0和OpenID Connect中起到了重要的作用。OpenIddict是一个轻量级的OpenID Connect提供程序和OAuth 2.0服务器框架,用于ASP.NET Core应用程序,并提供与IdentityServer4相似的功能。
OpenIddictTokens表与其他表的关系如下:
- OpenIddictApplications表:每个Token都必须与一个应用程序相关联,该表定义了可用于创建Token的应用程序,OpenIddictApplications表中的ApplicationId列与OpenIddictTokens表中的ApplicationId列是外键关系。
- OpenIddictAuthorizations表:每个Token都可以与一个授权相关联,该表定义了授权过程中使用的授权,OpenIddictAuthorizations表中的Id列与OpenIddictTokens表中的AuthorizationId列是外键关系。
- OpenIddictScopes表:每个Token都可以与一组范围相关联,该表定义了用于限制访问Token的范围,OpenIddictScopes表中的Id列与OpenIddictTokenScopes表中的ScopeId列是外键关系。
在Identity Server机制中,OpenIddictTokens表与默认的IdentityServer4令牌存储机制中的PersistedGrants表相对应。但两者的结构略有不同。OpenIddictTokens表存储OpenIddict框架中的令牌信息,而PersistedGrants表存储IdentityServer4框架中的授权数据和令牌信息。