Configurer le partage de ressources cross-origin (CORS) pour ApsaraVideo VOD à l'aide d'en-têtes de réponse HTTP personnalisés - ApsaraVideo VOD

Pour partager ou accéder à des ressources depuis différentes origines, configurez des en-têtes de réponse HTTP personnalisés. Cette rubrique explique comment activer le partage de ressources cross-origin pour les ressources dans ApsaraVideo VOD.

Qu'est-ce que le partage de ressources cross-origin ?

Le partage de ressources cross-origin (CORS) est un mécanisme standard qui permet à une page web d'accéder à des ressources provenant d'une origine différente (domaine, protocole ou port) de la sienne. Il offre un moyen sécurisé d'activer les transferts de données cross-origin. Pour plus d'informations, consultez Cross-Origin Resource Sharing (CORS).

Remarque

Q : Que se passe-t-il si CORS n'est pas activé par défaut sur CDN ?

Par défaut, CDN n'active pas le partage de ressources cross-origin (CORS). Sans cette configuration, les navigateurs appliquent la politique de même origine et bloquent les requêtes cross-origin, ce qui empêche d'autres sites web de charger vos ressources.

Erreurs cross-origin intermittentes causées par la mise en cache CDN

Lorsqu'un nœud CDN récupère du contenu depuis l'origine pour la première fois, si la requête ne contient pas l'en-tête Origin, OSS ne renvoie pas l'en-tête de réponse Access-Control-Allow-Origin. CDN met en cache cette réponse dépourvue d'en-têtes CORS (la durée de mise en cache par défaut est déterminée par les règles de cache).

Lorsqu'une requête cross-origin ultérieure contenant l'en-tête Origin atteint cette réponse mise en cache, le navigateur signale une erreur cross-origin car la réponse ne contient pas l'en-tête Access-Control-Allow-Origin. En raison du caractère aléatoire des hits de cache, l'accès à la même ressource échoue de manière intermittente.

Solution : Ajoutez l'en-tête de réponse Access-Control-Allow-Origin dans Custom HTTP Response Header sous Domain Names > Cache. Après la configuration, utilisez les fonctions d'actualisation et de préchargement pour supprimer les anciennes réponses mises en cache ne contenant pas d'en-têtes CORS sur les nœuds CDN, afin que les nouvelles réponses mises en cache contiennent les en-têtes CORS corrects.

Une fois que CDN a mis en cache une réponse, il ne récupère plus le contenu depuis l'origine pour vérifier les paramètres CORS d'OSS. Par conséquent, vous devez configurer les en-têtes de réponse au niveau du CDN, plutôt que de vous fier uniquement aux règles CORS d'OSS.

Pourquoi configurer le partage de ressources cross-origin ?

En raison des restrictions de sécurité, les navigateurs suivent généralement la politique de même origine, qui restreint les requêtes visant à charger et accéder à des ressources provenant de domaines, sous-domaines, protocoles ou ports différents. Par exemple, example.com ne peut pas accéder aux ressources sur example.org. En configurant le partage de ressources cross-origin (CORS), vous pouvez définir des en-têtes de réponse pertinents sur le serveur CDNDCDN. Si une requête inclut des en-têtes conformes aux règles autorisées, le serveur renvoie les en-têtes de réponse HTTP correspondants, ce qui permet le chargement et l'accès aux ressources cross-origin.

Fonctionnement

CORS configuré sur le serveur d'origine

Avec CORS configuré sur CDN

Activer le partage de ressources cross-origin

Connectez-vous à la console ApsaraVideo VOD.
Dans le volet de navigation de gauche, choisissez Configuration Management > CDN Configuration > Domain Names.
Sur la page Domain Names, localisez le nom de domaine que vous souhaitez gérer et cliquez sur Configure.
Dans le volet de navigation de gauche pour le nom de domaine, cliquez sur Cache.
Cliquez sur l'onglet Custom HTTP Response Header.
Cliquez sur Add pour configurer un en-tête de réponse HTTP personnalisé.

Définissez les paramètres pour les origines autorisées et cliquez sur OK.

