请求权限

社区组报告草案,

此版本:
https://jyasskin.github.io/permissions-request
问题跟踪:
GitHub
规范中的内联问题
编辑:
(Google Inc.)
前编辑:
(Google Inc.)
测试:
web-platform-tests permissions-request/ (进行中的工作)
Polyfill:
chromium/permissions.request

摘要

本规范扩展了 Permissions API,以提供一个统一的函数来请求使用 强大特性的权限。

本文档状态

本规范由 Web Platform Incubator Community Group 发布。 它不是 W3C 标准,也不在 W3C 标准轨道上。 请注意,根据 W3C Community Contributor License Agreement (CLA),存在有限的选择退出,并适用其他条件。 了解有关 W3C Community and Business Groups 的更多信息。

1. 介绍

本文档规定了一个用于请求在 Web 平台上使用强大 特性的权限的函数。

不同的 Web API 有不同的方式来表示开发者使用它们的意图:

如果开发者对所有强大特性都有 单一模式可循,那么他们就更容易设计与权限相关的代码。

2. 请求 API

partial interface Permissions {
  Promise<PermissionStatus> request(object permissionDesc);
};

当调用 request(permissionDesc) 方法时, 用户代理必须运行以下算法,并传入参数 permissionDesc

  1. rootDescpermissionDesc 所指的对象,并将其转换为 IDL 值,其类型为 PermissionDescriptor。 如果这抛出异常, 则返回以该异常拒绝的 promise,并中止这些 步骤。

  2. typedDescriptorpermissionDesc 所指的对象,并将其转换 为 IDL 值,其类型为 rootDesc.name权限描述符类型。如果这抛出 异常,则返回以该 异常拒绝的 promise,并中止这些步骤。

  3. promise 为一个新创建的 Promise

  4. 返回 promise,并异步继续以下步骤。

  5. 运行用于为 typedDescriptor 创建 PermissionStatus 的步骤,并令 status 为结果。

  6. 使用 typedDescriptorstatus 作为 参数,运行名为 typedDescriptor.name 的特性的权限请求算法

  7. 如果上一步抛出异常,则使用该 异常拒绝 promise

  8. 否则,使用 status 兑现 promise

3. Permission Registry 中的附加字段

Permission Registry 中的强大特性还会定义一个 权限请求 算法

输入
行为

使用 请求 更多权限中的算法,向用户显示任何必要提示,以尝试增加 权限,并更新权限结果类型的实例以 匹配。

返回

无返回值,但如果请求可能异常失败,则可以抛出异常。 (仅仅是权限被拒绝并不属于异常。)

示例调用方
默认

如果未指定,则默认为默认权限请求 算法

3.1. 默认请求算法

给定一个 PermissionDescriptor permissionDesc 和一个 PermissionStatus status默认权限请求算法运行以下步骤:

  1. permissionDescstatus 运行默认权限查询算法

  2. 如果 status.state 不是 "prompt", 则中止这些步骤。

  3. 请求使用 permissionDesc 的权限。

  4. 再次对 permissionDescstatus 运行默认权限查询算法

    在不会在环境设置对象内持久存储权限的浏览器上,这将始终 返回 "prompt", 但仍会向用户显示一个不必要的提示。这可能意味着不应有任何 权限使用默认权限请求算法, 因为它永远无法返回适当的对象能力。

4. 安全性考量

尚未识别出任何安全性考量。

5. 隐私考量

尚未识别出任何隐私考量。

一致性

文档 约定

一致性要求通过描述性断言 与 RFC 2119 术语的组合来 表达。 规范性部分中的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、 “MAY” 和 “OPTIONAL” 应按 RFC 2119 中的描述 进行解释。 但是,为了可读性, 这些词在本规范中并不全部以大写字母出现。

本规范的所有文本均为规范性内容, 但明确标记为非规范性的章节、示例和注释除外。 [RFC2119]

本规范中的示例以前置词语 “for example” 引入,或通过 class="example" 与规范性文本分隔开, 如下所示:

这是一个资料性示例的例子。

资料性注释以前置词语 “Note” 开始,并通过 class="note" 与规范性文本分隔开, 如下所示:

Note,这是一个资料性注释。

一致性 算法

作为算法一部分以祈使语气表述的要求 (例如 "strip any leading space characters" 或 "return false and abort these steps") 应按照引入该算法时使用的关键词 ("must"、"should"、"may" 等) 的含义来解释。

以算法或具体步骤表述的一致性要求 可以用任何方式实现, 只要最终结果等价即可。 特别是,本规范中定义的算法 旨在易于理解, 并不旨在具备高性能。 鼓励实现者进行优化。

索引

由本 规范定义的术语

由 引用定义的术语

参考文献

规范性参考文献

[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[PERMISSIONS]
Marcos Caceres; Mike Taylor. Permissions. 2022 年 3 月 11 日. WD. URL: https://www.w3.org/TR/permissions/
[RFC2119]
S. Bradner. 用于 RFC 中 表示要求级别的关键词. 1997 年 3 月. 最佳当前实践. URL: https://datatracker.ietf.org/doc/html/rfc2119
[WEBIDL]
Edgar Chen; Timothy Gu. Web IDL Standard. Living Standard. URL: https://webidl.spec.whatwg.org/

资料性参考文献

[geolocation-API]
Andrei Popescu. Geolocation API Specification 2nd Edition. 2016 年 11 月 8 日. REC. URL: https://www.w3.org/TR/geolocation-API/
[NOTIFICATIONS]
Anne van Kesteren. Notifications API Standard. Living Standard. URL: https://notifications.spec.whatwg.org/

IDL 索引

partial interface Permissions {
  Promise<PermissionStatus> request(object permissionDesc);
};

问题索引

在浏览器不会在环境 设置对象内持久存储权限的情况下,这将始终返回 "prompt", 但仍会向用户显示一个不必要的提示。这可能意味着不应有任何 权限使用默认 权限请求算法, 因为它永远无法返回适当的对象能力。