39

我们正在运行为 Chrome 和 Samsung Internet 启用推送通知的渐进式 Web 应用程序，并鼓励我们的用户将其添加到他们的主屏幕。我们严格记录和监控浏览器异常以保持高质量的服务。

自 2018 年 5 月 22 日以来，我们注意到令人费解的 JavaScript 异常突然增加，这些异常源自对以前从未失败过的标准功能检测 Web API 的调用。

例如，以下代码会产生以下错误，尽管“push”显然是Permissions.query() 规范的有效值：

const permissionStatus = await navigator
  .permissions
  .query({ name: 'push', userVisibleOnly: true });

TypeError: Failed to read the 'query' property from 'Permissions': The provided value 'push' is not a valid enum value of type PermissionName.

经过仔细检查，我们注意到所有这些错误都发生在不是我们实际客户的用户代理执行脚本期间。相反，我们看到一个未知的客户端在我们的用户访问后立即查询我们的应用程序：

  1. 用户访问我们的 PWA，没有报错
  2. 用户使用“添加到主屏幕”（大部分时间），没有报错
  3. 未知客户访问我们的 PWA，报错。

这个未知的客户端执行 HTTP 请求承载特征模式：

  • URL 与用户访问的 URL 完全相同
  • 原始 IP 地址分配给 Google, Inc.（66.102.0.0/20 或 66.249.64.0/19 范围）
  • 推荐人是“<a href="https://www.google.com/" rel="noreferrer">https://www.google.com/”</li>
  • 用户代理字符串以某种方式匹配用户之一：相同版本的 Android，相同的设备构建，相同的浏览器，但不同的浏览器版本，始终来自此列表：
    • Chrome/66.0.3359.126（5月22日→5月30日）
    • Chrome/66.0.3359.158（6 月 11 日 → 6 月 25 日）
    • SamsungBrowser/3.0 Chrome/38.0.2125.102（6月25日→6月27日）
    • SamsungBrowser/6.4 Chrome/56.0.2924.87（5月22日→5月30日，6月25日）
    • SamsungBrowser/7.0 Chrome/59.0.3071.125（5月22日→5月30日、6月25日）

更重要的是，这些请求只是间歇性地以一种看似可控的方式发生，如上面的日期和下面的图表所示：

来自 Google 的未知客户端的请求频率

这一点，以及我们在大多数情况下检测到“添加到主屏幕”的使用情况，让我们怀疑这是否可能是与WebAPK 相关的实验。然而，这是无证的，因此非常令人费解。

这个未知的源自 Google 的客户端是什么？

它的目的是什么？

开发者应该如何发现它们，应该采取什么措施？

2018 年 8 月更新：上述请求现在似乎已经完全消失了……但它们可能是我们现在看到的某种类似请求的某种原型。这些新类型的请求仍然来自 Google 服务器，并且似乎专门针对我们 PWA 的 Web Manifest，因此不再触发 JavaScript 错误。它们都带有明确后缀的 Chrome/59+ 用户代理字符串(via Google-Chrome-WebAPK)。其他浏览器，如三星互联网，尚未被发现。

4

1 回答 1

1

push这可能是一个没有权限的无头 Chrome（可能是预发布测试，以防你在 Play 商店中有它） ；例如。使用 Pupeteer，只能覆盖权限，但不能真正接受权限提示......而且通常没有附加桌面，可以将通知推送到。

只是为了try整理catch出不支持push许可的客户。

navigator.permissions
  .query({name: 'push', userVisibleOnly: true})
  .then(function(permissionStatus) {
      console.log('push permission state is ', permissionStatus.state);
  })
  .catch((error) => {
      console.warn(error);
  });
于 2020-06-07T15:18:13.313 回答