我有一个小工具[*]连接到用户的WiFi网络,并通过简单的REST界面响应命令。用户使用Web应用程序来控制此小工具。网络应用程序目前通过http
提供,应用程序的javascript对AJget调用小工具的本地IP地址进行控制。这个方案运作良好,我没有问题。
[*]“小工具”是指用户在家中购买和安装的实际物理IoT设备,并配置为连接到家庭WiFi网络
现在,我想通过https
投放此网络应用。我在托管方面设置https
没有问题。问题是,现在浏览器阻止访问小工具(因为小工具的REST API已超过http
而非https
)。
显而易见的解决方案是让小工具在https
上提供REST API。但是怎么样?它有一个本地IP地址,没有人会为它颁发证书。 (即使他们这样做了,我也必须为每个可能的本地IP地址购买大量证书。)我可以通过云进行往返(通过在我的服务器端添加额外的逻辑来接受来自Web应用程序的命令并转发它通过另一个连接到小工具),但这会增加延迟。
有解决这个问题的方法吗?我想到的一种可能性是:
*.mydomain.com
)192-168-1-123.mydomain.com
将映射到192.168.1.123
)https://192-168-1-123.mydomain.com
而不是http://192.168.1.123
进行AJAX调用,除了初始DNS查询外,延迟不会受到影响这会有用吗?尝试这是一个昂贵的实验(通配符证书成本约200美元),运行DNS服务器似乎是很多的工作。另外,我发现自己没有资格考虑安全问题。
也许那里已经有了解决这个问题的服务?
答案 0 :(得分:1)
如果您只想通过Web浏览器访问设备API,那么简单的解决方案就是通过您的Web服务器代理对设备的所有请求。这甚至是设备的自签名证书也不会成为问题。但问题只是服务器必须与您的设备在同一网络上。
如果您不在同一个网络上,可以编写一个简单的浏览器插件(chrome)来将api请求发送到IoT设备。但随后对app /插件的依赖将是笨拙的。
答案 1 :(得分:0)
虽然这是一个非常古老的问题,但你现在仍然没有找到现成的解决方案。
就像@ Jaffa-the-cake在评论中发表的那样,你可以依靠Plex的做法,Filippo Valsorda在他的博客中解释道: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/
这与你自己提出的非常相似。您甚至不需要通配符证书,但您可以使用Let的加密即时生成证书。 (如果您愿意,您仍然可以使用通配符证书,我们现在也支持加密。)
就在昨天,我为该工作流程做了一个手动概念验证,可以通过以下步骤自动完成:
现在,您将使用本地IP与本地服务器建立HTTPS连接,但这是一个公开解析的DNS条目。
缺点是这不能从任意客户端脱机工作。您需要考虑一个良好的安全性概念,以便在请求DNS和证书的客户端与将生成这些信息的Web服务之间建立信任。
顺便说一句,你介意分享你正在建造什么样的小工具吗?