Permissions、sandbox 与能力请求

Permissions、sandbox 与能力请求

机制拆解

权限查询只读取当前状态，真正请求能力仍需用户手势和对应 API。下面的页面会把 granted、prompt、denied 和安全上下文失败分别显示出来：

<button id="locate">读取位置权限</button>
<output id="status">未查询</output>
<script>
  const status = document.querySelector('#status')
  document.querySelector('#locate').addEventListener('click', async () => {
    if (!isSecureContext || !navigator.permissions) {
      status.textContent = '当前上下文不支持权限查询'
      return
    }
    try {
      const permission = await navigator.permissions.query({ name: 'geolocation' })
      status.textContent = `查询状态：${permission.state}`
      permission.addEventListener('change', () => {
        status.textContent = `状态变化：${permission.state}`
      })
      navigator.geolocation.getCurrentPosition(
        () => { status.textContent += '；能力调用成功' },
        (error) => { status.textContent += `；能力调用失败：${error.code}` }
      )
    } catch (error) {
      status.textContent = `权限查询失败：${error.name}`
    }
  })
</script>

分别在 HTTPS、普通 HTTP 和拒绝权限的环境中操作；记录查询状态、能力调用成功或 getCurrentPosition 的 error.code，不把 prompt 当作已经授权。

边界与失败路径

• 所有权：监听器、observer、worker、连接、缓存和焦点都有创建者与释放时机；页面隐藏、路由离开和元素移除时都要验证。
• 宿主差异：SSR、Web Worker、Shadow DOM、跨文档、跨源和辅助技术不会共享同一套全局对象与事件路径。
• 错误分类：取消、超时、权限拒绝、协议错误、配额不足和浏览器不支持应分别进入可观察状态。
• 安全边界：用户输入、URL、HTML、消息和持久化数据不能仅因为来自同源或类型正确就视为可信。

可运行实验

在 HTTPS 页面或 localhost 中运行上面的权限查询；再用一个普通 HTTP 地址打开同一文件。每次记录 isSecureContext、查询状态和地理位置回调的 error.code。把 iframe 增加 allow="geolocation" 与不增加分别测试，观察权限策略对嵌入页面的影响。

实验记录必须区分 prompt、denied、查询 API 不可用和用户拒绝回调；不能把权限查询成功当作能力调用成功。

练习

1. 为安全上下文、已授权、待询问和已拒绝四种状态写出 UI 提示与下一步动作。
2. 在 iframe 中移除 allow="geolocation"，解释为什么顶层页面有权限时子页面仍可能收到拒绝。
3. 比较权限查询与直接调用能力 API 的职责，说明为什么用户手势、浏览器策略和业务降级必须分别记录。

查看本节答案

下一步

完成练习后回到本章概览，按下一篇继续；遇到跨章节故障，先回到本节的所有权与宿主边界。