WebAPI 上的 C# SignalR 拒绝 CORS

Question

I have a C# RestAPI, to which I've just added some websockets functionality using the SignalR library.

This is separate to the Web Front End, also C#.

The Web Front End uses Javascript to make a SignalR connection to the RestAPI, sample code below.

In testing, when the Web Front End and the RestAPI are both on LocalHost, this works fine (even though the paths are different, WFE is on 'localhost/wfe' and RestAPI is on 'localhost/restapi'). The SignalR connection works, and does everything it's supposed to.

However, when I publish them to our test server, the paths are completely different (WFE is on 'our.test.server.com/Test', and RestAPI is on 'localhost:89/Test' on the same server).

Everything else works fine (this WFE and RestAPI have been in use live for about 10 years now, always on separate servers), but the SignalR connection no longer works.

Looking at the Web Browser console, I see the following:-

SignalR: Auto detected cross domain url.
SignalR: Negotiating with 'http://localhost:89/Test/socket/negotiate?clientProtocol=2.1&type=requestfile&userid=df4e6ce5-a666-42e5-8c0c-57c9f6f76a0e&documentid=b87c430a-03d8-47ba-bd5e-5913f895d0a6'.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:89/Test/socket/negotiate?clientProtocol=2.1…umentid=b87c430a-03d8-47ba-bd5e-5913f895d0a6&_=1571222295312. (Reason: CORS request did not succeed).
SignalR: Stopping connection.

The original code, which works fine if everything on the same server, is:-

RestAPI:

public partial class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.MapSignalR<WebPortalConnection>("/socket");
    }
}

public class WebPortalConnection : PersistentConnection
{
    // Methods here
}

WFE (Javascript):

var socketPath = 'Value passed from config file, e.g. http://localhost:89/Test/';

var requestFile = $.connection(socketPath + "socket", "type=requestfile&userid=" + currentUserID + "&documentid=" + documentID, true);

requestFile.received(function (data) {
    // Do Stuff Here
});

In attempting to get CORS working, I have tried all the following suggestions (from here, Microsoft, and other sites), none of which worked:-

1) Installed the nuGet package "Microsoft.AspNet.WebApi.Cors"

Added all the configuration bits, and a decorator on the WebPortalConnection class to allow CORS

Nope, so uninstalled that one again.

2) Installed the nuGet package "Microsoft.Owin.Cors"

Updated the Startup class with various different combinations of things suggested:-

public partial class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.MapSignalR<WebPortalConnection>("/socket");
        app.UseCors(CorsOptions.AllowAll);
    }
}

Nope

public partial class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.UseCors(CorsOptions.AllowAll);
        app.MapSignalR<WebPortalConnection>("/socket");
    }
}

Nope

public partial class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.Map("/socket", map =>
        {
            map.UseCors(CorsOptions.AllowAll);
            var hubConfiguration = new HubConfiguration { };
            map.RunSignalR(hubConfiguration);
        });
    }
}

This stopped it working entirely, even on localhost

public partial class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.UseCors(builder =>
        {
            builder.WithOrigins("https://example.com")
                .AllowAnyHeader()
                .WithMethods("GET", "POST")
                .AllowCredentials();
        });
    }
}

This wouldn't even compile, error "Cannot convert lambda expression type 'CorsOptions' because it is not a delegate type'.

Kitchen sink:

public partial class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.MapSignalR<WebPortalConnection>("/socket");
        app.UseCors(CorsOptions.AllowAll);
        app.Map("/socket", map =>
        {
            map.UseCors(CorsOptions.AllowAll);
            var hubConfiguration = new HubConfiguration { };
            map.RunSignalR(hubConfiguration);
        });
    }
}

Nope

3) Allow CORS in the RestAPI web.config

<httpProtocol>
  <customHeaders>
    <clear />
    <add name="Access-Control-Allow-Origin" value="*" />
    <add name="Access-Control-Allow-Methods" value="*" />
    <add name="Access-Control-Allow-Credentials" value="true" />
  </customHeaders>
</httpProtocol>

Nope.

