Sorry if service bus isn't the right forum - I don't see anything that matches better.
We have some users that are unable to negotiate a connection. The connection is immediately closed with
POST https://[prefix].service.signalr.net/client/negotiate?hub=[hub]&asrs.op=%2F[hub] net::ERR_CONNECTION_CLOSED
On most machines, we get a trace similar to:
Information: Normalizing '/[hub]' to 'https://[prefix].azurewebsites.net/[hub]'.
Utils.ts:177 Debug: Starting HubConnection.
Utils.ts:177 Debug: Starting connection with transfer format 'Text'.
Utils.ts:177 Debug: Sending negotiation request: https://[azurewebsitesHubUrl]/negotiate
WebExtension::executeScript: content script injected
**It gets rerouted to the signalr endpoint**
Utils.ts:177 Debug: Sending negotiation request: https://[prefix].service.signalr.net/client/negotiate?hub=[hub]&asrs.op=%2F[hub]
Utils.ts:177 Debug: Selecting transport 'WebSockets'
Utils.ts:177 Trace: (WebSockets transport) Connecting
Utils.ts:173 Information: WebSocket connected to wss://[prefix].service.signalr.net/client/?hub=[hub]&asrs.op=%2F[hub]&id=[id]&access_token=[access_token]
Utils.ts:177 Debug: Sending handshake request.
Utils.ts:177 Trace: (WebSockets transport) sending data. String data of length 32.
Utils.ts:173 Information: Using HubProtocol 'json'.
Utils.ts:177 Trace: (WebSockets transport) sending data. String data of length 61.
Utils.ts:177 Trace: (WebSockets transport) data received. String data of length 3.
Utils.ts:177 Debug: Server handshake complete.
Users are in the same groups, with the same whitelists/blacklists, and same permissions.
I have checked that 3rd party cookies are enabled in the browser (I saw an article that recommended this).
I'm not really sure what else to check here to get this working universally.
Issue is profile specific. If I log in on their machines, handshake completes successfully. If they log in on mine, it fails.
Edit 2:
It's something in Azure. I think we'll be able to figure it out by comparing accounts. If I log in to Azure with my credentials, on one of the "broken" people's windows sessions, it works - so Azure is forcefully closing the connection. It's nothing to do with Chrome, or their Windows settings. We'll be able to get to the bottom of it. Thanks all.
Thanks.