尽管来源相同，但同源请求会导致"Access-Control-Allow-Origin不匹配"错误.注意:是否具有带有“沙盒"的CSP策略? [英] Same-origin request causes “Access-Control-Allow-Origin doesn’t match” error, though origin of course matches. Note: has CSP policy w/ "sandbox"

查看：218
本文介绍了尽管来源相同，但同源请求会导致"Access-Control-Allow-Origin不匹配"错误.注意:是否具有带有“沙盒"的CSP策略?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

当CORS及其网页的URL同时使用精确 相同 URL时，我在Firefox开发控制台中仍然收到相同的错误消息./p>

浏览器控制台消息为:

 跨域请求被阻止:\相同来源策略"不允许读取远程资源\在https://egbert.net/fonts/fontawesome-webfont.woff2?v=4.7.0.\(原因:CORS标头"Access-Control-Allow-Origin"不\匹配"https://egbert.net").

标题设置，lighttpd服务器

  Access-Control-Allow-Origin:https://egbert.net访问控制允许方法:GET，POST，OPTIONS访问控制允许标头:DNT，用户代理，X请求，如果自修改以来，缓存控制，内容类型，范围内容安全政策:default-src'none';\base-uri'none';\script-src'严格动态';\object-src'none';\style-src'self';\img-src https://egbert.net/favicon.ico https://egbert.net/images/https://egbert.net/blog/articles/*/images/*.png数据:；\media-src https://egbert.net/media/数据:；\frame-src https://egbert.net/frames/;\框架祖先的自我"；\worker-src的自我"；\child-src https://egbert.net/frames/;\font-src https://egbert.net/fonts/;\connect-src'self'https://egbert.net/;\形式动作无"；\要求使用受信任的类型；\可信类型模板；\沙盒\report-uri https://ssoseo1.report-uri.com/r/d/csp/enforce;\向端点1报告；\升级不安全的请求；\阻止所有混合内容；功能-政策:加速度计无"；相机无"；全屏自我"；地理位置无"；陀螺仪无"；磁力计无"；麦克风无"；Midi'none';通知无"；付款无"；推无"；sync-xhr'none';演讲者无"；usb'none';振动无"；推荐人政策:无推荐人

HTML设置

 < link rel ="stylesheet" href ="https://egbert.net/css/m-dark.compiled.css">

CSS路径

 <代码> */@ font-face {font-family:'FontAwesome';src:url('../fonts/fontawesome-webfont.eot?v = 4.7.0');src:url('../fonts/fontawesome-webfont.eot?#iefix& v = 4.7.0')format('embedded-opentype')，url('../fonts/fontawesome-webfont.woff2?v = 4.7.0')format('woff2')，url('../fonts/fontawesome-webfont.woff?v = 4.7.0')format('woff')，url('../fonts/fontawesome-webfont.ttf?v = 4.7.0')format('truetype')，url('../fonts/fontawesome-webfont.svg?v = 4.7.0#fontawesomeregular')format('svg');font-weight:normal;字体样式:普通}

我确保所有字体文件都可以由同一浏览器在单独的选项卡中下载.

奇怪的是，错误消息暗示远程资源".它们是完全相同的URL.

未加载任何插件，这是Firefox v73.0.1的安全模式.

更新1

当我用绝对目录路径替换CSS /@ font-face 中的相对路径('../fonts')时，它没有任何改变.

更新2