Paramètre	Exemple
Operation	Add
Response Header	Access-Control-Allow-Origin
Header Value	* Remarque La valeur peut être définie sur un astérisque (``) pour autoriser les requêtes depuis n'importe quelle origine. Si la valeur n'est pas un astérisque (``), vous pouvez spécifier une ou plusieurs adresses IP, noms de domaine, ou un mélange des deux. Utilisez des virgules pour séparer plusieurs valeurs. Si la valeur de l'en-tête n'est pas `*`, elle doit commencer par `http://` ou `https://`. Vous pouvez inclure un numéro de port dans la valeur de l'en-tête. Les noms de domaine avec caractères génériques sont pris en charge.
Allow Duplicates	No Remarque Yes : Autorise les en-têtes en double. Le point de présence (POP) CDN conserve l'en-tête du serveur d'origine et ajoute un nouvel en-tête portant le même nom. No : Empêche les en-têtes en double. Le point de présence (POP) CDN remplace l'en-tête du serveur d'origine par le nouvel en-tête. Cette rubrique utilise un exemple où les doublons ne sont pas autorisés. La configuration réelle peut varier selon votre environnement. Important Les paramètres Allow Duplicates et CORS s'excluent mutuellement. Si Allow Duplicates est défini sur Yes, la validation CORS est désactivée.
CORS	Enable Remarque Vous pouvez configurer CORS uniquement lorsque Operation est défini sur Add et que Response Header est « Access-Control-Allow-Origin ». CORS peut être défini sur Disable ou Enable. La valeur par défaut est Disable. À l'état Off, le nœud CDN ne valide pas l'en-tête Origin dans la requête de l'utilisateur et répond uniquement avec la valeur « Access-Control-Allow-Origin » configurée. Lorsqu'il est Enabled, les nœuds CDN effectuent une validation cross-origin sur les requêtes utilisateur selon les règles suivantes et répondent avec la valeur « Access-Control-Allow-Origin » en fonction du résultat de la validation. Règles de validation cross-origin : Correspondance avec caractère générique : Lorsque la valeur de l'en-tête de réponse Response Header Access-Control-Allow-Origin est définie sur « », l'en-tête `Access-Control-Allow-Origin:` est toujours renvoyé, indépendamment du fait que la requête utilisateur inclue un paramètre `Origin` ou de la valeur de ce paramètre. Correspondance exacte : Header Value est défini sur une ou plusieurs origines spécifiques, séparées par des virgules (,). Si la valeur de l'en-tête « Origin » dans une requête correspond exactement à l'une des valeurs configurées, la réponse inclura l'en-tête cross-origin correspondant. S'il n'y a pas de correspondance exacte, l'en-tête CORS n'est pas inclus dans la réponse. Correspondance de nom de domaine avec caractère générique : Si la valeur de l'en-tête de réponse personnalisé « Access-Control-Allow-Origin » est définie sur un nom de domaine avec caractère générique, le système vérifie si la valeur Origin dans l'en-tête de requête correspond au nom de domaine avec caractère générique. Lorsqu'il est enabled, si le nom de domaine dans Header Value contient un trait d'union `-`, vous devez échapper le trait d'union avant de configurer la valeur. Échappez `-` en tant que `%-`. Par exemple : Valeur d'en-tête d'origine : `http://doc.aliyun-example.com`. Valeur d'en-tête échappée : `http://doc.aliyun%-example.com`.

Définissez les paramètres pour les méthodes autorisées et cliquez sur OK.

Paramètre	Exemple
Operation	Add
Response Header	Access-Control-Allow-Methods
Header Value	GET, POST, PUT Remarque Utilisez des virgules pour séparer plusieurs méthodes.
Allow Duplicates	No Remarque Yes : Autorise les en-têtes en double. Le point de présence (POP) CDN conserve l'en-tête du serveur d'origine et ajoute un nouvel en-tête portant le même nom. No : Empêche les en-têtes en double. Le point de présence (POP) CDN remplace l'en-tête du serveur d'origine par le nouvel en-tête. Cette rubrique utilise un exemple où les doublons ne sont pas autorisés. L'implémentation réelle peut varier selon votre environnement.

Exemples de configuration

Exemple 1

Si la valeur de l'en-tête de réponse pour le partage de ressources cross-origin est définie sur une seule valeur ou plusieurs valeurs (les valeurs multiples sont séparées par des virgules).

Si la valeur du paramètre « Origin » dans l'en-tête de requête correspond exactement à l'une des valeurs configurées, le serveur répond avec l'en-tête cross-origin correspondant.
S'il n'y a pas de correspondance exacte, l'en-tête CORS n'est pas inclus dans la réponse.

Dans la console ApsaraVideo VOD, définissez Access-Control-Allow-Origin sur http://example.com,https://aliyundoc.com.

L'en-tête Origin de la requête utilisateur est http://example.com, et le point de présence (POP) CDNDCDN répond avec Access-Control-Allow-Origin: http://example.com.
L'en-tête Origin dans la requête utilisateur est https://aliyundoc.com, et le nœud CDNDCDN répond avec Access-Control-Allow-Origin: https://aliyundoc.com.
Le nœud CDNDCDN ne répondra pas à une requête utilisateur avec l'en-tête Origin http://aliyundoc.com (en raison d'une incompatibilité de protocole : la requête utilisateur utilise HTTP, tandis que CDNDCDN est configuré pour HTTPS).
Si l'en-tête Origin d'une requête est http://aliyun.com, le point de présence (POP) CDNDCDN ne répondra pas (incompatibilité de domaine).

Exemple 2

