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.

所以，我得到的是……一个 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 url，: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] 代理创建:/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 中一切都是 kosher 的???

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

ADDENDUM #3:这是作为 --aot=true 使用代理运行的.

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

推荐答案

通过深入挖掘发现问题是独一无二的.发现在服务器端 (aspnet api v1) 的链接配置中有一个隐藏的条件，用于寻找 UrlReferrer.Authority 的 OPTIONS，它不存在于说一个新的第一次实例中.

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屋！