【问题标题】:Whitelist a CORS policy for a browser extension?将浏览器扩展的 CORS 策略列入白名单?
【发布时间】:2020-05-21 23:06:56
【问题描述】:

我有一个 POST 到服务器的浏览器扩展。我想在我的服务器中将扩展程序的来源列入白名单。例如,对 Chrome 扩展程序的请求来自以下位置:chrome-extension://fjhbdidbplpijoncnlfoadfadfasdf 和来自 Firefox,例如:moz-extension://cadf4351-e4f3-ca4d-b974-812309843dafd

我意识到我可以将服务器上的这些特定地址列入白名单,但我不确定它们是否是静态地址。这些随机生成的位置是否会发生变化,例如我是否曾经提交过更新?有没有办法永久设置它们?

【问题讨论】:

  • 对于未打包的扩展,您可以pin the id,对于商店中的扩展,它们的 id 永远不会改变。
  • Firefox 使用动态生成的 uuid。每个用户在 url 中都有不同的 uuid。

标签: google-chrome firefox google-chrome-extension cors firefox-addon


【解决方案1】:

这些会改变吗?

Chrome 和 Firefox 的情况不同。

对于网上应用店中已发布的扩展程序,ID 是固定的。你可以信赖它。

对于开发中的解压缩扩展,ID is determined 可以是清单中的"key" 值(如果存在),也可以是扩展文件夹的绝对路径。因此,如果您移动扩展程序,它可能会改变。但是您可以通过提供有效的"key""pin" it

火狐

您在 Mozilla 中看到的是特定于安装的来源。无论扩展程序的 ID 是什么,您在此处看到的 UUID 在每次扩展程序安装时都会有所不同(但应该通过更新保持不变)。

关于机制in this bug有一些讨论。

本质上,这是一种抗扩展阻塞技术。

不幸的是,这意味着您不能只将一个来源列入白名单并完成它。

依赖这个是个好主意吗?

可能不会。虽然浏览器倾向于忠实地报告 Origin,但其他能够生成请求的工具并没有遵循这一点。因此,它会比较容易被欺骗。

【讨论】:

  • 该死!我在服务器上将我的 Firefox moz 扩展地址列入白名单,它似乎工作正常。现在我担心其他 beta 用户可能会安装失败
  • 你认为这样的事情是否可行:'moz-extension://*'?
  • 我猜你可以欺骗来源,但总比允许一切都好
  • @greenie-beans 我只是好奇。你是如何解决这个问题的(服务器端)?
猜你喜欢
  • 2012-08-04
  • 2019-12-18
  • 1970-01-01
  • 2015-04-27
  • 2011-09-30
  • 2015-01-04
  • 2020-11-25
  • 2016-09-29
相关资源
最近更新 更多