Always get the same response (on those that didn't break everything):-

SignalR: Auto detected cross domain url.
SignalR: Negotiating with 'http://localhost:89/Test/socket/negotiate?clientProtocol=2.1&type=requestfile&userid=df4e6ce5-a666-42e5-8c0c-57c9f6f76a0e&documentid=b87c430a-03d8-47ba-bd5e-5913f895d0a6'.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:89/Test/socket/negotiate?clientProtocol=2.1…umentid=b87c430a-03d8-47ba-bd5e-5913f895d0a6&_=1571222295312. (Reason: CORS request did not succeed).
SignalR: Stopping connection.

The SignalR package I'm using is: Microsoft.AspNet.SignalR.Core v2.4.1

The CORS package I'm using is: Microsoft.Owin.Cors v4.0.1

Everything was originally using HTTPS, I've changed the Test system over to HTTP for both the WFE and RestAPI just in case it was the fact that we don't have proper certificates for HTTPS, still doesn't work.

I've used the exact same SignalR package and code on other projects, none of which required cross-origin, and never had a problem with it on those, and as I said it works quite happily in this one if everything's on the same URL. Unfortunately, in this case they have to be separate.

Everything else works if they're separate (and has for years), it's just SignalR that's not.

Edit: Answers to questions

sideshowbarker: What's the HTTP status code of the response? You can use the Network pane in browser devtools to check. Is it 4xx or 5xx error rather than a 200 OK success response?

When everything is on localhost and it works, I get the following network responses in regards to the SignalR request:-

200 GET localhost   negotiate?clientProtocol=2.1&<my passed parameters>
101 GET localhost   connect?transport=webSockets&clientProtocol=2.1&<my passed parameters>&connectionToken=<token>&tid=4
200 GET localhost   start?transport=webSockets&clientProtocol=2.1&<my passed parameters>&connectionToken=<token>&_=1571231671489
200 GET localhost   negotiate?clientProtocol=2.1&<my passed parameters>&_=1571231671490
101 GET localhost   connect?transport=webSockets&clientProtocol=2.1&<my passed parameters>&connectionToken=<token>&tid=6
200 GET localhost   start?transport=webSockets&clientProtocol=2.1&<my passed parameters>&connectionToken=<token>&_=1571231671491

When the WFE and RestAPI are in separate places and I get the CORS failure, I only get the following network response in regards to the SignalR request:-

<nothing> GET localhost:89 negotiate?clientProtocol=2.1&<my passed parameters>&_=1571231504762

By nothing, I mean there is no response code, presumably because SignalR didn't actually respond.

strickt01: You state that "WFE is on our.test.server.com/Test, and RestAPI is on localhost:89/Test on the same server" - so is the Rest API on the same server as the WFE or is it on your local computer? If it's on the same server as you state here then the URL for the SignalR hub would surely be our.test.server.com:89/Test

Sorry, I wasn't very clear there.

Both are on the same server (our test server), so both can indeed by accessed by http://our.test.server.com ...

However, I specifically need to test when the Web Front End and the RestAPI are on different servers (which they are when Live on our clients' systems).

So, in the config file, I specified the URL for the RestAPI as ' http://localhost:89/Test ' rather than ' http://our.test.server.com:89/Test '

Aaaand typing up this reply has just made me realise what the problem is, THANK YOU: :)

Up until now, the WFE has only ever spoken to the RestAPI directly, and so ' http://localhost:89/Test ' refers to the local host for our test server that the WFE is on, and so that works.

But of course like an idiot I'm passing the same value to the browser now for the SignalR connection to use, so it's looking at my localhost.

Changed the value in the config file to ' http://our.test.server.othername.com:89/Test ', different URL pointing to the same place, and now it all works!

Big thanks, strickt01 : :)

Edit #2: Another question

fran: but you are still going to have a problem in your production environment because you will have 2 different origins. are you using some sort of authentication in your wfe? I suspect you don't have any problem making calls currently because you wfe is calling into controllers running under the same origin, then your wfe controllers are the ones that are making the calls to the web service. In this case you don't have a CORS issue because it's server to server communication

I'm using two different origins now.

The WFE is on http://our.test.server.com/Test

The RestAPI is on http://our.test.server.othername.com:89/Test

Different URLs and different ports, both of which should throw a CORS error.

Internally within the test server, the WFE is calling the RestAPI from http://our.test.server.com/Test to http://our.test.server.othername.com:89/Test . They are on the same server, but they don't actually know that.

From the User perspective, in my browser I log on to http://our.test.server.com/Test . That's the origin as far as the browser is concerned.

When I make a SignalR call, that connects to http://our.test.server.othername.com:89/Test because that's the URL in the config file, which is passed as the URL to connect to.

SignalR does treat this as a cross domain connection, I get the following in the Console output:-

SignalR: Auto detected cross domain url.
SignalR: Negotiating with 'http://our.test.server.othername.com:89/Test/socket/negotiate?clientProtocol=2.1&t<my passed parameters>'.
SignalR: webSockets transport starting.
SignalR: Connecting to websocket endpoint 'ws://our.test.server.othername.com:89/Test/socket/connect?transport=webSockets&clientProtocol=2.1&t<my passed parameters>&connectionToken=<token>&tid=0'.
SignalR: Websocket opened.
SignalR: webSockets transport connected. Initiating start request.
SignalR: The start request succeeded. Transitioning to the connected state.
SignalR: Now monitoring keep alive with a warning timeout of 13333.333333333332, keep alive timeout of 20000 and disconnecting timeout of 30000.

Just to be sure, I removed the line app.UseCors(CorsOptions.AllowAll);from the Startup class and tried again.

This time it failed with a CORS error:-

SignalR: Auto detected cross domain url.
SignalR: Negotiating with 'http://our.test.server.othername.com:89/Test/socket/negotiate?clientProtocol=2.1&<my passed parameters>'.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://our.test.server.othername.com:89/Test/socket/negotiate?clientProtocol=2.1&<my passed parameters>&_=1571242017811. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
SignalR: Stopping connection.

So, definitely testing with cross origin, and definitely working!

Thanks for making me double-check though, always worth doing: :)

Answer 1

Solved, thanks to strickt01!

As I stated in the edit where I answered the questions, it was me being an idiot and using 'localhost' to refer to two entirely separate places.

Specifying an actual site name (different to the main site, but pointing to the same place) fixed the issue.

Just for completeness, the working code is...

RestAPI:

public partial class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.UseCors(CorsOptions.AllowAll);
        app.MapSignalR<WebPortalConnection>("/socket");
    }
}

public class WebPortalConnection : PersistentConnection
{
    // Methods here
}

WFE (Javascript):

var socketPath = 'Value passed from config file, e.g. http://our.test.server.othername.com:89/Test/';

var requestFile = $.connection(socketPath + "socket", "type=requestfile&userid=" + currentUserID + "&documentid=" + documentID, true);

requestFile.received(function (data) {
    // Do Stuff Here
});