CLI CORS代理未更改原点，仍在API请求上获得403? [英] CLI CORS Proxy not changing origin, still get 403 on API reqs?

问题描述

是的，我发现了很多类似的东西，但对于我的实例仍然无法解决.我想避免破坏浏览器端的安全性，而是让代理来完成它的工作，但我担心我会丢失设置中的一些无用的细节，而且我绝不是CORS专家.

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.

所以，我得到的是... a 403;

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.

其中localhost:10000是我的api网址，而:4200是默认的Angular CLI实例.

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

因此，我希望在angular.json中配置一个代理；

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"
          },

并添加proxy.conf.json;

and add a proxy.conf.json;

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

我提供它，甚至标记CLI服务确认的proxy.conf；

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

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

....除了我仍然得到403，并且仍然在Request *标头中看到；

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

附录:我的GET似乎运行正常，但是类似Access-Control-Request-Method: POST的内容显示为Request Method: OPTIONS，这就是我获取403的地方...为什么POST成为选项?

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

附录2 :值得一提的是，我在Chrome/Firefox中遇到了这个问题，但Edge中的一切都是洁食的??

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

附录3 :该服务器正在作为--aot=true与代理一起运行.

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

推荐答案

问题是通过挖掘更多发现的唯一问题.搞清楚在服务器端(aspnet api v1)的链式配置中存在一个隐藏条件，用于OPTIONS寻找UrlReferrer.Authority，而该UrlReferrer.Authority在新的首次实例中不存在.

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.

将其拉出，相应地更改Access-Control-Allow-Origin，然后开始比赛.

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

欢呼

这篇关于CLI CORS代理未更改原点，仍在API请求上获得403?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！