No 'Access-Control-Allow-Origin' header is present on the requested resource.

[dconger]

We are getting a "one-off" error every hundred or so requests to our api where the Access-Control-Allow-Origin header and other headers are not present on the resp_headers. You can see in the screenshots below that the "Working" request has all the appropriate Response Headers but the "Failed" request didn't add all of the Response Headers and thus, we get this error:

As far as how we're implementing CorsPlug, we simply have plug CORSPlug included at the top of our endpoint.ex file with no origin or any other options specified so it just falls back to the defaults.

I've looked through the cors_plug.ex source code and no clue why these headers wouldn't be added every hundred or so requests. Any thoughts as to what the issue might be?

Screenshots

Working:

Failed:

[avocade]

On second thought, breaking this out to a new issue.

But +1 for this as well.

[yordis]

@mschae is this still valid? I saw that you did some release 14 days ago so I am wondering if this is fix already

[rcoedo]

I'm having the same problem.

[mschae]

I have no leads here and issues recreating the issue.

We should no longer pass back an empty header as of the release recently (will verify).

Any way I can recreate this issue?

[rcoedo]

In my case I was having problems in an empty 1.3 phoenix application using the following configuration:

config :cors_plug,
  origin: ["http://localhost:3000", "http://localhost:3001"]

I had issues with cors_plug versions 1.4 and 1.3, and I was able to fix it by downgrading to 1.2.1

Sorry for the late response, I hope this helps! 😄

[rcoedo]

Oh, I forgot. with that configuration I had access from localhost:3000 but I could not reach the backend from localhost:3001. It may be a problem handling the url list.

[mschae]

@rcoedo can you please give me more info so I can reproduce?

• What did you expect to see?
• What did you see instead?

Please provide the headers you are seeing (/not seeing).

Thanks

[rcoedo]

I saw the exact same error shown in the first comment in the console, and Access-Control-Allow-Origin was set to null for localhost:3001, but it was correct for localhost:3000

I'm sorry that I can't give you more info to reproduce this, the project was just a toy project and I already deleted it.

[doomspork]

I just ran into this issue myself and am currently working through it to hopefully find a resolution. In my particular case the issue arose when we run both http and https.

[bjunc]

I am also receiving a null origin. This happens when I attempt any method for explicitly setting allowed origins. I've tried lists, regex, function, config, etc.. All result in null. Any thoughts? I'm using v1.5.

resp_headers: [
    {"cache-control", "max-age=0, private, must-revalidate"},
    {"vary", "Origin"},
    {"access-control-allow-origin", "null"},
    {"access-control-expose-headers", ""},
    {"access-control-allow-credentials", "true"},
    {"x-request-id", "saecnu6r28v1goopcu0g516bpf7po7vv"}
  ],

[mschae]

@bjunc Hard to tell from what information you're providing.

Can you provide your configuration and how you're testing it? A gist or example project would be ideal.

For everyone else who comments on here: If you are experiencing this issue please provide a gist or a sample project with instructions on how I can test this. I have currently no leads tracking this down. Thank you!

[bjunc]

My app is pretty complex at this point, so it's possible there is a config conflict. However, I can create the error pretty simply:

1. Add plug CORSPlug, origin: ["http://localhost:3000"] to endpoint.ex.
2. Navigate to a simple route (no pipeline, no guardian, etc.).
3. Inspect the response in Chrome dev tools
4. You should see access-control-allow-origin: null

If I remove the origin from the plug, then the response comes back with access-control-allow-origin: *.

It seems no matter what method I attempt to add an allowed origin, it always comes back as null. It does seem doable that I can manually set access-control-allow-origin using put_resp_header() at the end of a pipeline. However, this isn't ideal...

I'm using v1.5, with Phoenix 1.3.0.

[mschae]

@bjunc The origin is a domain name, not a URL. In your case it would have to be plug CORSPlug, origin: ["localhost"]

[yordis]

@mschae if that is the case, then that was the issue for me for sure ..... my fault!

[bjunc]

@mschae I ultimately ditched the origin logic, so I can't say what I had originally used. It's possible what I wrote into the issue comment was not accurate (using "http://localhost:3000" instead of just locahost). Either way, I appreciate you looking into it.

One thing worth noting though, is that the README shows with and without the scheme/protocol; which might be where some of the confusion here is coming from.

Also, it's probably worth noting in the README that null is returned when there is a mismatch between the request origin and the allowed origins. Maybe even a debug warning in the console would help.

[mschae]

Sorry you @yordis and @bjunc - nevermind, that was a wrong late-hour reply on my end.

Actually the origin is supposed to be a protocol, host, port triple. Looks like that's insufficiently covered by tests, I'll fix that.

That also means that if you want to allow the same origin on multiple ports, you have to specify each port from which you want to allow tests. So if your front-end is running on a different port than your back-end, you'll have to specify the front-ends port, not the back-ends. Hope that makes sense.

[mschae]

I've updated tests and the README accordingly and added the note as suggested by @bjunc.