Socket.io/Hapi 不工作 Azure 应用服务 (Linux)答案

【问题标题】：Socket.io/Hapi Not Working Azure App Service (Linux)Socket.io/Hapi 不工作 Azure 应用服务 (Linux)
【发布时间】：2020-01-31 01:49:42
【问题描述】：

我最近在我们的测试环境中从 Azure 应用服务 Windows 切换到了 Linux。除了我们的套接字连接之外，一切都像以前一样工作。似乎有很多关于 Linux App Service 的过时信息，文档也乏善可陈。但是，根据these release notes 的说法，Azure App Service Linux 上的 Web 套接字支持。

在某些Azure App Service for Linux documentation 中，它声明您必须禁用perMessageDeflate 才能使Web Sockets 与Linux App Service 和NodeJS 一起使用。我相信我已经在下面的 HapiJS 服务器代码中做到了这一点。我用console.log(io) 验证了设置perMessageDeflate 似乎正确设置为false。

import Server from 'socket.io';
import socketioJwt from 'socketio-jwt';

const myHapiJSPlugin = {
  name: 'myPluginName',
  version: '2.0.0',
  register: function (server, options) {

    const io = new Server(server.listener, {
      perMessageDeflate: false,
      transports: ['websocket'],
      origins: '*:*'
    });

    io.use(socketioJwt.authorize({
      secret: JWT_SECRET_KEY,
      handshake: true
    }));

    io.on('connection', socket => {
      console.log(io);
      // more code here
    };
  };
};

当我在使用网络客户端时打开 Chrome 控制台的网络页面时，我从服务器收到 101 响应代码。我console.log 从 socket.io 的客户端回调中连接/断开连接。尽管得到了服务器的确认（101 响应），但我可以看到它不断地连接/断开连接。连接状态在控制台中显示“已停止”。当回调触发时，我似乎订阅了一个特定的路由。

尽管在下面的配置中添加了perMessageDeflate 和origins 用于测试socket.io docs，但自从从Azure App Services Windows 切换后，我没有进行任何其他代码更改。我认为在握手或身份验证过程中出了点问题。

Status Code: 101 Switching Protocols
Access-Control-Allow-Origin: *
Connection: Upgrade
Date: Tue, 01 Oct 2019 18:04:57 GMT
Sec-WebSocket-Accept: <HASH>
Server: Kestrel
Upgrade: websocket

我还在客户端代码中添加了perMessageDeflate。没什么区别。

const client = new io(URL, {
  query: 'token=' + jwt,
  perMessageDeflate: false,
  transports: ['websocket'],
  upgrade: false
});

我还缺少什么？如何在 Azure 应用服务 Linux 上启用 Web 套接字？我检查了类似 Windows 的配置设置。似乎没有设置 - 因为默认情况下似乎启用了 Web 套接字。我已经在日志中验证了 Web 服务器不会不断重新启动导致连接/断开连接。

【问题讨论】：

标签： node.js azure socket.io azure-web-app-service hapi

【解决方案1】：

如果身份验证关闭，您的 WebSockets 还能工作吗？

我只在启用身份验证功能时遇到使用 Linux 应用程序的 WebSocket 问题。

我认为这是由于 EasyAuth 代理的实施不善造成的，并且它被认为是 MS 难以解决的问题。

【讨论】：

【解决方案2】：

tl;博士

通过 Linux 应用服务上的门户禁用 CORS 和 AUTH。

通过转到您的应用服务禁用 CORS，在 API 下的左侧菜单栏中选择 CORS，删除其中的所有条目。通过删除所有条目，您将禁用 Azure 的应用服务 CORS 实现。

通过转到左侧菜单栏上设置标题下的身份验证/授权来禁用身份验证。单击开关以“关闭”。

这将允许 Web 套接字按预期与 Linux 应用服务一起工作。但是，您现在需要使用 Web 服务器框架配置 CORS 和 AUTH。

长格式

在收到我的 MS 支持代表的回复后，她确认启用 CORS 或 AUTH 会破坏 Linux 应用服务的套接字实现。 Microsoft 尚未实现 Linux 应用服务 CORS 和 AUTH 功能。

为了使用 Linux 应用服务并利用 CORS 或 AUTH 功能，您根本不能，因为它没有实现。官方推荐的解决方案是切换到Windows App Service。

尽管 Azure 文档指出，perMessageDeflate 不是 WebSockets 与 socket.io 一起工作所必需的。如果没有它，我可以正常工作。要从门户为应用服务配置 CORS，与为 Windows 配置的相同。您可以在门户中转到您的应用服务，在 API 下的左侧菜单中选择 CORS。删除其中的所有条目以禁用应用服务的 CORS 功能。我在测试期间只使用了一个条目 (*)，因为在切换到 Linux 之前，我已经使用我的 Windows 应用服务正确配置了 CORS。

如果您删除所有条目，您应该有没有 CORS 的正常运行的 Web 套接字。但是，请记住，出于安全原因，您应该使用 Web 服务器框架配置 CORS。如果它是通过 socket.io 表达的，你将不得不做类似this 的事情。大多数 Web 框架都遵循类似的范例，将其作为选项指定在您的服务器对象上。

在 GitHub 上的 this thread 中有更多相关信息。

【讨论】：

Despite what the Azure documentation states, perMessageDeflate is not required [...] 文档现在说它是必需的：docs.microsoft.com/en-us/azure/app-service/…

【解决方案3】：

我在 Node.js 上遇到过类似的问题。 socket.io 在 azure cdn 托管域上的 Linux 上运行的应用程序服务失败。能够通过使用自定义域和 TLS/SSL 设置将我的域链接到应用服务 url 而不是在应用服务上设置 azure cdn 来缓解这种情况。

【讨论】：