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

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.

localhost:10000

:4200

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

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

....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??

Access-Control-Request-Method: POST

Request Method: 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.

--aot=true

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 5 '18 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.
Sep 5 '18 at 14:11

OPTIONS

Origin

Access-Control-Allow-Headers

Also might check the 2nd addendum about the Chrome vs FF vs Edge nuances, everything is fine in Edge (for once...)
– Chris W.
Sep 5 '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 5 '18 at 14:42

@misorude Excuse the ignorance, but isn't that the point of the proxy?
– Chris W.
Sep 5 '18 at 14:56

2 Answers
2

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

http://localhost:10000/*

http://localhost:4200/some/rest/*

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

@ChrisW. and your URLs were pointing to the proxy ?
– YoukouleleY
Sep 12 '18 at 18:36

because your host header is not good
– YoukouleleY
Sep 12 '18 at 18:37

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
– YoukouleleY
Sep 12 '18 at 19:18

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.

UrlReferrer.Authority

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

Access-Control-Allow-Origin

Cheers

Thanks for contributing an answer to Stack Overflow!

But avoid …

To learn more, see our tips on writing great answers.

Some of your past answers have not been well-received, and you're in danger of being blocked from answering.

Please pay close attention to the following guidance:

But avoid …

To learn more, see our tips on writing great answers.

Required, but never shown

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

搜尋此網誌

Dfyjkt