了解Access-Control-Allow-Origin和缓存 [英] Understanding Access-Control-Allow-Origin and caching

问题描述

我在查询WordPress API时遇到了我认为是缓存原始标头的问题。但是，我正在努力弄清楚到底发生了什么以及如何解决它。

I have an issue with what I believe to be caching of the origin header when querying the WordPress API. However, I am struggling to work out exactly what is happening and how I can fix it.

首先 - 这是发生了什么：

First - here's what's happening:

我有一个HubSpot页面，通过ajax查询WordPress API，特别是WP API Menus插件添加的端点 - 然后构建菜单，以便客户端（或其中一个营销团队）在WordPress中更新） - 菜单也在HubSpot页面上更新。

I have a HubSpot page that queries via ajax the WordPress API and specifically the endpoints added by the WP API Menus plugin - I then build the menu so that when updated in WordPress by the client (or one of the marketing team) - the menu is updated on the HubSpot pages too.

HubSpot页面位于WordPress站点的子域中，最初WordPress站点的头部为Access-Control -Allow-Origin添加了 明确设置的子域名。

The HubSpot page is on a subdomain of the WordPress site, and initially the WordPress site had the header Access-Control-Allow-Origin added with just the subdomain URL explicitly set.

如果我浏览到内部的编辑屏幕HubSpot - 主菜单未加载，但第二次调用（对于不同的菜单）成功。主菜单的错误如下：

If I browse to the edit screen within HubSpot - the main menu doesn't load, but the second call (for a different menu) succeeds. The error for the main menu is as follows:

'Access-Control-Allow-Origin'标头的值为
' http://subdomain.example.com '不等于提供的
来源。因此不允许来源' https://preview.hs-sites.com '
访问。

The 'Access-Control-Allow-Origin' header has a value 'http://subdomain.example.com' that is not equal to the supplied origin. Origin 'https://preview.hs-sites.com' is therefore not allowed access.

http： //subdomain.example.com 是实时网页的网址。奇怪的是，预览页面的实际URL不是 https://preview.hs-sites.com - 但我认为这可能是因为可能在iframe中预览加载。

The http://subdomain.example.com being the URL of the live page. Strangely the actual URL of the preview page is not https://preview.hs-sites.com - but I assume this may be because perhaps preview loads in an iframe.

现在，当我转到实时URL时，同样的事情发生 - 第一次调用错误，但第二次成功。这次错误如下：

Now, when I then go to the live URL, the same thing happens - the first call errors, but the second succeeds. This time the error is as follows:

'Access-Control-Allow-Origin'标题的值为
'< a href =https://preview.hs-sites.com =nofollow noreferrer> https://preview.hs-sites.com '不等于提供的
起源。因此，不允许
访问来源' http://subdomain.example.com '。

---

---

问题1 - 这是因为原点已被缓存通过
WordPress网站？

Question 1 - is this because the origin has been cached by the WordPress site?

我现在已经添加了 http://subdomain.example.com 和 https：/ /preview.hs-sites.com 到WordPress中的 allowed_http_origins 过滤器 - 如下所示：

I have now added both http://subdomain.example.com and https://preview.hs-sites.com to the allowed_http_origins filter within WordPress - as follows:

add_filter( 'allowed_http_origins', 'my_add_origins' );
function my_add_origins($origins) {
    $origins[] = 'https://preview.hs-sites.com';
    $origins[] = 'http://subdomain.example.com';
    return $origins;
}

问题2：无论假定的缓存如何 - 为什么
https://preview.hs-sites.com 如果有的话是不可接受的已被添加到
允许的来源？

Question 2: Regardless of the presumed caching - why is https://preview.hs-sites.com not acceptable if it has been added to the allowed origins?

我不确定如何测试上述功能 - 所以我也试过以下：

I was unsure how to test the above function - so I also tried the following:

add_action( 'rest_api_init', function() {
    remove_filter('rest_pre_serve_request', 'rest_send_cors_headers');
    add_filter('rest_pre_serve_request', function($value) {
        $domains = [
            'https://preview.hs-sites.com',
            'http://subdomain.example.com'
        ];
        $allowed = get_http_origin();
        if ($allowed && (in_array($allowed, $domains))) {
            header("Access-Control-Allow-Origin:" . esc_url_raw($allowed));
        } elseif (!$allowed) {
            header("Access-Control-Allow-Origin: http://subdomain.example.com");
        }
        header('Access-Control-Allow-Methods: GET');

        return $value;
    });
});

但是出现完全相同的错误。

But the exact same errors occur.

问题3：有人可以解释在这种情况下发生
的过程以及错误所说的 - 特别是在
他们从中得到他们的价值的地方 - 来源于当前页面？而
''Access-Control-Allow-Origin'标题的值为'... - 这个
值是由设置为
访问控制的任何值设置的WordPress中的Allow-Origin标题 - 正确吗？

Question 3: Could somebody please explain the process that takes place in this situation and what the errors are saying - specifically where they are getting their values from - is origin the current page? And the 'The 'Access-Control-Allow-Origin' header has a value' ... - this value is being set by whatever has been set as the Access-Control-Allow-Origin header in WordPress - correct?

注意我还尝试设置no-cache标头ajax请求，但由于预检请求导致此错误。我还在请求中添加了一个随机查询字符串，这没有任何效果。

Note I have also tried setting no-cache header in the ajax request, but this errors because of the preflight request. I've also added a random querystring to the request, which has no effect.

我想避免添加通配符值作为Access-Control-Allow-出于安全原因的Origin头。我真的很想了解发生了什么！

I'd like to avoid adding a wildcard value as the Access-Control-Allow-Origin header for security reasons. And I'd really like to understand what's going on!

推荐答案

尝试添加 Vary 响应头，值为 Origin 到服务器响应。

Try adding a Vary response header with the value Origin to the server response.

这应该会导致任何浏览器在 Origin 请求标头的值与 Origin 缓存的请求的值。

That should have the effect of causing any browser to skip its cache and make a new network request when the value of the Origin request header is different from the Origin value of the request it cached from.

有关详细信息，请参阅关于 Vary 响应标题的MDN文章。

For a bit more info, see the MDN article on the Vary response header.

Vary HTTP响应标头确定如何匹配未来的请求
标头以确定是否缓存响应可以使用而不是
从原始服务器请求新的。
服务器使用它来指示在内容协商算法中选择资源的
表示时使用的标头。

The Vary HTTP response header determines how to match future request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server. It is used by the server to indicate which headers it used when selecting a representation of a resource in a content negotiation algorithm.

这篇关于了解Access-Control-Allow-Origin和缓存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！