【问题标题】:User specific version of extensions from Chrome Web Store来自 Chrome 网上应用店的用户特定版本的扩展程序
【发布时间】:2012-08-03 07:14:24
【问题描述】:

我一直在为我的公司开发和维护一个 Chrome 扩展程序,每个客户都将在代码中分配一个唯一的 ID。我们一直在使用该 ID 来确定许可证状态并登录我们的服务(付费延期,每月订阅费)。

到目前为止,我们自己托管了扩展文件,并为每个客户扩展提供了唯一的更新 URL。这很好很简单;访问我们的网站,点击安装,您就完成了。然而,在最新的 Chrome 版本中,该安装过程已被 Google 阻止,因为他们现在要求用户通过将 CRX 文件拖放到 chrome://chrome/extensions/ 选项卡中来安装扩展程序。当然,除非您的扩展程序可以通过 Chrome 网上应用店获得 - 这导致我遇到了问题:

  • 我们不希望拖放式 CRX 安装 - 需要网上应用店。
  • 我们不希望 Web Store 上有多个版本的扩展程序(每个客户一个),因为每次更新扩展程序时,这都是一个维护地狱。
  • 我们不想使用网上应用店许可,因为:
    • 需要 OpenID 登录。
    • 我们向有许多学生的学校出售扩展程序,由学校支付账单,而不是学生。
    • 我们不想将我们的付款方式锁定在一个浏览器上,即我们希望能够通过我们的或服务器维持许可和付款。
  • 我们不希望用户输入许可证密钥,因为这对于数千名学生必须输入密钥的风险太大 - 而且它需要某种存储(cookies/localStorage),最终会被清除,需要要重新输入的许可证密钥。

我不能 100% 确定我的陈述是否完全正确,如果我遗漏了什么,请随时赐教。

如果是,问题是我们是否可以通过网上应用店为每个客户定制扩展程序(使用唯一 ID),而无需为每个 ID 发布一个扩展程序?

作为附带问题,任何可能通过其他方法解决问题的答案也将被接受。

【问题讨论】:

  • 关于 localStorage:你的应用程序的 localStorage 不会被清除,除非你的应用程序这样做(在其中你会知道发生了什么并可以适当地处理它),或者你的用户从 JS 执行它控制台(在这种情况下,他会知道它坏了,因为他在 JS 控制台上乱搞)。应用程序 localStorage 永远不会被浏览器任意清除——even when the user wipes all localStorage(请注意,链接的错误标记为“WontFix”)。但是,成千上万的学生输入许可证密钥是一个单独的问题。

标签: google-chrome-extension chrome-web-store


【解决方案1】:

对于下面的答案,我假设您的应用是打包应用,而不是托管应用。

我有一个与您当前的实现非常相似的解决方案,但为用户增加了一个额外的步骤。对于学生用户,流程如下:

  1. 从网上应用店下载应用程序。该应用程序尚未运行,启动它只会显示“请点击您的学校/机构提供的激活链接”消息。
  2. 单击您的服务器(即您用来托管更新 URL 的服务器)上托管的链接,该链接类似于 https://myserver.com/activateapp.php?custid=123456789。您为您支持的每个机构托管一个此类链接,并且该机构的工作是向其学生提供链接。此链接可激活应用。

从实现的角度来看,它是这样工作的:

  1. 在您的服务器上托管一个页面https://myserver.com/activateapp.php。服务器端,检查custid参数是否有效。如果不是,请发送 404 错误。
  2. 您的应用程序有一个内容脚本被注入https://myserver.com/activateapp.php,它会扫描 URL 并挑选出客户 ID。应用程序找到 ID 后,会将其存储在 localStorage 中。由于无效的客户 ID 会产生 404 错误,因此您知道当内容脚本运行时,页面不是 404 错误;因此,它正在读取有效的客户 ID。
  3. 每当应用程序想要查询您的服务时,它都会检查它在 localStorage 中是否有客户 ID。如果是,则使用该 ID;如果没有,它会显示一条消息,表明应用程序尚未激活。打包的应用程序永远不会删除其localStorage,除非您的应用程序被编程为擦除自己的存储空间,或者用户从控制台执行此操作。存储擦除永远不会“意外”发生。即使是最强大的浏览器范围内的数据/缓存清除,也只会从网页中清除 localStorage,而不是从应用程序和扩展程序中清除。

为了提高安全性 - 如果您不希望人们随机猜测客户 ID - 您可以添加额外的签名参数,例如 https://myserver.com/activateapp.php?custid=123456789&sig=2464509243。这个额外的参数是客户 ID 的一些经过服务器验证的转换(理想情况下是加密签名或与数据库中的 ID 相关联的纯随机值),任何人都无法猜到。当activateapp.php 的请求到达服务器时,它会检查有效的客户 ID 有效的对应签名。当然,这并不能阻止对有效链接具有合法访问权限的人将链接分享给未经授权的人,但我认为这是您的旧系统中存在的漏洞。

【讨论】:

  • 我建议使用 chrome.storage.sync 而不是 localStorage,因为这样可以让用户在使用 Google 同步时在多台计算机上使用相同的凭据。
  • 我的老板赞成这种方法。出于好奇,您会怎么做才能避免像提供激活链接那样简单地共享扩展程序?
  • 我能想到的唯一真正的安全选项是一个机构范围的用户名/密码,用户输入为 1) HTTP 身份验证或 2) 在登录页面(例如 enterpass.php?custid=...)上,然后重定向到activateapp.php,并将用户名和密码作为 POST 数据传递给激活页面。在 #2 下,activateapp.php 仅在 POST 数据正确时返回 200 OK 响应,此外还会检查有效的 custid
  • 另一个(不是很好)选项是检查请求的源IP,并验证它是否在学校计算机的正常IP范围内。这要求学生在激活应用程序时在现场(或通过隧道连接到现场的计算机)。这最适合拥有指定 IP 块或通过代理运行所有流量的大学。
  • 是的,期待一些类似于登录的内容,但即使这样也不安全,因为可以检查 Javascript 和 localStorage。
猜你喜欢
  • 2015-04-06
  • 1970-01-01
  • 2013-01-18
  • 2014-08-25
  • 1970-01-01
  • 2015-04-10
  • 2014-08-26
  • 2013-05-16
  • 1970-01-01
相关资源
最近更新 更多