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 de même origine sont des contrôles de sécurité ou des restrictions appliqués par un 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 est une requête de même origine, le navigateur compare :

  • URI (Uniform Resource Identifiers)
  • Noms d’hôtes (par exemple, http://www.my-webpage-example.com)
  • Numéros de port (par exemple, port 80 et 440 pour les requêtes HTTP et HTTPS)

Le navigateur permet à une requête de réussir si les deux pages partagent ces caractéristiques et bloque les requêtes de ressources dans le cas contraire.

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

CORS offre un moyen sécurisé et efficace de demander des ressources entre 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 de déterminer quelles requêtes sont autorisées ou bloquées. La vérification en amont est transparente pour l’application, l’API ou le script qui demande une ressource. Deux en-têtes importants dans le processus de demande de ressources sont les suivants :

  • 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 comment les en-têtes de demande et de réponse CORS vérifient l'accès à une ressource.

Action Description

Requête

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 interdomaines comprend l’en-tête :

  • Origin: https://www.finance-website.com

Réponse

La réponse du domaine du serveur de collecte de données comprend ces en-têtes qui donnent à la société financière l'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 des avantages offerts par CORS aux clients qui utilisent le service d’ID.

Avantage Description

Sécurité renforcée

CORS utilise XMLHttpRequest pour demander et transférer des données. Cette méthode est plus sécurisée qu’une requête 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. La charge utile de réponse CORS XMLHttpRequest est analysée par le code JavaScript du service d’ID et n’est pas simplement exécutée 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 (v10+), Opera et Safari.

Amélioration des performances

CORS aide à améliorer les performances car :

  • Le navigateur gère les requêtes de ressources. Le processus de demande est transparent pour le service d’ID.
  • Contrairement aux requêtes JSONP asynchrones, le navigateur ne déclasse pas la priorité des requêtes CORS et ne les met pas en file d’attente.
  • Le service d’ID répond de manière autorisée. Cela signifie que lorsqu’une URL est transmise en tant qu’origine, le service d’ID lui donne accès aux ressources requises.

Sur cette page