Need to send "Origin" header when connecting from JavaScript to avoid CORS problems

[shaulbehr]

Hi,
My SignalR host is an Azure App Service. The CORS behavior seems to be different from other hosts, in that if you don't explicitly send an "Origin" header in the connection request, it does not respond with an "Access-Control-Allow-Origin" header, and the browser spits out a CORS error.
Is there some way to do this in the current release, or is that a new feature?

[HNeukermans]

I think you need to solve this issue, pure server side.
check my signalr backend. Also hosted on azure and it works. backend

this is key to get it working
appBuilder.SetDataProtectionProvider(new MachineKeyProtectionProvider());

[DaveMonag]

Can second that. Check out the CORS section here: https://docs.microsoft.com/en-us/aspnet/signalr/overview/guide-to-the-api/hubs-api-guide-javascript-client

[shaulbehr]

Thanks, will do.

[shaulbehr]

Hi,
Still banging my head on this, and no joy. Here's what I've done:

1. On Azure, set CORS to allow origin "*"
2. Copied your code from the backend demo project into my Startup class (see attached)
3. Added a section to web.config:

 <system.webServer>
   <httpProtocol>
     <customHeaders>
       <add name="Access-Control-Allow-Origin" value="*" />
       <add name="Access-Control-Allow-Methods" value="GET,PUT,POST,DELETE,OPTIONS" />
       <add name="web-config-was-read" value="true" />
     </customHeaders>
   </httpProtocol>
 </system.webServer>

4. In my Authentication provider, call SetCorsPolicy():

       private static void SetCorsPolicy(IOwinContext owinContext)
        {
            owinContext.Response.Headers.Add("Access-Control-Allow-Origin", new[] { "*" });
            owinContext.Response.Headers.Add("SetCorsPolicyCalled", new[] { "true" });
            owinContext.Response.Headers.AppendCommaSeparatedValues("Access-Control-Allow-Headers", "Authorization",
                "Content-Type", "Location", "Date", "loginOnly", "GoogleToken", "CleverToken", "EEToken", "LDAPToken",
                "ADToken", "ShardKey", "UserId", "StudentId", "TeacherId", "ClassId", "UserGroupId", "SchoolId",
                "UserGroupOrganizationId");
            owinContext.Response.Headers.AppendCommaSeparatedValues("Access-Control-Request-Headers", "Authorization",
                "Content-Type", "loginOnly", "GoogleToken", "CleverToken", "EEToken", "LDAPToken", "ADToken", "ShardKey",
                "UserId", "StudentId", "TeacherId", "ClassId", "UserGroupId", "SchoolId", "UserGroupOrganizationId");
            owinContext.Response.Headers.AppendCommaSeparatedValues("Access-Control-Expose-Headers", "Authorization",
                "Content-Type", "Location", "Date");
            owinContext.Response.Headers.AppendCommaSeparatedValues("Access-Control-Allow-Methods", "OPTIONS", "GET",
                "POST", "PUT", "DELETE");
            owinContext.Response.Headers.AppendCommaSeparatedValues("Access-Control-Request-Methods", "OPTIONS", "GET",
                "POST", "PUT", "DELETE");
        }

My connection to SignalR returns HTTP200 as before, but there is still no "Access-Control-Allow-Origin" header. I do, however, have "web-config-was-read" and "SetCorsPolicyCalled" headers, which shows that my code is, in fact, being called - but the "Access-Control-Allow-Origin" header is specifically being stripped out.

When I add an "Origin" header to my SignalR request, however, I do get back the "Access-Control-Allow-Origin" header.

What am I doing wrong?

And - as a shortcut - is it possible somehow to get the ng2-signalr library to send that "Origin" header?

App_Start.zip

[shaulbehr]

Incidentally, @HNeukermans , I added that line:

appBuilder.SetDataProtectionProvider(new MachineKeyProtectionProvider());

Made no difference.
I found someone else having a related issue here, which they resolved by removing the CORS configuration in Azure (my step 1 above), and I followed suit - also made no difference...

The only thing that seems to work is sending an "Origin" header in the request.

[shaulbehr]

Problem solved on the Azure side.

Still, according to what Petre Poposcu says there, the client should be sending an Origin header. You may still want to investigate why that header is not being sent.