У меня проблема с тем, что я считаю кэшированием заголовка источника при запросе API WordPress. Тем не менее, я изо всех сил пытаюсь понять, что происходит и как я могу это исправить.
Сначала – вот что происходит:
У меня есть страница HubSpot, которая запрашивает через ajax API WordPress и, в частности, конечные точки, добавленные плагином WP API Menus – я затем создаю меню, чтобы при обновлении в WordPress клиентом (или одной из маркетинговой команды) – меню обновлен на страницах HubSpot.
Страница HubSpot находится на субдомене сайта WordPress, и сначала на сайте WordPress был добавлен заголовок Access-Control-Allow-Origin с явно указанным URL-адресом субдомена.
Если я перейду на экран редактирования в HubSpot – главное меню не загружается, но второй вызов (для другого меню) преуспевает. Ошибка для главного меню следующая:
Заголовок заголовка «Access-Control-Allow-Origin» имеет значение « http://subdomain.example.com », которое не соответствует предоставленному источнику. Поэтому исходный адрес https://preview.hs-sites.com 'не допускается.
Http://subdomain.example.com является URL-адресом текущей страницы. Странно, что фактический URL-адрес страницы предварительного просмотра не является https://preview.hs-sites.com – но я предполагаю, что это может быть потому, что, возможно, просмотр загрузок в iframe.
Теперь, когда я перехожу к живому URL-адресу, происходит то же самое – первые ошибки вызова, но второй преуспевает. На этот раз ошибка следующая:
Заголовок заголовка «Access-Control-Allow-Origin» имеет значение « https://preview.hs-sites.com », которое не соответствует предоставленному источнику. Происхождение « http://subdomain.example.com », следовательно, не допускается.
Вопрос 1 – это потому, что источник был кэширован сайтом WordPress?
Теперь я добавил как http://subdomain.example.com, так и https://preview.hs-sites.com фильтр разрешенных_http_origins в WordPress – следующим образом:
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 неприемлемо, если он был добавлен к разрешенному происхождению?
Я не знал, как проверить вышеперечисленную функцию, поэтому я также попробовал следующее:
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; }); });
Но происходят одни и те же ошибки.
Вопрос 3: Может кто-нибудь объяснить процесс, который имеет место в этой ситуации, и то, что говорят ошибки – в частности, где они получают свои значения, – это начало текущей страницы? Заголовок заголовка «Access-Control-Allow-Origin» имеет значение «… – это значение задается тем, что было установлено как заголовок Access-Control-Allow-Origin в WordPress – правильно?
Примечание. Я также попытался установить заголовок no-cache в запросе ajax, но это ошибки из-за запроса предполетной проверки. Я также добавил случайный запрос на запрос, который не имеет никакого эффекта.
Я хотел бы избежать добавления значения подстановочного знака в качестве заголовка Access-Control-Allow-Origin из соображений безопасности. И мне очень хотелось бы понять, что происходит!