16

I'm working on selenium tests (written in C# using the chrome webdriver) for a javascript web app that uses a backend server running on WebApi 5.2.4. It is CORS enabled with very permissive settingss:

namespace SealingService
{
    public static class WebApiConfig
    {
        public static void Register(HttpConfiguration config)
        {
            // Web API configuration and services

            var cors = new EnableCorsAttribute("*", "*", "*");
            config.EnableCors(cors);

            // etc...
        }
    }
}

Normally everything works as expected. But on some machines when the server is started by the test scripts the client encounters CORS errors on every request. The chrome dev console shows the standard Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. message. The server logs show that the OPTION requests are reaching it, and it's sending a response.

When I try to access any of the API routes manually, the server returns the generic ASP.NET 404 page. This makes me think that our CORS configuration actually could be working correctly, but the server is not being started/configured correctly by our test script, so the routes are not being registered. Thus, all API routes are returning the 404 page, which is obviously not CORS enabled.

This is the applicationhost.config used by IIS during the tests. This is how the server is started by the test script:

public static Process StartIIS(string siteName)
{
    return Process.Start(@"C:\Program Files (x86)\IIS Express\iisexpress.exe", $"/site:{siteName} /config:{_applicationHostConfigFilePath}");
}

The errors only occur on some machines, and we can't figure out what is configured differently between them. I've tried using Chrome's --disable-web-security flag but it doesn't seem to make any difference.

David Reed
  • 226
  • 1
  • 6
  • Have you tried this extension (https://chrome.google.com/webstore/detail/allow-control-allow-origi/nlfbmbojpeacfghkpbjhddihlkkiljbi?utm_source=chrome-app-launcher-info-dialog)? I took it from (https://stackoverflow.com/questions/35588699/response-to-preflight-request-doesnt-pass-access-control-check) – Shlomi Bazel Sep 17 '18 at 13:00
  • 1
    I haven't tried that specific extension, but according to its description it does the same thing as the `--disable-web-security` flag which I have tried. At this point I'm pretty sure the error is not actually related to CORS but is something wrong with how IIS is being configured (see the config file in the original question) – David Reed Sep 18 '18 at 17:27
  • what is your header response – Rohit Dhiman Sep 20 '18 at 11:59

2 Answers2

1

You can usually solve pre-flight errors with a change to your web.config:

<system.webServer>

    ...

<httpProtocol>
    <customHeaders>
        <add name="Access-Control-Allow-Origin" value="*" />
        <add name="Access-Control-Allow-Headers" value="Origin, X-Requested-With, Content-Type, Accept, Cache-Control" />
        <add name="Access-Control-Allow-Credentials" value="true" />
        <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
    </customHeaders>
</httpProtocol>
</system.webServer>

Or via code in a custom handler with something like:

if (request.Headers.Contains("Origin") && request.Method.Method == "OPTIONS")
{
    var response = new HttpResponseMessage();
    response.StatusCode = HttpStatusCode.OK;
    response.Headers.Add("Access-Control-Allow-Origin", "*");
    response.Headers.Add("Access-Control-Allow-Headers", "Origin, Content-Type, Accept, Authorization");       
    response.Headers.Add("Access-Control-Allow-Methods", "DELETE, POST, PUT, OPTIONS, GET");
}

If it works you can then try refining things by e.g. changing Access-Control-Allow-Origin to just your front-ends address.

Ben Hall
  • 1,001
  • 7
  • 15
  • 1
    Thanks for the suggestion, but updating web.config with additional CORS configuration doesn't seem to solve the problem. I'm thinking that the problem is not with CORS settings, but lies somewhere in the way our test script is starting or configuring the routes in IIS. I updated the question with more details. – David Reed Aug 01 '18 at 16:15
  • add this to the web.config AND applicationhost.config. you'll find it easier to troubleshoot if you use IIS and not IIS Express. Also try "*" for the settings. – smoore4 Sep 20 '18 at 14:28
0

Assuming you are using windows OS. If yes then, did you allow your application to bypass windows firewall..? ex: if you have a application running on localhost:9000, then you need to make sure windows firewall has rules to allow port 9000.

Hope, this resolves your issue.

Kiran Dudyala
  • 11