【问题标题】:Cross-Origin Request Blocked: The Same Origin Policy Disallows reading the remote resource... (Reason: CORS did not succeed) [closed]跨域请求被阻止:同源策略不允许读取远程资源...(原因:CORS 未成功)[关闭]
【发布时间】:2021-11-29 03:53:53
【问题描述】:

我目前正在尝试部署以下堆栈: React、Django、Nginx 和 Docker

我花了无数个小时尝试调试,但没有成功。 我已尝试查看以下资源:

  1. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSDidNotSucceed
  2. CORS preflight response did not succeed
  3. Recommendation on deploying a heavy Django + React.js web-application
  4. https://pypi.org/project/django-cors-headers/

还有更多...

我遇到了以下 CORS 错误:

跨域请求被阻止:同源策略不允许读取位于http://127.0.0.1:8000/api/token 的远程资源。 (原因:CORS 没有成功)

我对如何解决此问题或问题可能是什么感到困惑,因为此消息并没有像其他一些 CORS 消息那样真正告诉您您的请求有什么问题。例如:

“缺少标题 Access-Control-Allow-Origin”

我认为这是我的 NGINX 实现的一个问题,但我可能完全错了。我将所有请求发送到 192.168.100.6:80

从我的主机向我的 API 发出的请求可以正常工作(使用内部 IP:192.168.100.6),但是当我从同一网络中的另一台计算机发出请求时开始失败并出现 CORS 错误。 (我已转发所有相关端口)。

网络调试显示我的预检请求似乎失败了。这些是其中发送的请求标头:

选项:

Accept /
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Access-Control-Request-Headers content-type
Access-Control-Request-Method POST
Connection keep-alive
Host 127.0.0.1:8000
Origin http://192.168.100.6
Referer http://192.168.100.6/
Sec-Fetch-Dest empty
Sec-Fetch-Mode cors
Sec-Fetch-Site cross-site
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:92.0) Gecko/20100101 Firefox/92.0

发布:

Accept application/json, text/plain, /
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Connection keep-alive
Content-Length 29
Content-Type application/json;charset=utf-8
Host 127.0.0.1:8000
Origin http://192.168.100.6
Referer http://192.168.100.6/
Sec-Fetch-Dest empty
Sec-Fetch-Mode cors
Sec-Fetch-Site cross-site
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:92.0) Gecko/20100101 Firefox/92.0

这些是我对 nginx-proxy.conf 的设置:

  upstream api {
    server backend:8000;
}


server {
    server_name _;
    listen 8080;


    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Methods "GET, POST, OPTIONS, PUT,";
    add_header Access-Control-Allow-Headers "DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range";
    add_header Access-Control-Expose-Headers "Content-Length,Content-Range";
    add_header Access-Control-Max-Age 1728000;
    # ignore cache frontend
    

    location ~* (service-worker\.js)$ {
        expires off;
        proxy_no_cache 1;
    }

    location / {
        root /var/www/react-frontend;
        try_files $uri $uri/ /index.html;
    }

    location /api/{  
        proxy_pass http://api$request_uri/;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-NginX-Proxy true;
        proxy_redirect off;

    }
}

这些是我的 Django 设置:

DEBUG = False

#ALLOWED CONNECTIONS:
ALLOWED_HOSTS = ['*']
CORS_ORIGIN_ALLOW_ALL = True


# Application definition

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    
    #Django Apps:
    'authentication',

    #Packages:
    'rest_framework',
    'corsheaders',
]

#Cors middleware set as first
MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware',
    ...
]

感谢我可以查看的任何资源或任何帮助。我真的很困惑为什么会收到此 CORS 错误。

【问题讨论】:

  • OPTIONS 响应是什么样的?由于某种原因,它可能不会像我们预期的那样返回正确的 Access-Control-Allow-Origin
  • @BrunoFarias 感谢您的回答。没有选项响应。只是被拒绝了。
  • 应该有对您的预检 (OPTIONS) 请求的响应。如果您使用的是 Chrome DevTools,它就在网络选项卡中请求详细信息中的请求标头上方。或者如果您正在使用curl 你可能需要增加输出的详细程度
  • @BrunoFarias “加载响应数据失败:没有可用于预检请求的内容”。这是否意味着我的代理转发了错误的 IP?这又意味着所有连接都将被拒绝,因此没有响应?我对 API 的请求似乎试图将我连接到127.0.0.1:8000。没有运行,因为它不是运行服务器的计算机。任何想法为什么会发生这种情况?感谢您的回复。
  • “CORS 请求未成功” 错误消息实际上表明问题与 CORS 无关。它的字面意思是浏览器未能成功完成请求。或者换句话说,这意味着事务从未到达服务器实际响应的点。因此,它通常可以指示网络级别的故障,而不是服务器级别的故障。见developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/…

标签: django nginx


【解决方案1】:

因此,经过大量故障排除和评论者的帮助,我已经找到了我的具体问题的解决方案。我的代理实际上正在做它需要做的事情。根据@DariusV 的建议,我测试了通过 Postman 向它发出的请求。

Mozilla 请求失败消息本身让我相信这是一个 CORS 错误,而实际发生的只是对 127.0.0.1 的失败请求,而不是对正确 IP (192.168.100.6) 的请求。

实际发生的情况是我的所有代码库都是正确的,但出于某种原因,

docker-compose 构建

甚至:

docker-compose build --no-cache

没有更新我的代码更改(它仍在向我在开发中使用的 ip 发送请求)。

我得到的答案是:

docker volume prune "my-nginx-volume"

然后通过 docker-compose 进行重建。 提醒一下,此修剪命令会完全删除所选容器。如果其他阅读者希望添加到此解决方案中,请随时这样做。谢谢大家!

【讨论】:

  • 这仍然很有趣,它是如何从邮递员而不是从火狐指向正确的 IP。据我了解,您在 docker volume prune 之前也尝试过邮递员。
  • @Darius.V 这是因为我的反应应用程序仍在向 127.0.0.1 发送请求,尽管我的代码上的 IP 地址已更改为 192.168.100.5。所以问题不在于代理,它正在做它需要做的事情(这就是邮递员工作的原因)。问题是我的应用程序的请求一开始没有被发送到正确的 IP(因为重建时代码从未更新)。
猜你喜欢
  • 2021-04-04
  • 2014-10-17
  • 2015-07-22
  • 2018-04-20
  • 2014-07-20
  • 1970-01-01
相关资源
最近更新 更多