小编Dag*_*der的帖子

这是我的Mac Chromecast应用程序的屏幕截图.正如您所看到的,勾选"在检查更新时发送此Chromecast的序列号"的选项已丢失.我在同一个wifi网络上有另一个Chromecast设备,并且该设备存在该选项.有人知道为什么这个选项消失了,我怎么能把它拿回去？我需要它来白名单设备,以便我可以为它开发应用程序.

免责声明:我是node.js的新手,所以如果这是一个奇怪的问题我很抱歉:)

我有一个node.js使用express.js来提供REST-API.REST-API提供的数据由node.js应用程序从nosql数据库中提取.所有客户端仅使用HTTP-GET.但有一个例外:数据是来自master数据库的PUT和DELETEd(另一个服务器上的关系数据库).这种设置的想法当然是让'node.js/nosql数据库'服务器成为公共前端,从而保护主数据库免受繁重的流量.

可能许多不同的客户端应用程序将使用REST-API,但主要是它将由具有较长生命周期(通常为0.5到2小时)的客户端应用程序使用.我没有让这个应用程序不断地轮询REST-API以寻找可能的新数据,而是希望使用websockets,以便在有任何新数据时只将数据发送到客户端.我将使用node.js应用程序,并且可能使用socket.io,以便在客户端不支持websockets时它可以回退到api-polling.每次nosql数据库中的主数据库PUT或DELETE对象时,都应将新数据发送到客户端.

问题是我是否应该为API和websockets使用一个node.js,或者为API使用一个node.js,为websockets使用一个.

需要考虑的事项: - 性能:应用程序将托管在服务器集群上,前面有负载均衡器和HTTP加速器.处理一切的应用程序是否会比具有不同任务的两个应用程序执 - 应用程序之间的流量:如果我选择一个两个应用程序解决方案,从主数据库接收PUT和DELETE的api应用程序每次收到新数据时都必须注意websocket应用程序(或主数据库必须注意两个应用程序).双倍流量是否会成为性能问题？ - 代码清理:我相信两个应用程序将产生更清晰和更好的代码,但是再一次肯定会有两个应用程序的共同代码,这将导致它有两个副本.

至于负载有多重,很难说,但可能的峰值可能涉及:50000个客户端,每个监听多达5个不同的通道,从主站发送新数据,每5秒钟新数据应发送到大约25%客户端(对于某些数据,它应该发送到所有客户端,其他数据可能低于1%的客户端)

更新: 谢谢你们的答案.这里有更多的思想食物.我决定有两个node.js应用程序,一个用于REST-API,另一个用于Web套接字.原因是我相信它会更容易扩展它们.首先,整个系统将托管在三个物理服务器和一个node.js应用程序上,每个服务器上的REST-API应该足够,但对于websocket应用程序,可能需要在每个物理服务器上有几个实例.

我已经在 Google 和 SO 上搜索了几个小时，但没有找到与我现在面临的挑战相同的人，所以这里是：

我们有一个数据库，我们投入了大量金钱和精力来维护它。数据库中的数据可通过 REST-API 公开获得。我们还有一个使用此 API 的公共 javascript 网络应用程序，我们将其出售给大约 30-40 位客户。由于 API 中的数据对我们来说非常有价值，我们希望尝试保护它，以便没有人可以从中抓取内容并制作自己的数据库副本。我们也不希望任何人在未经我们同意的情况下使用我们的 API 构建服务。同时，我们需要我们在http://www.example.com/theApp、http://www.example2.com/theApp、http://www.example3.com/theApp等的网络应用程序才能访问 API。没有用户参与。大家可以去http://www.example.com/theApp并获得网站的全部功能。API 也是只读的，因此我们不会担心任何试图污染我们数据的人。

javascript web 应用程序是使用 react.js 和 node.js 服务器构建的。当然，SSL 将用于服务器和客户端之间的所有通信。

我认为行不通的事情：

• 使用户登录以使用http://www.example.com/theApp。（没有额外的登录功能，所以这只会惹恼用户。）
• 在 Web 应用程序中存储密码/令牌。（javascript 中没有任何东西是安全的，但是混淆代码是安全的。）
• 使 Web 应用程序客户端从身份验证服务器请求令牌。（这个请求也可以由敌对的客户完成。）
• 将允许的 IP 列入白名单。（每个人都可以访问这些网站...）
• 将 URL 列入白名单。（URL 作为标头发送。标头可以被操纵。）

可能有效的事情（或至少是解决方案的一部分）：

• 让 node.js 服务器应用程序代表客户端从身份验证服务器请求令牌。（但我仍然不知道这将如何防止恶意客户端向 node.js 服务器应用程序发出相同的请求）
• 混淆视听。（这可能会推迟大多数敌对用户，但更持久（和最熟练/最危险？）只会对挑战感到兴奋并最终能够破解它。）

由于这是我们试图实现的相当复杂的事情，所以我开始相信这可能是不可能的，如果有人对该怎么做有一些建议，我将不胜感激。如果给出充分的理由，“不要这样做”是一个非常好的答案。我更多的是这里的概念性解决方案，但如果有人想具体了解软件，我们有一个带有 node.js、Nginx 和 PHP 的 Linux 环境。