Si l'en-tête de réponse Access-Control-Allow-Origin est défini sur un nom de domaine avec caractère générique, la valeur Origin dans l'en-tête de requête est vérifiée pour s'assurer qu'elle correspond au nom de domaine avec caractère générique.

Dans la console ApsaraVideo VOD, définissez Access-Control-Allow-Origin sur http://*.aliyundoc.com.

La requête utilisateur contient l'en-tête Origin http://demo.aliyundoc.com, et le point de présence (POP) CDNDCDN répond avec Access-Control-Allow-Origin: http://demo.aliyundoc.com.
Si l'en-tête Origin d'une requête est http://demo.example.com, le point de présence (POP) CDNDCDN ne répondra pas car le nom de domaine ne correspond pas.
Le nœud CDNDCDN ne répond pas à une requête utilisateur avec l'en-tête Origin https://demo.aliyundoc.com car la requête utilise le protocole HTTPS, mais CDNDCDN est configuré avec le protocole HTTP.

FAQ

Pourquoi la lecture échoue-t-elle sur les navigateurs web (Chrome/Edge) avec des erreurs CORS sur les fichiers .ts ?

Les versions récentes des navigateurs appliquent une validation CORS stricte lors du chargement des segments .ts via Media Source Extensions (MSE). Si CDN n'a pas correctement configuré l'en-tête Access-Control-Allow-Origin, le navigateur bloquera la requête et la lecture échouera.

De plus, si vous avez configuré la valeur générique * pour Access-Control-Allow-Origin et que la requête du lecteur transporte des cookies ou des identifiants de session, le navigateur rejettera la réponse. Dans ce cas, remplacez la valeur * par le nom de domaine exact de votre lecteur frontal (par exemple, https://player.example.com).

Pourquoi l'aperçu de la console échoue-t-il ou les requêtes de fichiers .ts signalent-elles des erreurs CORS sur certains ordinateurs ?

Vérifiez si des règles CORS ont été ajoutées pour le nom de domaine accéléré. Sur la page Domain Names, sélectionnez le domaine cible et vérifiez que les en-têtes de réponse HTTP personnalisés incluent Access-Control-Allow-Origin avec la valeur correcte.

Pourquoi la lecture échoue-t-elle sur Android WebView mais fonctionne-t-elle sur le web/iOS après modification d'Access-Control-Allow-Origin ?

Après avoir modifié l'en-tête de réponse Access-Control-Allow-Origin, vous devez purger le cache CDN et vider le cache WebView sur l'appareil Android pour que les nouveaux paramètres CORS prennent effet. Sinon, l'application continue d'utiliser la réponse mise en cache avec les anciens en-têtes.

Pourquoi l'environnement de test ou un domaine spécifique renvoie-t-il l'erreur 4009 ?

Vérifiez si Access-Control-Allow-Origin est configuré pour autoriser uniquement le domaine de production tout en excluant le domaine de test. Ajoutez votre domaine de test à la liste des origines autorisées.

Si Access-Control-Allow-Credentials est défini sur true, la valeur Origin ne doit pas être définie sur le caractère générique *. Configurez plutôt le domaine d'origine exact (par exemple, https://test.example.com).

Pourquoi la lecture échoue-t-elle dans les mini-programmes WeChat ou les comptes officiels ?

Si la protection contre le hotlinking n'est pas activée, vous n'avez pas besoin de configurer une liste blanche de Referer. Cependant, si une interception CORS se produit toujours, vous devez néanmoins configurer des règles CORS.

Pour la lecture intégrée dans l'application au sein des comptes officiels WeChat, assurez-vous des éléments suivants :

La page de lecture est diffusée via HTTPS.
Le nom de domaine a effectué le dépôt ICP.
Le certificat SSL est valide.
La réponse de la liste de lecture M3U8 renvoie l'en-tête Content-Type correct : application/vnd.apple.mpegurl ou application/x-mpegURL.

La configuration du partage de ressources cross-origin (CORS) augmente-t-elle le risque de hotlinking ?

Non. CORS et la protection contre le hotlinking basée sur Referer sont deux mécanismes de sécurité indépendants qui fonctionnent à différents niveaux. CORS est une politique côté navigateur qui contrôle si un navigateur autorise une page web à demander des ressources depuis une origine différente. La protection contre le hotlinking basée sur Referer est un contrôle d'accès côté serveur sur CDN qui empêche les noms de domaine non autorisés d'utiliser vos ressources vidéo.

La configuration de CORS ne contourne ni n'affaiblit vos listes noires et blanches Referer existantes. Même si vous définissez Access-Control-Allow-Origin sur le caractère générique *, les requêtes dont la valeur Referer n'est pas autorisée sont toujours rejetées avec le code d'état HTTP 403. Pour empêcher le hotlinking de vos ressources, configurez la protection contre le hotlinking basée sur Referer. Pour plus d'informations, consultez Configurer la protection contre le hotlinking Referer.