最近整理一篇关于 一些 浏览器html5 相关api 的权限的东西 虽然大部分都可以用了 但是基本上还是草案居多
本文所有的demo都在 这里 blog-demo/permission 代码在这github.com/xjpin/blog-demo
有几个权限的demo还没有写好 之后会单独写出来
w3c.github.io/permissions: Editor’s Draft, 17 October 2016
事实上不止链接中的这几个权限, 比如usb
, 本文就只对下面列出的这几个权限进行介绍
1 | enum PermissionName { |
push
background-sync
需要配合service worker
工作
notifications
在service worker
与浏览器环境中有不同
检查权限
1 | navigator.permissions.query({ |
geolocation
www.w3.org/TR/geolocation-API: W3C Recommendation 8 November 2016
虽然这个版本是2016年11月8日出的第二版 才出没多久 按照其他权限的实现方式 估计这个方案会改成Promise
的方式 而且会增加一个专门来请求权限的接口
1 | // 调用的时候会向用户请求权限 |
Notification
notifications.spec.whatwg.org: Living Standard — Last Updated 15 February 2017
通知有两套实现方案 一个是在浏览器中直接调用构造函数生成通知 另外一个是中调用service worker
里的serviceWorkerRegistration
对象上的构造方法
两者有两个区别
- 事件监听方式不同 第二种可以将事件注册在全局对象
ServiceWorkerGlobalScope
上 - 通知属性不同 第二种比第一种多了
actions
属性 可以在通知框上添加额外的按钮
1 | // 请求通知权限 |
push
www.w3.org/TR/push-api/: W3C Working Draft 22 February 2017
相关内容:
appmanifest
Progressive Web Apps
这个api和Progressive Web Apps
的推送有关 内容比较复杂 之后我再单独开一篇文章写这个吧
1 | // in browser |
midi
web midi: W3C Working Draft 17 March 2015
获取设备上的MIDI
接口 多用于音频设备(主机上也留有这种接口 给键盘鼠标用的)
这个api太专业了 我这里没有测试的设备 所以没法试这个代码 而且数据请求都是直接传送二进制数据 所以也比较头疼
1 |
|
media: camera, microphone, speaker, device-info
www.w3.org/TR/mediacapture-streams: W3C Candidate Recommendation 19 May 2016
www.w3.org/TR/audio-output: W3C Working Draft 15 December 2016
主要涉及两个函数
navigator.mediaDevices.enumerateDevices()
: 查询设备信息 和device-info
权限相关 一般都是允许的
navigator.mediaDevices.getUserMedia()
: 获取设备媒体输入数据 对应的camera
和microphone
权限 这个函数做过一次相当大的调整 原本是直接在navigator
下的navigator.getUserMedia
而且是回调式的 现在是基于Promise
的异步
关于speaker
权限 暂时还没有去研究 看接口应该是能指定某个音箱设备播放声音 而且有单独的标准audio-output
除了浏览器的接口外 还涉及HTMLMediaElement相关的东西
srcObject
属性 设置播放源
1 | video.srcObject = stream; |
sinkId
属性 设置播放设备
1 | audio.setSinkId(deviceId); |
capture
属性 选择摄像头拍摄内容作为文件 移动端较为常见 而且常内置于type="file"
标签中
1 | <input type="file" accept="video/*, image/*, audio/*" capture> |
allowusermedia
属性
1 | iframe.allowUserMedia = true |
MediaStream Image Capture 图像捕获相关的接口
除了这些之外 这个标准还和webrtc标准有一点联系 可以研究一下
标准里涉及到了多个非常非常相似的几个数据结构
1 | SupportedConstraints { // 各个属性是否支持 |
这三个结构 相当于Settings
是最基础的 Capabilities
在前者只是给每个属性增加了扩展: 字符串可以使用数组, 数值可以给范围 ConstraintSet
再进行扩展 给每个属性增加了预期值和实际值 Constraints
再在前者上增加了一个属性 可以设置为同结构的数组 几个数据结构用的地方也不太一样 要注意
1 | // device-info |
background-sync
wicg.github.io/BackgroundSync/spec: Draft Community Group Report, 2 August 2016
Note: Background sync SHOULD be enabled by default. Having the permission denied is considered an exceptional case.
browser
与ServiceWorker
之间进行的相当简单的单向通信 不能传数据
当一个耗时的重要操作还没有完成的时候 如果用户把浏览器关了 就会造成数据丢失什么的 为了解决这个问题可以吧这些操作放到ServiceWorker
中进行处理 这样
其实感觉这个权限有点点奇怪
1 | // in browser |
bluetooth
webbluetoothcg.github.io/web-bluetooth: Draft Community Group Report, 15 February 2017
社区 www.w3.org/community/web-bluetooth
相当复杂 另起一篇 而且没有测试设备 这个月初的时候官方才刚刚出了一个demo 还挺复杂
其实本篇文章就是从这个demo开始的 本来想研究下WebBluetooth
然后涉及到浏览器权限 然后干脆就整理一个吧 于是就写了这篇整理权限的东西
persistent-storage
storage.spec.whatwg.org: Living Standard — Last Updated 23 February 2017
似乎这个权限没有明显的代码实例 只是一个普通的查询用的权限 根据这篇文章的回复persistent-storage 似乎认为这个接口是用来查询浏览器端数据存储是否为永久性的. 如果权限查询结果为true
表明这些存储方式存储的数据 在系统存储空间充足的情况下 不会被浏览器清理掉 具体有哪些存储方式 文档有说明storage.spec.whatwg.org/#infrastructure 包括网络请求的缓存 cookie IndexDB LocalStorage等
一个同源站点关联里一个站点存储单元
(site storage units) 每个站点存储单元
包含了一个单个的空间
(box)
1 | // 在`persistent-storage`权限为`granted`的情况下 将`站点存储单元`的`存储空间`类型转换为`persistent box` |