accesstoken-guidelines.md 7.0 KB
Newer Older
1
# 访问控制(权限)开发指导
L
l00520400 已提交
2 3 4

## 场景介绍

5
以下示例代码基于此场景假设:应用因为应用核心功能诉求,需要申请权限"ohos.permission.PERMISSION1"和权限"ohos.permission.PERMISSION2"。
L
l00520400 已提交
6

7 8 9 10
- 应用的APL等级为normal。
- 权限"ohos.permission.PERMISSION1"的权限等级为normal,权限类型为system_grant。
- 权限"ohos.permission.PERMISSION2"的权限等级为system_basic, 权限类型为user_grant。

11
> **注意:** 
12 13 14 15 16
>
> 当前场景下,应用申请的权限包括了user_grant权限,对这部分user_grant权限,可以先通过权限校验,判断当前调用者是否具备相应权限。
>
> 当权限校验结果显示当前应用尚未被授权该权限时,再通过动态弹框授权方式给用户提供手动授权入口。
>
L
l00520400 已提交
17
## 接口说明
18 19 20 21 22

以下仅列举本指导使用的接口,更多说明可以查阅[API参考](../reference/apis/js-apis-abilityAccessCtrl.md)

| 接口名                                                       | 描述                                             |
| ------------------------------------------------------------ | --------------------------------------------------- |
L
l00520400 已提交
23 24
| verifyAccessToken(tokenID: number, permissionName: string): Promise<GrantStatus> | 校验应用是否授予权限,使用Promise方式异步返回结果。 |

25 26
## 权限申请声明

27
应用需要在工程配置文件中,对需要的权限逐个声明,没有在配置文件中声明的权限,应用将无法获得授权。Ability框架提供了两种模型,分别为FA模型和Stage模型,更多信息可以参考[Ability框架概述](../ability/ability-brief.md)
28

29 30
不同的Ability框架模型的应用包结构不同,所使用的配置文件不同,请开发者在申请权限时注意区分。

31
配置文件标签说明如下表。
32 33 34 35 36 37

| 标签      | 说明                                                         |
| --------- | ------------------------------------------------------------ |
| name      | 权限名称。                                                   |
| reason    | 当申请的权限为user_grant权限时,此字段必填,描述申请权限的原因。 |
| usedScene | 当申请的权限为user_grant权限时,此字段必填,描述权限使用的场景和时机。 |
38 39
| ability   | 标识需要使用到该权限的元能力,标签为数组形式。   <br/>**适用模型:** FA模型            |
| abilities | 标识需要使用到该权限的元能力,标签为数组形式。   <br/>**适用模型:** Stage模型            |
40 41
| when      | 标识权限使用的时机,值为"inuse/always",表示为仅允许前台使用和前后台都可使用。 |

42 43 44 45
### FA模型

使用FA模型的应用,需要在config.json文件中声明权限。

46 47
**示例:**

F
update  
fanchenxuan 已提交
48 49 50 51 52 53 54 55
```json
{
    "module" : {
        "reqPermissions":[
           {
                "name" : "ohos.permission.PERMISSION1",
                "reason": "$string:reason",
                "usedScene": {
56
                     "ability": [
F
update  
fanchenxuan 已提交
57 58 59 60 61 62 63 64 65
                         "FormAbility"
                     ],
                     "when":"inuse"
                }
            },
           {
                "name" : "ohos.permission.PERMISSION2",
                "reason": "$string:reason",
                "usedScene": {
66
                     "ability": [
F
update  
fanchenxuan 已提交
67 68 69 70 71
                         "FormAbility"
                     ],
                     "when":"always"
                }
            }
72
        ]
F
update  
fanchenxuan 已提交
73 74 75 76
    }
}
```

77
### Stage模型
F
update  
fanchenxuan 已提交
78

79
使用Stage模型的应用,需要在module.json5文件中声明权限。
F
update  
fanchenxuan 已提交
80 81 82

**示例:**

83 84 85
```json
{
    "module" : {
86
        "requestPermissions":[
87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110
           {
                "name" : "ohos.permission.PERMISSION1",
                "reason": "$string:reason",
                "usedScene": {
                     "abilities": [
                         "FormAbility"
                     ],
                     "when":"inuse"
                }
            },
           {
                "name" : "ohos.permission.PERMISSION2",
                "reason": "$string:reason",
                "usedScene": {
                     "abilities": [
                         "FormAbility"
                     ],
                     "when":"always"
                }
            }
        ],
    }
}
```
F
update  
fanchenxuan 已提交
111

112 113 114 115
## ACL方式声明

如上述示例所示,权限"ohos.permission.PERMISSION2"的权限等级为system_basic,高于应用此时应用的APL等级,用户的最佳做法是使用ACL方式。

116 117 118 119
在配置文件声明的基础上,应用还需要在Profile文件中声明不满足申请条件部分的权限。Profile文件的字段说明可参考[HarmonyAppProvision配置文件的说明](../quick-start/app-provision-structure.md)

该场景中,用户应该在字段"acls"中做声明如下:

120 121 122 123 124 125 126 127 128 129 130 131 132
```json
{
    "acls": {
        "allowed-acls": [
            "ohos.permission.PERMISSION2"
        ]
    },
}
```

## 申请授权user_grant权限

在前期的权限声明步骤后,在安装过程中系统会对system_grant类型的权限进行权限预授权,而user_grant类型权限则需要用户进行手动授权。
L
l00520400 已提交
133

134 135 136 137
所以,应用在调用受"ohos.permission.PERMISSION2"权限保护的接口前,需要先校验应用是否已经获取该权限。

如果校验结果显示,应用已经获取了该权限,那么应用可以直接访问该目标接口,否则,应用需要通过动态弹框先申请用户授权,并根据授权结果进行相应处理,处理方式可参考[访问控制开发概述](accesstoken-overview.md)

138
> **注意:**
139 140 141 142 143 144
>
> 不能把之前授予的状态持久化,每次访问受目标权限保护的接口前,都应该检查权限授权状态,因为用户在动态授予后可能通过设置取消应用的权限。

## 完整示例

对访问者进行权限校验的开发步骤为:
L
l00520400 已提交
145

F
fanchenxuan 已提交
146 147 148
1. 获取ability的上下文context。
2. 调用requestPermissionsFromUser接口进行权限校验。
3. 根据权限校验结果采取对应的措施。
L
l00520400 已提交
149 150

```js
F
fanchenxuan 已提交
151 152 153 154 155 156 157 158 159 160 161 162 163
  //ability的onWindowStageCreate生命周期
  onWindowStageCreate() {
    var context = this.context
    let array:Array<string> = ["ohos.permission.PERMISSION2"];
    //requestPermissionsFromUser会判断权限的授权状态来决定是否唤起弹窗
    context.requestPermissionsFromUser(array).then(function(data) {
        console.log("data type:" + typeof(data));
        console.log("data:" + data);
        console.log("data permissions:" + data.permissions);
        console.log("data result:" + data.authResults);
    }, (err) => {
        console.error('Failed to start ability', err.code);
    });
L
l00520400 已提交
164 165 166 167
  }

```
> **说明:**
168
> 动态授权申请接口的使用详见[API参考](../reference/apis/js-apis-ability-context.md)。
169 170 171 172 173 174

## 相关实例

针对访问控制,有以下相关实例可供参考:

- [`AbilityAccessCtrl`:访问权限控制(eTS)(API8)](https://gitee.com/openharmony/app_samples/tree/master/Safety/AbilityAccessCtrl)
175
- [为应用添加运行时权限(eTS)(API 9)](https://gitee.com/openharmony/codelabs/tree/master/Ability/AccessPermission)