>您有一个网络服务器,只有在您的客户端安装了特定的Chrome扩展程序时,才能提供独家内容.
>您有两种提供Chrome扩展程序包的可能性：
>从Chrome网上应用店
>从你自己的服务器
问题：
>有很多解决方案可以知道安装了Chrome扩展程序：
>使用Content Scripts加载网页时插入元素.
>使用Web Requests向服务器发送特定头文件.
>等
>但是,似乎没有解决方案来检查与您的网页交互的Chrome扩展是否是真实的.
>的确,Chrome浏览器扩展程序的源代码可以由任何想要的用户查看和复制,似乎无法知道当前的Chrome扩展程序与您的网页交互是否是您已发布的或克隆的版本(也许有些改变)由另一个人.
>您似乎只能知道一些Chrome扩展程序以“预期的方式”与您的网页进行交互,但是您无法验证其真实性.
解决方案？
>一个解决方案可能包括使用Chrome扩展程序包中包含的信息,哪些不能被其他人更改或复制：
>将Chrome扩展程序的ID发送到服务器？但是怎么样
>该ID必须由您和您的JavaScript代码发送,似乎没有办法使用“内部”Chrome功能.
>所以如果有人只是将相同的ID发送到您的服务器(某种Chrome扩展的ID欺骗),那么您的服务器将其Chrome扩展程序视为真正的扩展！
>使用打包应用程序时提供的私钥？但是怎么样
>似乎无法以编程方式访问或以任何方式使用该密钥！
>另一个解决方案是使用NPAPI Plugins并嵌入认证方法,如GPG等.但是这个解决方案是不可取的,主要是因为它的API’s doc的“警告”部分.
>还有其他解决方案吗？
笔记
这个问题试图在Chrome扩展程序的API中提出真正的安全问题：如何在与您的服务进行互动时检查Chrome扩展的真实性.
如果有任何遗漏的可能性或任何误解,请随时向我发表评论.
解决方法
来自客户端的任何信息都可以通过其他方式进行复制.这是一个本质上同样的问题,试图证明当用户登录到他们的帐户时,其实是用户没有找到或被给予他们的用户名和密码的其他人.
互联网安全模型建立在2个方面,试图进行沟通,而第三方无法模仿,修改或倾听对话.在不隐藏扩展的源代码的情况下,客户端与第三方无法区分(副本之间的文件 – 无法确定哪个是哪个).
如果源代码被隐藏,它将成为一个完整的其他故事.现在,用户或恶意方无法访问真实客户端知道的所有常规安全模型.但是,Chrome将允许在扩展中隐藏源代码,因为它会产生其他安全问题.
一些源代码可以使用NPAPI插件隐藏,如您所说,但它带有您已经知道的价格.
回到当前状态：
现在,它成为交互意味着什么的问题.
如果交互意味着当用户在页面上时,您想知道是否是您的扩展名或其他一些,那么您可以获得的最接近的是将您的页面列在应用程序部分的扩展清单中,如文档here
这将允许您在页面上询问应用程序是否通过使用安装
chrome.app.isInstalled
这将返回布尔值,显示您的应用程序是否安装.该命令记录为here
但是,这并不能解决问题,因为扩展名可能已安装,但未启用,还有另一个扩展名嘲笑与您的站点的通信.
此外,验证在客户端,所以使用该验证的任何函数都可以被覆盖,以忽略该变量的结果.
然而,如果交互意味着使XMLHttpRequests发生,那么你就不幸了.由于上述源代码的可见性,无法使用当前的方法.
但是,如果限制您的网站对授权实体的可用性,我建议使用常规验证方式：让用户登录将允许您创建一个会话.这个会话将被传播到扩展程序所做的所有请求,所以你被定期的客户端登录信任问题,如帐户共享等等.这当然可以通过使用户通过他们的Google帐户进行登录来管理,大部分都是不情愿的通过阻止似乎被滥用的帐户来分享和进一步缓解.
