CLI CORS Proxy not changing origin, still get 403 on API reqs?

Question

Yes, I've found a ton of stuff similar but still not resolved for my instance. I would like to avoid killing the browser side security and instead let the proxy do its job but I fear I'm missing some inane detail in the setup and I'm no CORS expert by any means.

So, what I get...a 403;

Failed to load http://localhost:10000/some/rest/endpoint: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4200' is therefore not allowed access.

Wherein localhost:10000 is my api url, and :4200 is the default Angular CLI instance.

So I config a proxy as I'd expect to as such in the angular.json;

"serve": {
          "builder": "@angular-devkit/build-angular:dev-server",
          "options": {
            "browserTarget": "angular-proj:build",
            "proxyConfig": "./proxy.conf.json"
          },

and add a proxy.conf.json;

{
    "/some/rest/*": {
      "target": "http://localhost:10000",
      "secure": false,
      "changeOrigin": true,
      "logLevel": "debug"
    }
  }

I serve it up and even flag the proxy.conf which the CLI serve confirms;

[HPM] Proxy created: /some/rest -> http://localhost:10000 etc...

....except I still get the 403, and still see in the Request* headers;

Host: localhost:10000
Origin: http://localhost:4200

So my question is, what inane detail am I missing here? I don't want to asterisk out the requests on all origins, and I don't want to shut off the browser checks, I would much prefer to have this nicely bundled up in the serve config like I'm doing so another pair of eyes are more than welcome. Cheers

ADDENDUM: My GET's seem to go through fine however something like a Access-Control-Request-Method: POSTshows as Request Method: OPTIONS and that's where I get my 403...why would a POST become an OPTIONS??

ADDENDUM #2: Worth mentioning, I get this issue in Chrome / Firefox but everything is kosher in Edge???

ADDENDUM #3: This is running serve as --aot=true with proxy.

Your browser is automatically on its own sending a CORS preflight OPTIONS request before even trying the POST request from your code. That’s how CORS works. And the server the browser is sending that OPTIONS request to is responding to the OPTIONS request with a 403. The server needs to instead respond to that OPTIONS request with a 200 OK and the required Access-Control-* response headers — sideshowbarker, Sep 05 '18 at 02:05
@sideshowbarker Ya that's the part I'm apparently stuck on, I have a specific condition for when the request is `OPTIONS` to declare it in the 'Access-Control-Allow-Methods' and I have `Origin` in the `Access-Control-Allow-Headers`, was there some other Access-Control-Allow-* flow I'm missing? I'm not entirely new to CORS, but this instance seems to be throwing me a fool stick. :D — Chris W., Sep 05 '18 at 14:11
Also might check the 2nd addendum about the Chrome vs FF vs Edge nuances, everything is fine in Edge (for once...) — Chris W., Sep 05 '18 at 14:32
If you are trying to get around CORS by setting up a proxy(?), then you would still need to change the URL you make your request to from the client side. — misorude, Sep 05 '18 at 14:42
@misorude Excuse the ignorance, but isn't that the point of the proxy? — Chris W., Sep 05 '18 at 14:56
Yes, but I couldn’t infer from your problem description, whether you actually did that. (“and still see in the Request* headers; `Host: localhost:10000`” makes it sound rather like you didn’t.) — misorude, Sep 05 '18 at 14:59
@misorude I guess that's where I'm confused, as the setup is the same and everything works fine in IEdge. It would make sense between origin and host but if only difference in origin is port number I could also understand why it would be allowed. Guess I have more digging to do. — Chris W., Sep 05 '18 at 15:04
Different port means different origin. Origin is the combination of protocol, host name _and_ port. _“and everything works fine in IEdge”_ - history teaches that that must not mean much ... — misorude, Sep 05 '18 at 15:07

Guerric P · Answer 1 · 2018-09-12T15:36:18.213

5

The following headers are wrong and this is why your browser still triggers the "same Origin policy" handshake:

Host: localhost:10000
Origin: http://localhost:4200

They should be:

Host: localhost:4200
Origin: http://localhost:4200

I strongly believe you didn't change your requests from http://localhost:10000/* to http://localhost:4200/some/rest/* and that the "ton of stuff similar" didn't include this: Angular2 CORS issue on localhost

edited Sep 12 '18 at 15:36

answered Sep 12 '18 at 15:09

Guerric P

30,447
6
48
86

Thanks for the time but figured it out there was a hidden conditional in a chained config on the server side (aspnet api v1) for OPTIONS looking for Authority that's not present on say a fresh first-time instance. Tried to del the question but unable due to the bounty. – Chris W. Sep 12 '18 at 18:34
Ya the proxy is to change origin to :1000 it was fine. – Chris W. Sep 12 '18 at 18:37
@ChrisW. I really don't get how it works then. You must have disabled something related to CORS on server side – Guerric P Sep 12 '18 at 19:18

score 3 · Accepted Answer · answered Sep 12 '18 at 18:36

Issue was unique found by digging more. Figured out there was a hidden conditional in a chained config on the server side (aspnet api v1) for OPTIONS looking for UrlReferrer.Authority that's not present on say a fresh first-time instance.

Pulled it out, changed Access-Control-Allow-Origin accordingly, and off to the races.

Cheers

CLI CORS Proxy not changing origin, still get 403 on API reqs?

2 Answers2

Linked