当我添加方案和域时，它没有任何改变( https://egbert.net/)到CSS的/@ font-face ，位于绝对目录路径前面，以获取完整的URL路径.

这与以下问题不同:

解决方案

在CSP策略中用 sandbox allow-same-origin 替换 sandbox 将解决此问题./p>

说明:

该问题描述的CORS问题最终是由浏览器将原始值设置为 null 引起的.因此，即使 Access-Control-Allow-Origin 响应标头设置为通常期望的原始值(与浏览器地址栏中显示的URL匹配)，但实际上不匹配，由于事实，浏览器已将原点设置为 null .

因此，您最终陷入了一个看起来像是悖论的境地，而文档似乎与它自己的来源不符.

https://stackoverflow.com/a/42242802/441757 上的答案概述了所有浏览器设置原为 null .该问题的具体原因是由 https:上的HTML规范文本引起的://html.spec.whatwg.org/multipage/#attr-iframe-sandbox ，其中指出是否设置了 sandbox :

...内容被视为来自唯一的来源，表单，脚本，并且禁用了各种可能令人讨厌的API，阻止了链接将其定位到其他浏览上下文，并确保了插件的安全. allow-same-origin 关键字使内容被视为来自其真实来源，而不是强制其成为唯一来源.

因此，最重要的是:每当在某处指定 sandbox 时，在大多数情况下，您都希望使用包含 allow-same-origin 关键字的顺序进行指定以防止出现令人惊讶且难以解决的问题/副作用，例如问题中所述的CORS问题.

When the exact same URL is being used in both by CORS and its web pages' URL, I still get the same error messages in my Firefox development console.

Browser console messages were:

Cross-Origin Request Blocked: \
  The Same Origin Policy disallows reading the remote resource \
  at https://egbert.net/fonts/fontawesome-webfont.woff2?v=4.7.0. \
  (Reason: CORS header ‘Access-Control-Allow-Origin’ does not \
  match ‘https://egbert.net’).

Header Settings, lighttpd Server

Access-Control-Allow-Origin: https://egbert.net
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range
Content-Security-Policy: \
    default-src 'none'; \
    base-uri 'none'; \
    script-src 'strict-dynamic'; \
    object-src 'none'; \
    style-src 'self'; \
    img-src https://egbert.net/favicon.ico https://egbert.net/images/ https://egbert.net/blog/articles/*/images/*.png data:; \
    media-src https://egbert.net/media/ data:; \
    frame-src https://egbert.net/frames/; \
    frame-ancestors 'self'; \
    worker-src 'self'; \
    child-src https://egbert.net/frames/; \
    font-src https://egbert.net/fonts/; \
    connect-src 'self' https://egbert.net/; \
    form-action 'none'; \
    require-trusted-types-for; \
    trusted-types template; \
    sandbox; \
    report-uri https://ssoseo1.report-uri.com/r/d/csp/enforce; \
    report-to endpoint-1; \
    upgrade-insecure-requests; \
    block-all-mixed-content;
Feature-Policy: accelerometer 'none'; camera 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; notifications 'none'; payment 'none'; push 'none'; sync-xhr 'none'; speaker 'none'; usb 'none'; vibrate 'none';
Referrer-Policy: no-referrer

HTML settings

  <link rel="stylesheet" href="https://egbert.net/css/m-dark.compiled.css">

CSS path

 */@font-face {
 font-family:'FontAwesome';
 src:url('../fonts/fontawesome-webfont.eot?v=4.7.0');
 src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.7.0') format('embedded-opentype'),
 url('../fonts/fontawesome-webfont.woff2?v=4.7.0') format('woff2'),
 url('../fonts/fontawesome-webfont.woff?v=4.7.0') format('woff'),
 url('../fonts/fontawesome-webfont.ttf?v=4.7.0') format('truetype'),
 url('../fonts/fontawesome-webfont.svg?v=4.7.0#fontawesomeregular') format('svg');
 font-weight:normal;
 font-style:normal
}

I've ensured that all font files are able to be downloaded by the same browser in separate tabs.

And what's weirder is that the error message implies "remote resource". They're the exact same URL.

No plugins were loaded, this is safe mode Firefox v73.0.1.

Update 1

It didn't change anything when I replaced the relative path ('../fonts') in the /@font-face of CSS with an absolute directory path.

Update 2

It didn't change anything when I added the scheme and domain (https://egbert.net/) to the /@font-face of CSS in front of the absolute directory path for a full-blown URL path.

This is not the same issue as:

解决方案

Replacing sandbox with sandbox allow-same-origin in the CSP policy will fix the problem.

Explanation:

The CORS problem the question describes is ultimately caused by the fact the browser is setting the origin value to null. So even though the Access-Control-Allow-Origin response header is set to the origin value that’d normally be expected — matching the URL shown in the browser address bar — it actually doesn’t match, due to the fact the browser has set the origin to null.

So you end up in what looks like a paradox, with the document seeming to not match its own origin.

The answer at https://stackoverflow.com/a/42242802/441757 outlines all cases where browsers set an origin to null. The specific cause of the case in the question arises from HTML spec text at https://html.spec.whatwg.org/multipage/#attr-iframe-sandbox which states that if sandbox is set:

…the content is treated as being from a unique origin, forms, scripts, and various potentially annoying APIs are disabled, links are prevented from targeting other browsing contexts, and plugins are secured. The allow-same-origin keyword causes the content to be treated as being from its real origin instead of forcing it into a unique origin.

So the bottom line is: Whenever you specify sandbox somewhere, in most cases you want to be specifying it with the allow-same-origin keyword included — in order to prevent surprising and hard-to-troubleshoot problems/side-effects such as the CORS problem described in the question.

这篇关于尽管来源相同，但同源请求会导致"Access-Control-Allow-Origin不匹配"错误.注意:是否具有带有“沙盒"的CSP策略?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