Hello,
I’m reporting an issue about SignalR Core 3.1. I have developed my web app (ASP.NET CORE) and locally (Visual Studio) everything works. Then I’ve deployed the web app to IIS (latest version) and everything works, at least on my side.
A user reported me, instead, that when he tries to connect using his Chrome browser latest version (on Windows), the SignalR connection does not get established and instead he gets this error in the browser’s console:
Server returned handshake error: Handshake was canceled.
This issue seems very similar (if not the same) to issue #11089, but I don’t know how to solve it. I’m attaching the error from the user.
At first I was thinking it was a server issue, but for me it works and for other users too. Then that user told me he can make it work under Edge and under Chrome on Linux. The issue is only with his Chrome (version 83) on Windows.
I only have one server and no multiple app pools or multiple instances of an app pool. But it does not seem to be a server-side issue, I least I think.
What can we check?
Thanks!
There is a large gap between the negotiate returning and the http connection starting which you can see in the logs between «selecting transport» and «SSE connected to». This will causes issues with the server killing the connection because the client took too long to send the handshake.
Could you share the server logs with us so we can try to see whats going on?
I’m using latest IIS, how can I see server logs? I looked at the link you specified in issue #11089 however it speaks only about IIS Express in Visual Studio, not «real» IIS.
However, I think I’ve narrowed the problem: since I found on the Internet some issues regarding antivirus conflicts, I asked the user if he had antivirus: yes, he had Kaspersky, I told him to disable it and magically it worked. On the Internet I found similar issues with other antivirus (Bitdefender, AVG) and it seems quite a common issue. Why the antivirus may interfere with SignalR?
A side question: when I was looking to fix the problem server-side (but it turned out to be a client-side issue), I found an article saying that WebSockets are not enabled by default on IIS (https://docs.microsoft.com/en-us/iis/configuration/system.webserver/websocket) I checked my current IIS 10 setup and actually this feature is not enabled, but SignalR works anyway. So the question is: should I really enable WebSockets on my IIS server?
Thanks!
Just a clarification on my last question: actually I noted that, without WebSockets protocol enabled on my IIS, everything was still working with SSE protocol. I installed WebSockets support in IIS and it started using WebSockets protocol. So everything is fine.
The only question still open is: why the antivirus may interfere with SignalR?
Thanks.
We have no idea if your anitivirus can interfere with websockets. I’d recommend reaching out to your antivirus vendor.
msftbot
bot
locked as resolved and limited conversation to collaborators
Jul 5, 2020
Наш программист сделал сайт на базе движка Node.JS и на его локальном компьютере все работает замечательно — и при обращениях с локалхоста и при обращениях по сети. Размещаю это творение на наш сервер и ставлю весь список модулей которые он использует. Не работает…
Разбор полетов показал, что сценарий из файла socket.io.min.js вызывает с сервера 192.168.122.252:3000/socket.io/1/?t=1379433566379 На сервере это вызывает обработчик описанный в следующем блоке кода:
io.configure(function (){
io.set('authorization', function (handshakeData, callback) {
// некоторый код по анализу
});
});
после отработки сервер выдает в консоль сообщение: » warn — handshake error», а на клиент возвращает текст «handshake error». Ситуация повторяется стабильно при тесте из браузеров на самом сервере и из его сети.
Добавил от себя в процедуру авторизации сериализацию JSON параметра handshakeData и получил на сервере результат:
Coockie: {"headers":{"host":"192.168.122.252:3000","connection":"keep-alive","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8","user-agent":"Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36","accept-encoding":"gzip,deflate,sdch","accept-language":"ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4"},"address":{"address":"192.168.122.135","port":3146},"time":"Tue Sep 17 2013 19:16:16 GMT+0300 (EEST)","query":{"t":"1379433566379"},"url":"/socket.io/1/?t=1379433566379","xdomain":false,"issued":1379434576801}
А вот у разработчика на его рабочей машине в хидерах еще есть куки и потому содержимое обработчика авторизации успешно выполняется, варнинг не генерируется и веб-служба работает:
Coockie: {"headers":{"host":"localhost:3000","connection":"keep-alive","user-agent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36","accept":"*/*","referer":"http://localhost:3000/","accept-encoding":"gzip,deflate,sdch","accept-language":"en-US,en;q=0.8","cookie":"auth.sid=s%3APjHB8aINSzgpvDqgPLtcwkSp.VVyPsLtWzyJKzooaePC2Yg1WaISVp5ew6x1e88jGhLY"},"address":{"address":"127.0.0.1","port":44417},"time":"Tue Sep 17 2013 19:02:40 GMT+0300 (EEST)","query":{"t":"1379433760241"},"url":"/socket.io/1/?t=1379433760241","xdomain":false,"issued":1379433760263}
Что я уже второй день упускаю? Может нужны какие-то специфические настройки для Express?
When using Ingress in Kubernetes, the NGINX Ingress Controller presents a default options for many. When you application is using WebSocket and frameworks like SignalR, the NGINX should be adjusted for that use-case.
Feb 15, 2020
• 2 min read
When using Ingress in Kubernetes, the NGINX Ingress Controller presents a default options for many. When you application is using WebSocket and frameworks like SignalR, the NGINX should be adjusted for that use-case.
Scaling SignalR out to multiple instances
When running multiple instances of a SignalR server, you should make sure, they can all talk to and transfer state between each other. For that, you can back SignalR with a Redis Cache backplane.
Once that is done, you can scale out. Still, you want to ensure that an application holds a connection to the same instance, once established. For that, add the Session Affinity annotation to your Kubernetes Ingress.
nginx.ingress.kubernetes.io/affinity: cookieYou should also think about setting the Affinity Mode. By default, NGINX will re-distribute the load, if a deployment gets scaled up. When choosing persistent, NGINX will not rebalance sessions to new servers.
Troubleshooting
Some users run into these errors, when running a SignalR or similar WebSocket based application behind the NGINX Ingress Controller.
WebSocketTransport.js:86 WebSocket connection to 'wss://yourdomain.com/echo?id=_Zbe1Q5-pyRTFQiE3jWYHg' failed: Error during WebSocket handshake: Unexpected response code: 200
[2020-02-15T19:10:47.497Z] Error: Failed to start the transport 'WebSockets': Error: There was an error with the transport.
[2020-02-15T19:11:02.591Z] Error: Connection disconnected with error 'Error: Server returned handshake error: Handshake was canceled.'.That usually implies, that you are using the nginx/inginx-ingress Helm Chart for deploying NGINX Ingress into your cluster. Turns out, that this variant of NGINX causes trouble to some customers. The official Helm Chart, that should be used is stable/nginx-ingress.
If you still want to use NGINX version, that the nginx/inginx-ingress Helm Chart deploys, you need to enable WebSocket support for your Service. To load balance Web Sockets, we have to add the following annotation to the Ingress resource:
nginx.org/websocket-services: "service1[,service2,...]"The following example shows two load balances applications, one of which is using WebSockets:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-ingress
annotations:
nginx.org/websocket-services: "web-chat"
spec:
rules:
- host: app.yourdomain.com
http:
paths:
- backend:
serviceName: web-app
servicePort: 80
- host: chat.yourdomain.com
http:
paths:
- backend:
serviceName: web-chat
servicePort: 80
☝️ Advertisement Block: I will buy myself a pizza every time I make enough money with these ads to do so. So please feed a hungry developer and consider disabling your Ad Blocker.
Интернет сделал для нас удобным находить любую необходимую информацию. Вы можете посещать веб-сайты напрямую или использовать поисковую систему, например Google, для доступа к различным типам данных. Однако бывают случаи, когда мы не можем открывать веб-страницы, и этому может быть несколько причин. В некоторых случаях это может быть связано с вашим сетевым подключением. С другой стороны, еще одна распространенная проблема, которая вызывает эту проблему, — это сбой установления связи TLS.
Теперь вы можете спросить: «Что означает рукопожатие TLS?» TLS означает Transport Layer Security, протокол шифрования. Связь по этому протоколу остается конфиденциальной и безопасной. В этом посте мы собираемся объяснить, что происходит при рукопожатии TLS. Таким образом, вы лучше поймете концепцию. Более того, мы научим вас, как исправить ошибку сбоя установления связи TLS.
Как мы все знаем, когда есть форма переговоров или приветствия между двумя людьми, мы скрепляем это рукопожатием. Точно так же, когда два сервера обмениваются данными и подтверждают друг друга, они формируют рукопожатие TLS. Во время этого процесса серверы проходят проверку. Они устанавливают шифрование при обмене ключами. После подтверждения подлинности всех деталей начнется обмен данными. Вот четыре этапа рукопожатия TLS:
- Указывает версию TLS, которая будет использоваться для связи.
- Выбор алгоритма шифрования для связи.
- Открытый ключ и цифровая подпись эмитента сертификата SSL будут использоваться для проверки подлинности.
- Будут созданы сеансовые ключи, которые затем будут обмениваться между двумя серверами.
Чтобы упростить задачу, обе стороны сначала скажут «привет». Затем сервер предоставит сертификат, который клиент проверит. После того, как будет подтверждена подлинность сертификата, начнется сеанс. Перед этим будет создан ключ, который позволит обмениваться данными между серверами.
Как исправить проблемы с рукопожатием TLS
К сожалению, если проблема связана с сервером, вы ничего не можете сделать. Например, если сертификат с сервера не может быть аутентифицирован, тогда это уже не в ваших руках. Однако, если у вас возникли проблемы с браузером, который вы используете, вы все равно можете попробовать множество обходных путей. Кроме того, если вы имеете дело с несоответствием в протоколе TLS, вы можете исправить проблему в браузере.
Сбой рукопожатия TLS может быть по разным причинам. Прежде чем пытаться решить проблему, убедитесь, что вы действительно имеете дело с ошибкой рукопожатия TLS. В большинстве случаев можно соблюдать следующие правила:
- Попробуйте посетить другие сайты и посмотрите, сохраняется ли проблема.
- Если вы используете сеть Wi-Fi, попробуйте переключиться на проводную.
- Попробуйте другие сетевые подключения. Например, используйте другой маршрутизатор или переключитесь на общедоступную сеть.
После того, как вы установили причину проблемы, вы можете спросить: «Следует ли мне отключить квитирование TLS в моем браузере?» Мы понимаем ваше разочарование, но не рекомендуем этого делать. В конце концов, протокол TLS — один из лучших способов обеспечить безопасный просмотр. Действительно, вы можете продолжить просмотр веб-сайта даже с недействительным сертификатом. Однако вы никогда не должны совершать с ним какие-либо операции. Например, не отправляйте учетные данные пароля и не используйте свою кредитную карту.
С другой стороны, бывают случаи, когда сбой подтверждения TLS возникает из-за проблем с вашим браузером. В этом случае вы можете решить проблему, изменив некоторые настройки в вашем браузере. Ниже мы расскажем о некоторых из лучших обходных путей.
Решение 1. Обеспечение правильного системного времени
В большинстве случаев рукопожатие TLS не удается из-за неправильных настроек системного времени. Имейте в виду, что системное время является жизненно важным фактором при проверке того, действительно ли сертификат действителен или просрочен. Итак, если время на вашем ПК не совпадает со временем на сервере, то может показаться, что сертификаты больше не действительны. Поэтому мы рекомендуем вам установить системное время на «автоматическое». Вот шаги:
- На клавиатуре нажмите Windows Key + I. Откроется приложение «Настройки».
- В приложении «Настройки» выберите «Время и язык».
- Перейдите на правую панель и установите переключатель в разделе «Автоматически устанавливать время» в положение «Вкл.».
- Перезагрузите компьютер, затем попробуйте снова зайти на сайт, чтобы убедиться, что ошибка подтверждения TLS исчезла.
Решение 2. Изменение протокола TLS в Windows 10
Возможно, проблема связана с версией TLS, которую использует ваш браузер. Стоит отметить, что в Windows 10 и более ранних версиях операционной системы централизованы настройки протокола. Вы можете получить доступ к свойствам Интернета, чтобы переключиться на другую версию TLS. Для этого следуйте этим инструкциям:
- Запустите диалоговое окно «Выполнить», нажав клавиши Windows + R на клавиатуре.
- В диалоговом окне «Выполнить» введите «inetcpl.cpl» (без кавычек), затем нажмите «ОК».
- В окне свойств Интернета перейдите на вкладку «Дополнительно».
- Прокрутите вниз, пока не дойдете до раздела «Безопасность», где вы можете добавить или удалить протоколы TLS.
- Если веб-сайт, к которому вы пытаетесь получить доступ, требует TLS 1.2, вам необходимо его выбрать.
- Нажмите «Применить» и «ОК», чтобы сохранить внесенные изменения.
- После изменения версии TLS попробуйте снова получить доступ к тому же веб-сайту.
Когда дело доходит до протоколов TLS, IE, Chrome и Edge используют возможности Windows. Между тем Firefox управляет собственной базой данных сертификатов и протоколами TLS. Итак, если вы хотите изменить версию TLS в Firefox, выполните следующие действия:
- Запустите Firefox, затем введите «about: config» (без кавычек) в адресной строке.
- Нажмите Enter, затем щелкните поле поиска.
- Введите «TLS» (без кавычек), затем найдите security.tls.version.min.
- Вы можете изменить это на любое из следующего:
Установите TLS 1 и 1.1, введя 1 и 2.
Включите TLS 1.2, введя 3.
Установите максимальный протокол TLS 1.3, введя 4.
Решение 3. Удаление базы данных сертификатов или профиля браузера
Браузеры хранят базу данных сертификатов. Например, профили Firefox поддерживают файл cert8.db. Есть один способ узнать, что ошибка установления связи TLS связана с локальной базой данных сертификатов. Вы можете попробовать удалить файл cert8.db в Firefox. Если ошибка исчезает при перезагрузке компьютера и браузера, значит, вы определили причину.
Для Edge за обработку сертификатов отвечает диспетчер сертификатов. Вы можете удалить сертификаты, выполнив следующие действия:
- Откройте Edge, затем введите в адресной строке «edge: // settings / privacy» (без кавычек).
- Щелкните параметр «Управление сертификатами и настройками HTTPS / SSL», затем удалите сертификаты.
Если у вас возникли проблемы с поиском базы данных сертификатов, лучше всего удалить профиль браузера. Как только вы это сделаете, вы можете снова попытаться получить доступ к веб-сайту, чтобы узнать, исчезла ли ошибка TLS.
Решение 4. Сброс настроек браузера
Если ни одно из исправлений, которыми мы поделились, не может решить проблему TLS, то последнее средство — сбросить настройки браузера. Лучший способ сделать это — удалить и переустановить браузер. Как только вы это сделаете, вы можете снова попытаться получить доступ к веб-сайту, чтобы проверить, исчезла ли ошибка TLS.
В некоторых случаях время установления связи TLS истекает, и вы не можете посетить веб-сайт. Когда это происходит, вы, естественно, спросите: «Сколько времени занимает рукопожатие TLS?» Что ж, это займет несколько секунд. Если это занимает больше минуты или двух, возможно, у вас медленное сетевое соединение. С другой стороны, также возможно, что ваш браузер перегружен расширениями, надстройками и прочим мусором.
Когда это происходит, вы должны использовать надежный очиститель нежелательной почты с ПК, например Auslogics BoostSpeed. Вы можете использовать этот инструмент, чтобы легко избавиться от ненужных файлов браузера. Более того, BoostSpeed имеет функции, которые позволяют настраивать неоптимальные настройки браузера, обеспечивая плавную и быструю работу.
Какое из решений помогло вам решить проблему с подтверждением TLS?
Дайте нам знать в комментариях ниже!