Show Menu
TOPICS×

Prise en charge de la norme CORS dans le service Experience Cloud Identity

Les navigateurs utilisent la norme CORS (Cross Origin Resource Sharing) pour demander des ressources auprès d’un domaine autre que le domaine actuel. Le service Experience Cloud Identity prend en charge les normes CORS qui permettent d’envoyer des requêtes de ressources cross-origin côté client. Dans les navigateurs plus anciens ou non compatibles avec la norme CORS, les demandes JSONP sont restaurées.

Problèmes liés aux règles sur la même origine et aux demandes de service d’ID

Les règles sur la même origine sont des contrôles ou des restrictions de sécurité appliqués par le navigateur Web. Lorsqu’elles sont appliquées à ce niveau, le navigateur Web lui-même détermine si une requête de ressources effectuée d’une page à une autre sera autorisée ou bloquée. Pour déterminer si une requête provient de la même origine, le navigateur compare :
  • Les URI (Uniform Resource Identifiers)
  • Les noms d’hôtes (par exemple, http://www.my-webpage-example.com)
  • Les numéros de ports (par exemple, port 80 et 440 pour les requêtes HTTP et HTTPS)
Le navigateur autorise l’exécution d’une requête si les deux pages ont ces caractéristiques en commun, et bloque les requêtes si elles ont des caractéristiques différentes.

La norme CORS résout les problèmes liés aux règles de même origine

La norme CORS offre une manière efficace et sécurisée de demander des ressources sur différents domaines. La spécification CORS comprend un ensemble d’en-têtes HTTP que les navigateurs utilisent pour envoyer, recevoir et évaluer les demandes de ressources. L’évaluation d’une demande de ressource s’appelle une
preflight check
. Cette vérification permet aux navigateurs et aux serveurs d’identifier les requêtes autorisées ou bloquées. La vérification préalable est transparente par rapport à l’application, l’API ou le script qui demande une ressource. Les deux en-têtes importants lors du processus de demande de ressource sont :
  • Origin
     : un en-tête de demande qui identifie la source de la requête.
  • Access-Control-Allow-Origin
     : un en-tête de réponse qui indique si une ressource peut être partagée avec le demandeur.
Observons le fonctionnement de ces en-têtes : Dans cet exemple, imaginons une entreprise de services financiers ayant mis en œuvre le service Experience Cloud ID sur son site, www.finance-website.com. Le tableau suivant définit la manière dont les en-têtes de demande et de réponse CORS vérifient l’accès à une ressource.
Action
Description
Demande
Alors que la page de l’entreprise financière se charge, le navigateur envoie une demande à
dpm.demdex.net
. Il s’agit d’un appel au domaine des serveurs de collecte de données (DCS) utilisés par le service d’ID. Cette demande sur plusieurs domaines comprend l’en-tête :
  • Origin: https://www.finance-website.com
Réponse
La réponse du domaine DCS comprend ces en-têtes qui donnent au site de l’entreprise financière accès aux ressources requises :
  • Access-Control-Allow-Origin: https://www.finance-website.com
  • Access-Control-Allow-Credentials: true
Voir aussi useCORSOnly .

Autres avantages liés à l’utilisation des normes CORS

Le tableau ci-dessous décrit certains avantages que CORS offre aux clients utilisant le service d’ID.
Avantage
Description
Plus de sécurité
CORS utilise XMLHttpRequest pour demander des données et les transférer. Cette méthode est plus sécurisée qu’une demande JSONP. Elle fait en sorte qu’il n’existe aucune façon d’exécuter du JavaScript aléatoire, qui peut être compris dans la réponse du DCS. Les données utiles de la réponse CORS XMLHttpRequest sont analysées par le JavaScript du service d’ID et ne sont pas simplement exécutées dans une fonction de rappel.
Remarque : Pour accepter les cookies, la propriété
withCredentials
de l’objet
XMLHttpRequest
doit être définie sur
true
. Cette propriété est prise en charge dans Chrome, Firefox, Internet Explorer 10 et versions ultérieures, Opera et Safari.
Amélioration des performances
CORS permet d’améliorer les performances, parce que :
  • Le navigateur gère les demandes de ressources. Le processus de demande est transparent pour le service d’ID.
  • Contrairement aux demandes JSONP asynchrones, le navigateur n’annule pas la priorité des demandes CORS ni ne les met en file d’attente.
  • Le service d’ID répond de manière permissive. Cela signifie que lorsqu’une URL est transmise en tant qu’
    origine
    , le service d’ID lui donne accès aux ressources requises.