diff --git a/zh-cn/application-dev/security/accesstoken-overview.md b/zh-cn/application-dev/security/accesstoken-overview.md index f2e661d3c72267bc7b56e9199a89a9a3d6ef8c38..94feaa30c186d4ea8a17d3ba323fef0f25e11603 100644 --- a/zh-cn/application-dev/security/accesstoken-overview.md +++ b/zh-cn/application-dev/security/accesstoken-overview.md @@ -74,8 +74,9 @@ ATM(AccessTokenManager)是OpenHarmony上基于AccessToken构建的统一的应 | system_basic等级 | 该等级的应用服务提供系统基础服务。 | | normal等级 | 普通应用。 | -默认情况下，应用的APL等级都为normal等级，如果应用需要将自身的APL等级声明为system_basic及以上的APL等级，需要进行以下步骤： -- 开发应用安装包时，需要修改应用的[profile文件](../quick-start/app-provision-structure.md)，在文件的"apl"字段声明应用的APL等级，并使用profile签名工具生成证书。具体签名流程可以查看页面[Hap包签名工具指导](hapsigntool-guidelines.md)。 +默认情况下，应用的APL等级都为normal等级。 + +如果应用需要将自身的APL等级声明为system_basic及以上的APL等级，在开发应用安装包时，要修改应用的profile文件。在文件的"apl"字段声明应用的APL等级，并使用profile签名工具生成证书。具体签名流程可以查看页面[Hap包签名工具指导](hapsigntool-guidelines.md)。 ### 权限等级说明 @@ -107,9 +108,24 @@ ATM(AccessTokenManager)是OpenHarmony上基于AccessToken构建的统一的应 **场景举例：** -开发者正在开发应用A，该应用的APL等级为normal级别。由于功能场景需要，应用A必须申请到权限B和权限C，其中，权限B的权限等级为system_basic，权限C的权限等级为normal级别。此时，推荐开发者使用ACL方式来申请权限B。 +开发者正在开发应用A，该应用的APL等级为normal级别。由于功能场景需要，应用A必须申请到权限B和权限C，其中，权限B的权限等级为system_basic，权限C的权限等级为normal级别。 + +在权限B的ACL使能为TRUE的情况下，此时，开发者可以使用ACL方式来申请权限B。 ACL方式的工作流程可以参考[ACL方式使用说明](#ACL方式使用说明)。 +权限的ACL使能情况可查阅[权限定义列表](permission-list.md)。 + +### ACL方式使用说明 + +如果应用申请的权限中，存在部分权限的权限等级比应用APL等级高，开发者可以选择通过ACL方式来解决这个等级不匹配的问题。 + +在上述的[授权流程](#不同权限类型的授权流程)的基础上，应用需要进行额外的ACL声明步骤。 + +应用除了需要在config.json文件声明所需申请的权限，还需要在应用的[profile文件中声明](accesstoken-guidelines.md#acl方式声明)不满足申请条件的高等级权限，接下来的授权流程不变。 + +**ACL申请方式须知** + +开发应用安装包时，需要修改应用的profile文件，在文件的"acl"字段声明目标的访问控制列表，并使用profile签名工具生成证书。具体签名流程可以查看页面[Hap包签名工具指导](hapsigntool-guidelines.md)。 ## 权限类型说明 @@ -131,7 +147,7 @@ ACL方式的工作流程可以参考[ACL方式使用说明](#ACL方式使用说 应用需要在应用商店的详情页面，向用户展示所申请的user_grant权限列表。 -## 不同权限类型的授权流程 +### 不同权限类型的授权流程 如[权限的工作流程](#权限的工作流程)所示，如果应用需要获取目标权限，那么需要先进行权限申请。 @@ -160,16 +176,3 @@ ACL方式的工作流程可以参考[ACL方式使用说明](#ACL方式使用说 - 如需检查用户是否已向您的应用授予特定权限，可以使用[verifyAccessToken](../reference/apis/js-apis-abilityAccessCtrl.md)函数，此方法会返回 [PERMISSION_GRANTED](../reference/apis/js-apis-abilityAccessCtrl.md)或[PERMISSION_DENIED](../reference/apis/js-apis-abilityAccessCtrl.md)。具体的示例代码可以查看[访问控制开发指导](accesstoken-guidelines.md)。 - user_grant权限授权要基于用户可知可控的原则，需要应用在运行时主动调用系统动态申请权限的接口，系统弹框由用户授权，用户结合应用运行场景的上下文，识别出应用申请相应敏感权限的合理性，从而做出正确的选择。 - 即使用户向应用授予过请求的权限，应用在调用受此权限管控的接口前，也应该先检查自己有无此权限，而不能把之前授予的状态持久化，因为用户在动态授予后还可以通过设置取消应用的权限。 - -### ACL方式使用说明 - -如果应用申请的权限中，存在部分权限的权限等级比应用APL等级高，开发者可以选择通过ACL方式来解决这个等级不匹配的问题。 - -在上述的[授权流程](#不同权限类型的授权流程)的基础上，应用需要进行额外的ACL声明步骤。 - -应用除了需要在config.json文件声明所需申请的权限，还需要在应用的[profile文件中声明](accesstoken-guidelines.md)不满足申请条件的高等级权限，接下来的授权流程不变。 - -**ACL申请方式须知** - -* 开发应用安装包时，需要修改应用的profile文件，在文件的"acl"字段声明目标的访问控制列表，并使用profile签名工具生成证书。具体签名流程可以查看页面[Hap包签名工具指导](hapsigntool-guidelines.md)。 - diff --git a/zh-cn/application-dev/security/figures/permission-application-process.png b/zh-cn/application-dev/security/figures/permission-application-process.png new file mode 100644 index 0000000000000000000000000000000000000000..85246f199f01c29f13018bc1841470dc20a54f61 Binary files /dev/null and b/zh-cn/application-dev/security/figures/permission-application-process.png differ diff --git a/zh-cn/application-dev/security/permission-list.md b/zh-cn/application-dev/security/permission-list.md index d9b781f95426a83b20d347e69e5f44921a498da7..1ed3deaf2708e590a3c993dc3555ba03c5fc8f2b 100644 --- a/zh-cn/application-dev/security/permission-list.md +++ b/zh-cn/application-dev/security/permission-list.md @@ -1,8 +1,14 @@ # 权限定义列表 -以下给出当前系统定义的权限信息列表。 +在符合[应用申请和使用权限的基本原则](accesstoken-overview.md#基本原则)的基础上，可以根据下图判断应用是否可以申请某权限。 -权限级别、授权方式、ACL使能的说明，请参考[访问控制开发概述](accesstoken-overview.md)。权限的使用示例请参考[访问控制开发指导](accesstoken-guidelines.md)。 +![](D:\doc-gitee\docs\zh-cn\application-dev\security\figures\permission-application-process.png) + +1. 应用APL等级与权限等级的匹配关系请参考[访问控制开发概述-权限等级说明](accesstoken-overview.md#权限等级说明)。 +2. 权限的授权方式分为user_grant（用户授权）和system_grant（系统授权），具体请参考[访问控制开发概述-权限类型说明](accesstoken-overview.md#权限类型说明)。 +3. 应用可以通过ACL（访问控制列表）方式申请高级别的权限，具体请参考[访问控制开发概述-访问控制列表说明](accesstoken-overview.md#访问控制列表acl说明)。 + +以下给出当前系统定义的权限信息列表。权限的使用示例请参考[访问控制开发指导](accesstoken-guidelines.md)。 | 权限名 | 权限级别 | 授权方式 | ACL使能 | 权限说明 | | -------------------------------------------------------- | ------------ | ------------ | ------- | ------------------------------------------------------------ | @@ -128,4 +134,5 @@ | ohos.permission.READ_HEALTH_DATA | normal | user_grant | TRUE | 允许应用读取用户的健康数据。 | | ohos.permission.GET_DEFAULT_APPLICATION | system_core | system_grant | TRUE | 允许应用查询默认应用。 | | ohos.permission.SET_DEFAULT_APPLICATION | system_core | system_grant | TRUE | 允许应用设置、重置默认应用。 | -| ohos.permission.MANAGE_DISPOSED_APP_STATUS | system_core | system_grant | TRUE | 允许设置和查询应用的处置状态。 | \ No newline at end of file +| ohos.permission.MANAGE_DISPOSED_APP_STATUS | system_core | system_grant | TRUE | 允许设置和查询应用的处置状态。 | +| ohos.permission.ACCESS_IDS | system_core | system_grant | TRUE | 允许应用查询设备的唯一标识符信息。 | \ No newline at end of file