认证/授权

WebSocket协议不处理授权或认证。实际上，这意味着auth之后的页面里打开的WebSocket不会“自动”接收任何类型的身份验证; 所以，我们需要采取措施来保护WebSocket连接。

这个验证可以通过多种方式完成。因为WebSockets需要使用通常用于身份验证的标准HTTP Header，这也就意味着我们可以使用与WebSocket建立连接时的身份验证机制。

由于我们无法通过JavaScript自定义WebSocket的Header，因此我们只能从浏览器发出“隐式”身份验证（即Basic或cookie）。此外，处理WebSockets的服务器与处理“正常”HTTP请求的服务器完全分开是很常见的，这可以使共享授权Header很困难或不可能。

所以，我们来看看一种似乎很好地解决了WebSocket身份验证问题的方案，这是一种基于“ticket”的身份验证系统。一般来说，它的工作原理是这样的：

当客户端代码决定打开WebSocket时，它会联系HTTP服务器以获取授权“ticket”。
服务器生成此ticket。它通常包含一些诸如用户/帐户ID、请求ticket的客户端的IP地址，时间戳以及其他任何可能需要的内部数据。
服务器存储此ticket（即在数据库或缓存中），并将其返回给客户端。
客户端打开WebSocket连接，并作为初始握手的一部分发送此“ticket”。
然后，服务器可以比较此ticket，检查源IP，验证ticket尚未重新使用且未过期，并执行任何其他类型的权限检查。如果一切顺利，则允许WebSocket连接。

Origin header

WebSocket标准定义了一个Origin Header域，用于Web浏览器设置发起WebSocket请求的URL。这可以用来区分来自不同主机的WebSocket连接，或者来自浏览器和某种其他类型的网络客户端的WebSocket连接。但是，请记住Origin头部基本上是建议性的：非浏览器客户端可以轻松地将Origin头部设置为任何值，从而“假装”成为浏览器。

我们可以将Origin header 与AJAX请求使用的X-Requested-With header 看成是大致类似的。 Web浏览器发送X-Requested-With：XMLHttpRequest的header，该header可用于区分浏览器和直接制作的AJAX请求。然而，这个头文件很容易被非浏览器客户端设置，因此不能被信任为认证来源。

同样的道理，我们可以将Origin header作为一种咨询机制: 帮助区分来自不同位置和主机的WebSocket请求，但不应将其作为身份验证来源。

原文地址: WebSocket Security