J'ai récemment effectué un interrupteur dans notre environnement de test à partir d'une fenêtre Azure App Services Windows à Linux. Tout fonctionne car il était auparavant sauf nos connexions de socket. Il semble y avoir beaucoup d'informations obsolètes concernant le service d'applications Linux et la documentation est DakeLuster. Cependant, selon Ces notes de version , support est disponible pour Sockets Web sur Azure App Service Linux.
dans certains des Service Azure App pour la documentation Linux , il stipule que vous devez désactiver permessagedeflate code> afin d'obtenir des sockets Web pour travailler avec Linux App Service et Nodejs. Je crois que je l'ai fait dans mon code serveur Hapijs ci-dessous. J'ai vérifié avec un console.log (io) code> que le paramètre permessagedeflate code> semble être réglé sur false correctement. P> const client = new io(URL, {
query: 'token=' + jwt,
perMessageDeflate: false,
transports: ['websocket'],
upgrade: false
});
3 Réponses :
Faites que vos webockets fonctionnent si l'authentification est désactivée?
Je n'ai que des problèmes avec WebSockets à l'aide des applications Linux lorsque je active les fonctionnalités d'authentification.
Je pense que cela est dû à une mauvaise mise en œuvre du proxy EasyAuth, et qu'il est considéré comme un problème difficile pour la MS de corriger.
Désactiver Cors et Auth à travers le Portal sur le service d'applications Linux.
Désactivez Cors en allant à votre service d'applications, sélectionnez Cors dans la barre de menus latéral de gauche sous API, supprimez toutes les entrées de connexion. En supprimant toutes les entrées, vous désactivez la mise en œuvre de Cors de Azure pour le service App.
Désactiver l'authentification en allant à l'authentification / Autorisation sous les réglages en direction de la barre de menus côté gauche. Cliquez sur le commutateur sur 'OFF'.
Cela permettra aux sockets Web de fonctionner comme prévu avec Linux App Service. Cependant, vous devez configurer Cors et authentifier avec votre cadre de serveur Web maintenant.
Après avoir entendu parler de mon représentant de support MS, elle a confirmé que lorsque Cors ou Auth est activé, il casse la mise en œuvre des sockets de Linux App Service. Les fonctionnalités de Cors et d'authentification de Linux App Service ne sont pas encore implémentées par Microsoft.
Pour utiliser le service d'applications Linux et utiliser les fonctionnalités CORS ou AUTH, vous ne pouvez tout simplement pas car ce n'est pas implémenté. La solution officielle recommandée consiste à basculer vers Windows App Service.
malgré ce que la documentation azur indique, Si vous supprimez toutes les entrées, vous devez avoir des sockets Web fonctionnant sans Cors. Cependant, gardez à l'esprit, vous devez configurer Cors avec votre cadre de serveur Web pour des raisons de sécurité. Si c'est exprès avec socket.io, vous devrez faire quelque chose comme Ceci . La plupart des cadres Web suivent un paradigme similaire en la spécifiant sur votre objet serveur en option.
Il y a encore plus d'informations sur cela dans Ce fil sur github. permessageageageflate n'est pas requis pour que WebSockets fonctionne avec Socket.IO. Je travaille sans elle correctement. Pour configurer Cors pour le service App du portail, c'est la même chose que vous le feriez pour Windows. Vous pouvez accéder à votre service d'applications dans le portail, sélectionnez Cors dans le menu côté gauche sous API. Supprimez toutes les entrées de là pour désactiver la fonctionnalité CORS de l'App Service. Je n'avais qu'une seule entrée ( * ) que j'utilisais pendant les tests car j'avais Cors configuré correctement avec mon service d'application Windows avant de passer à Linux.
Malgré ce que la documentation Azure indique, permessagegedeflate n'est pas nécessaire [...] la documentation indique maintenant qu'il est requis: docs.microsoft.com/en-us/azure/app-service/...
J'ai eu des problèmes similaires sur le nœud. Socket.io a échoué sur App Services exécutés sur Linux sur un domaine Azure CDN Hébergé. A été capable d'atténuer cela en utilisant les paramètres de domaine personnalisé et de TLS / SSL pour lier mon domaine à l'URL du service app au lieu de configurer un CDN Azure sur le service App.