It seems like if you add an AuthorizeAttribute to your hub, this does not extend to the longpolling 'negotiate' call, so if your connection falls back to longPolling, SignalR does not properly reject the promise on the call to $.connection.hub.start.
It seems like the dynamic resources SignalR creates (handlers) should be in a context that receives the authorization treatment (unfortunately they are in /signalR/*, not specific to a hub).
Alternatively, since it does eventually fail (some point after the ping loop), this should reject the promise.
Steps to reproduce:
Respond with a 401 if the user is unauthorized AND unauthenticated
- Similar to 04fb595 in 2.0.0
Made auth work for hubs
- Made auth work for hubs when there's a challenge that happens after a
- Added connectionData (the list of hubs) to all urls including
negotiate send and abort.
added [Authorize] to HubConnectionAPI
navigated to http://localhost:40476/Hubs/HubConnectionAPI/Default.aspx?transport=longPolling
it raises OnError and triggers start.fail but showing full http response content explaining the 401 error