J'ai un problème avec ce que je crois être la mise en cache de l'en-tête d'origine lors de l'interrogation de l'API WordPress. Cependant, j'ai du mal à comprendre exactement ce qui se passe et comment je peux y remédier.Présentation de Access-Control-Allow-Origin et de la mise en cache
Première - Voici ce qui se passe:
J'ai une page HubSpot que les requêtes via ajax l'API WordPress et plus précisément les points de terminaison ajoutée par le plug-in API WP Menus - Je construis puis le menu de sorte que lorsque mis à jour dans WordPress le client (ou l'une des équipes marketing) - le menu est également mis à jour sur les pages HubSpot.
La page HubSpot est sur un sous-domaine du site WordPress, et d'abord le site WordPress a l'en-tête Access-Control-Allow-Origin ajouté avec juste l'URL du sous-domaine défini explicitement.
Si je navigue jusqu'à l'écran d'édition dans HubSpot - le menu principal ne se charge pas, mais le deuxième appel (pour un menu différent) réussit. L'erreur pour le menu principal est la suivante:
Le 'Access-Control-Allow-Origin' en-tête a une valeur 'http://subdomain.example.com' qui ne correspond pas à l'origine fournie. L'origine 'https://preview.hs-sites.com' n'est donc pas autorisée accès.
Le http://subdomain.example.com étant l'URL de la page en cours. Curieusement, l'URL de la page d'aperçu n'est pas https://preview.hs-sites.com - mais je suppose que c'est peut-être parce que l'aperçu se charge dans un iframe.
Maintenant, quand je vais à l'URL live, la même chose se produit - les erreurs d'appel premier, mais le second réussit. Cette fois, l'erreur est la suivante:
Le 'Access-Control-Allow-Origin' en-tête a une valeur 'https://preview.hs-sites.com' qui ne correspond pas à l'origine fournie. L'origine 'http://subdomain.example.com' n'est donc pas autorisée accès.
Question 1 - est-ce parce que l'origine a été mis en cache par le site WordPress ?
J'ai maintenant ajouté à la fois http://subdomain.example.com et https://preview.hs-sites.com aux allowed_http_origins filtre dans WordPress - comme suit:
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;
}
Question 2: Quelle que soit la mise en cache présumée - pourquoi est- https://preview.hs-sites.com pas acceptable s'il a été ajouté à les origines autorisées?
Je ne savais pas comment tester la fonction ci-dessus - donc j'ai aussi essayé ce qui suit:
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;
});
});
Mais les mêmes erreurs se produisent exactement.
Question 3: Quelqu'un pourrait-il s'il vous plaît expliquer le processus qui se déroule dans cette situation et ce que les erreurs disent - en particulier où qu'ils obtiennent leurs valeurs à partir - est l'origine de la page en cours? Et l'en-tête «L'Access-Control-Allow-Origin» a une valeur «... - cette valeur est définie par tout ce qui a été défini comme l'en-tête Access-Control-Allow-Origin dans WordPress - correct?
Remarque J'ai également essayé de placer en-tête no-cache dans la demande ajax, mais cette erreur en raison de la demande de contrôle en amont. J'ai également ajouté une chaîne de requête aléatoire à la requête, ce qui n'a aucun effet.
Je souhaite éviter d'ajouter une valeur générique comme en-tête Access-Control-Allow-Origin pour des raisons de sécurité. Et j'aimerais vraiment comprendre ce qui se passe!