【发布时间】：2018-04-27 12:32:41
【问题描述】：
我目前正在使用 MEAN 堆栈开发 Web 应用程序。它具有社交功能，因此我希望能够向用户推送通知。
我现在这样做的方式是，当发生应该是通知的事情时，它会存储在带有未读标志的 mongo 数据库中。每个客户端会每 30 秒向服务器发送一次 get 请求，并会收到所有标记为未读的通知，然后将其标记为已读。
我想改用消息队列和套接字，这样可以减少使用的网络资源，并为用户提供实时体验。我曾考虑过使用 redis 及其 pubsub 结构，但我似乎无法弄清楚如何安全地做到这一点。如果我向受影响的用户推送通知，那么恶意的人会不会很容易订阅别人的频道并收到不适合他们的通知？我是否遗漏了什么，或者这只是这样一个系统的错误方法？
编辑：如果其他阅读本文的人有同样的问题，我会更新我所使用的解决方案。
我没有像答案建议的那样使用rabbitmq，而是认为一个更简单、更优雅的解决方案是只使用socket.io。当新的套接字连接到服务器时，我会在 redis 内存数据库中保存从 userID 到 socketId 的映射。 （在我验证了他们的令牌之后）这样，如果我需要向用户推送通知，我只需在 redis 数据库中查找 socketId，然后将其发送到正确的套接字。
这样我不需要任何安全性，因为 socketID 是不可猜测的，并且消息仅通过属于给定用户的单个套接字发送。
这种方式只会通过给定套接字的连接发送，因为套接字ID仅用于服务器端来跟踪所有连接。这意味着没有其他人可以使用其他人的 socketID 来“监听”。
【问题讨论】：
-
我不同意。通过默默无闻的安全被认为已经过时了大约 130 年。身份验证和授权被认为是最佳实践是有原因的：您确定通信伙伴（主题）实际上是他声称的那个人，并且您检查该特定主题是否被授权对资源执行请求的操作。由于只有一些难以猜测的沟通渠道，您永远无法确定谁会看到您的数据。
-
我完全同意整个“通过默默无闻的安全”这件事还不够好。我不知道为什么我强调 socketIDs 是不可猜测的。据我了解，使用socket.io，客户端无法“订阅”另一个套接字ID。它只是服务器端的一个内部 ID，用于跟踪各个套接字。
-
感谢您的评论，我将更改我的答案，以便更清楚。
标签： node.js mongodb sockets redis notifications