我正在设置一个 socket.io 服务器来处理套接字请求。它在端口 1234 上运行。它与 laravel 5.1 应用程序一起运行。 Laravel 使用 redis 来处理 session 。
我有很多关于将 laravel 与 socket.io 连接起来的教程，一切都非常简单。我可以连接、响应并将消息转发回套接字和 laravel 应用程序。
但是每个教程都避免了此设置的身份验证部分。在 socket:1234 空间内收到消息后，我如何将该消息转发到 laravel，同时确保该请求已被授权。
理想情况下，我会简单地共享 session ，并验证 XSRF token 。因为这两个应用程序在不同的端口上，所以我无法直接获取 session 。
目前我正在使用另一种方法，它涉及以下内容:
- 在套接字连接(在节点中)后，我使用节点的 Crypto 库和节点的 PHPUnserialise 库解密连接时发送的 cookie。
- 这给了我 laravel session ID(来自 cookie)
- 我用它来访问 redis laravel session
- 然后我解密该 session ，这反过来让我可以访问用户 ID
它有效，但我觉得它可能是一个安全漏洞，因为我实际上并没有使用 _token 来验证来源。
最佳答案
我认为您的代码是正确的，也许是唯一的方法。 session_id 通常存储在 cookie 中，并且在某些时候必须发送到服务器。由于 node 和 php 是不同的语言，它们不能直接共享一个 session 。你总是需要像 redis、mysql 或文件系统这样的中间存储。当然还有一种检索 session 的方法。检索 session 的关键当然是 session_id。
关于保护 websockets 的有趣帖子:
https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html
他的建议是在您的 session 中添加一个随机生成的 key ，您可以在建立 websocket 连接时进行验证。
session_id 本身已经是随机的，但这些 session_id 通常是长期存在的，因此短期随机 id 可以提高安全性。 short-lived应该越短越好:让php把它加入到数据库中，一旦在node中验证了连接，就把它从数据库中移除，这样就不能再使用了。
还有很多额外的 session 验证技术，比如检查浏览器字符串，或者将 session 固定到一个 ip 地址:
http://phpsec.org/projects/guide/4.html
我不推荐这些类型的检查，因为它们并没有真正增加太多额外的安全性，只会让最终用户感到烦恼。
我认为最重要的是:
- 您使用安全的方式来传递 session_id 等。这意味着 HTTPS
- session 应在用户关闭浏览器时过期
- 如果用户从不同的位置连接，或者应该可以访问他的“登录日志”，则应该通知他
关于php - 如何与节点共享 Laravel session ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32538978/