admin管理员组

文章数量:1323330

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 wele. 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 bee 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.

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 wele. 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 bee 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.

Share edited Sep 30, 2021 at 10:26 Guerric P 31.8k6 gold badges58 silver badges105 bronze badges asked Sep 4, 2018 at 18:26 Chris W.Chris W. 23.3k4 gold badges63 silver badges98 bronze badges 9
  • 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 Commented Sep 5, 2018 at 2: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. Commented Sep 5, 2018 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. Commented Sep 5, 2018 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 Commented Sep 5, 2018 at 14:42
  • @misorude Excuse the ignorance, but isn't that the point of the proxy? – Chris W. Commented Sep 5, 2018 at 14:56
 |  Show 4 more ments

2 Answers 2

Reset to default 5 +50

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

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

本文标签: javascriptCLI CORS Proxy not changing originstill get 403 on API reqsStack Overflow