OSS configurer le partage de ressources entre origines CORS - Object Storage Service

Fonctionnement

Il existe deux types de requêtes CORS : les requêtes simples (envoyées directement) et les requêtes préliminaires (nécessitant une vérification d'autorisation avant la requête principale).

Une requête préliminaire est requise si l'une des conditions suivantes est remplie :

La requête utilise une méthode autre que GET, HEAD ou POST.
La requête utilise la méthode POST avec un Content-Type autre que text/plain, application/x-www-form-urlencoded ou multipart/form-data.
La requête inclut des en-têtes personnalisés, tels que x-oss-*.

Lorsqu'un navigateur envoie une requête simple à OSS, le processus suivant se déroule :

Le navigateur ajoute un en-tête Origin à la requête. L'en-tête Origin spécifie l'origine de la page appelante, par exemple Origin: https://www.example.com.
OSS compare la méthode HTTP de la requête et l'en-tête Origin avec les règles CORS du bucket pour trouver une règle correspondante. Si une correspondance est trouvée, OSS inclut l'en-tête Access-Control-Allow-Origin dans la réponse. La valeur de cet en-tête correspond à celle de l'en-tête Origin de la requête initiale.
Le navigateur reçoit la réponse. Il autorise la poursuite de la requête uniquement si l'en-tête Access-Control-Allow-Origin est présent et si sa valeur correspond au domaine de la page. Dans le cas contraire, la requête échoue.

Une requête préliminaire ajoute ces étapes avant le flux de requête simple. En cas de succès, elle procède ensuite selon le même processus qu'une requête simple :

Le navigateur envoie une requête OPTIONS qui inclut la méthode (Access-Control-Request-Method) et les en-têtes (Access-Control-Request-Headers) de la requête principale prévue.
OSS vérifie si la méthode et les en-têtes de la requête sont autorisés selon la configuration CORS. Si la requête préliminaire inclut une méthode ou un en-tête non autorisé par les règles, la requête échoue et la requête principale n'est pas envoyée.

Charger des ressources de site web statique

Un site web situé à l'adresse https://www.example.com doit charger des images, des fichiers CSS et JS stockés dans un bucket OSS.

Étape 1 : Configurer une règle CORS

Connectez-vous à la console OSS. Accédez à la page Content Security > CORS du bucket de destination et créez une règle comme suit :

Paramètre	Valeur	Description
Origine	`https://www.example.com`	Restreint l'accès à ce site web.
Méthodes autorisées	`GET`, `HEAD`	`GET` télécharge les ressources ; `HEAD` valide les caches.
En-têtes autorisés	Vide	Non requis — les requêtes simples ne déclenchent pas de requête préliminaire.
En-têtes exposés	`ETag`, `Content-Length`	`ETag` permet aux navigateurs de valider les caches avec des requêtes `HEAD`. Si un objet n'a pas changé, le serveur renvoie une réponse `304 Not Modified` pour éviter un nouveau téléchargement. `Content-Length` peut être utilisé pour afficher la progression du chargement des ressources sur le frontend.
Délai de mise en cache (secondes)	86400	Met en cache les résultats des requêtes préliminaires pendant 24 heures.
Vary: Origin	Décoché	Non nécessaire pour une origine unique et spécifique.

Étape 2 : Vérifier la configuration

Visitez l'adresse https://www.example.com et confirmez que les ressources OSS, telles que les images, se chargent correctement et qu'il n'y a aucune erreur CORS dans la console du navigateur.

Télécharger des fichiers directement depuis le frontend

Un utilisateur sur la page web https://app.example.com télécharge des fichiers, tels que des avatars et des documents, directement vers OSS.

Étape 1 : Configurer une règle CORS

Connectez-vous à la console OSS. Accédez à la page Content Security > CORS du bucket de destination et créez une règle comme suit :

Paramètre	Valeur	Description
Origine	`https://app.example.com`	Restreint les téléchargements à cette application autorisée.
Méthodes autorisées	`PUT`, `POST`	`PUT` ou `POST` sont requis pour les téléchargements.
En-têtes autorisés	`*`	Les téléchargements directs utilisent des signatures temporaires (URL présignées) plutôt qu'un en-tête `Authorization` fixe pour des raisons de sécurité. Le caractère prend en charge divers en-têtes SDK (par exemple, `x-oss-meta-`) sans introduire de risques.
En-têtes exposés	`ETag`, `x-oss-request-id`	`ETag` : Identifiant unique pour un téléchargement de fichier réussi, utilisé pour la vérification ultérieure. `x-oss-request-id` : Utilisé pour le dépannage des téléchargements ayant échoué.
Délai de mise en cache (secondes)	600	Un cache de 10 minutes équilibre la réduction des requêtes préliminaires avec des mises à jour rapides de la configuration.
Vary: Origin	Coché	Empêche la pollution du cache CDN pour les déploiements potentiels multi-domaines.

Étape 2 : Vérifier la configuration

Effectuez une opération de téléchargement sur la page https://app.example.com et confirmez que le fichier est téléchargé avec succès vers OSS et qu'il n'y a aucune erreur CORS dans la console du navigateur.

Prise en charge de plusieurs environnements

Plusieurs sous-domaines pour le développement, les tests et la production, tels que dev.example.com et app.example.com, doivent accéder aux mêmes ressources OSS.

Étape 1 : Configurer une règle CORS

Connectez-vous à la console OSS. Accédez à la page Content Security > CORS du bucket de destination et créez une règle comme suit :

Paramètre

Valeur

Description

Origine

https://*.example.com

Le caractère générique * autorise tous les sous-domaines HTTPS sous example.com.

Méthodes autorisées

GET, PUT, POST

Prend en charge la lecture et le téléchargement dans tous les environnements.

En-têtes autorisés

*

Le caractère générique * évite les modifications fréquentes des règles CORS lorsque les environnements introduisent différents en-têtes personnalisés.

En-têtes exposés

ETag, x-oss-request-id

Prend en charge à la fois la validation des téléchargements et le retour d'information sur les résultats de téléchargement.

Délai de mise en cache (secondes)

3600

Un cache d'une heure équilibre les performances avec la flexibilité de débogage.

Vary: Origin

Coché

Requis. Indique au CDN de mettre en cache les réponses par Origin, empêchant les conflits entre environnements.

Étape 2 : Vérifier la configuration

Effectuez des tests d'accès ou de téléchargement sur https://dev.example.com et https://app.example.com pour confirmer que toutes les opérations réussissent.

Effectuer des appels de type API avec authentification

Une application frontend située à l'adresse https://api.example.com doit accéder aux ressources OSS protégées en incluant des en-têtes personnalisés tels que Authorization.

Étape 1 : Configurer une règle CORS

Connectez-vous à la console OSS. Dans le bucket de destination, accédez à la page Content Security > CORS et créez une règle comme suit :

Paramètre

Valeur

Description

Origine

https://api.example.com

Pour les requêtes contenant des informations d'authentification, l'origine doit être un domaine précis et fiable.

Méthodes autorisées

GET, PUT, DELETE

Prend en charge la lecture, la mise à jour et la suppression des ressources privées.

En-têtes autorisés

authorization, content-type, x-oss-*

N'utilisez pas *. Listez explicitement les en-têtes requis (principe du moindre privilège).

En-têtes exposés

ETag, x-oss-request-id

Fournit un identifiant de vérification pour les opérations réussies et un ID pour le dépannage.

Délai de mise en cache (secondes)

600

Un délai de mise en cache plus court (10 minutes) garantit que les modifications de la politique de sécurité s'appliquent rapidement.

Vary: Origin

Sélectionner

Garantit que le CDN met en cache les réponses séparément par origine.

Étape 2 : Vérifier la configuration

Initiez une requête avec un en-tête Authorization depuis la page https://api.example.com et confirmez que vous pouvez accéder à la ressource OSS protégée.

Application en production

Bonnes pratiques de sécurité

Suivez le principe du moindre privilège.

Configurez précisément Origin (AllowedOrigin) : Évitez de définir * pour Sources sauf si votre bucket est entièrement public. Spécifiez des domaines exacts, tels que https://www.example.com.
Restreignez les Allowed Methods : N'exposez que les méthodes HTTP dont votre application a besoin. Pour les sites en lecture seule, configurez uniquement GET et HEAD.
Spécifiez explicitement les Allowed Headers : Pour les requêtes authentifiées (avec en-tête Authorization), n'utilisez pas *. Listez explicitement tous les en-têtes de requête requis.

Bonnes pratiques de performance

Optimisez le cache des requêtes préliminaires : Une valeur raisonnable pour MaxAgeSeconds, telle que 86400 secondes (24 heures), réduit considérablement les requêtes préliminaires, abaissant ainsi la latence et les coûts.
Évaluez l'impact de Vary: Origin : L'activation de Vary: Origin résout les problèmes de pollution du cache mais augmente la complexité de la mise en cache du CDN. Cela peut réduire le taux de succès du cache et augmenter le trafic vers l'origine (coûts et latence supplémentaires). Activez cette option uniquement après avoir évalué vos modèles de trafic.

Accélération CDN

Si votre bucket est accéléré par Alibaba Cloud CDN et accessible via un domaine CDN, les requêtes inter-origines atteindront d'abord un point de présence (PoP) CDN. Vous devez configurer les règles CORS dans la console CDN, et non dans la console OSS. La configuration CORS dans OSS s'applique uniquement aux requêtes effectuées directement vers le domaine d'origine OSS. Pour plus de détails, consultez Configurer le partage de ressources entre origines.

Paramètres des règles CORS

Vous pouvez configurer jusqu'à 20 règles CORS pour chaque bucket. OSS évalue les règles séquentiellement de haut en bas et applique la première qui correspond à la requête. Une fois qu'une correspondance est trouvée, OSS ne vérifie pas les règles suivantes.

Paramètre	Obligatoire	Description
Origine (AllowedOrigin)	Oui	Spécifie les sites web (domaines d'origine) autorisés à effectuer des requêtes inter-origines vers les ressources OSS. Le format est `protocole://domaine ou adresse IP[:port]`. Exemple : `https://www.example.com` ou `http://192.168.1.1:8080`. Le caractère générique `` est pris en charge, mais vous ne pouvez l'utiliser qu'une seule fois dans chaque origine. Exemples valides* : `https://.example.com`, `http://localhost:` ou `http://192.168.1.1:8080` Exemples invalides : `https://.example.` ou `https://*` Plusieurs origines sont autorisées, une par ligne.
Méthodes autorisées (AllowedMethod)	Oui	Spécifie les méthodes HTTP autorisées. Valeurs valides : `GET`, `PUT`, `POST`, `DELETE`, `HEAD`. Plusieurs méthodes sont autorisées.
En-têtes autorisés (AllowedHeader)	Non	S'applique aux requêtes préliminaires et détermine quels en-têtes HTTP peuvent être inclus dans la requête réelle. Le caractère générique `*` est pris en charge, ce qui autorise tous les en-têtes. Plusieurs en-têtes sont autorisés, un par ligne. Les en-têtes NE SONT PAS insensibles à la casse.
En-têtes exposés (ExposeHeader)	Non	Spécifie quels en-têtes de réponse OSS sont accessibles au JavaScript côté client. Le caractère générique `` n'est pas pris en charge. Plusieurs en-têtes sont autorisés, un par ligne. Cas d'utilisation* : Pour obtenir l'`ETag` ou l'`x-oss-request-id` d'un fichier téléchargé en JavaScript, ajoutez `ETag` et `x-oss-request-id` à ce paramètre.
Délai de mise en cache (MaxAgeSeconds)	Non	Spécifie le temps en secondes pendant lequel un navigateur peut mettre en cache le résultat d'une requête préliminaire `OPTIONS`. Effet : Pendant la durée de mise en cache, les requêtes inter-origines identiques ultérieures pour la même ressource ne déclencheront pas de nouvelle requête préliminaire, ce qui optimise les performances.
Vary: Origin	Non	Détermine s'il faut ajouter l'en-tête de réponse HTTP `Vary: Origin`. Cet en-tête indique aux CDN et autres caches intermédiaires de mettre en cache différentes versions de la ressource en fonction de l'en-tête `Origin` de la requête. Cela empêche la pollution du cache lorsque plusieurs origines accèdent à la même ressource. Cas d'utilisation : Pour empêcher la pollution du cache lorsque vous configurez plusieurs domaines ou un caractère générique pour le paramètre `Sources`, activez cette option. Important L'activation de cette option peut réduire le taux de succès du cache CDN.

FAQ

Erreur : No 'Access-Control-Allow-Origin' header is present on the requested resource.

Cette erreur signifie généralement que le navigateur a mis en cache une ancienne réponse sans en-têtes CORS, ou qu'aucune règle CORS ne correspond à la requête entrante.

Videz le cache de votre navigateur et réessayez. Si l'erreur persiste, vérifiez vos règles CORS :

Connectez-vous à la console OSS.
Cliquez sur Buckets, puis cliquez sur le nom du bucket de destination.
Dans le volet de navigation de gauche, choisissez Content Security > CORS.
Sur la page CORS, cliquez sur Create Rule.
Dans le panneau Create CORS Rule, définissez Origin sur *, sélectionnez toutes les Allowed Methods, définissez Allowed Headers sur *, définissez Exposed Headers sur ETag et x-oss-request-id, définissez Cache Timeout (Seconds) sur 0, sélectionnez Vary: Origin et cliquez sur OK.
Si le problème persiste, connectez-vous à n'importe quel serveur et exécutez la commande suivante pour afficher les en-têtes de requête inter-origines.
```
curl -v -o output_file.txt -H 'Origin:[$URL2]' '[$URL1]'
```
Remarque
- [URL1] est l'URL de la ressource OSS demandée.
- [URL2] est l'adresse d'origine que vous avez configurée dans la règle CORS.
Le système affiche une sortie similaire à la suivante.
- Si la réponse inclut un en-tête CORS correspondant, le problème est probablement lié à la mise en cache du navigateur ou du réseau. Une requête antérieure non-CORS a pu être mise en cache localement, et une requête inter-origines ultérieure a récupéré cette réponse mise en cache au lieu d'obtenir une nouvelle réponse du serveur. Essayez les solutions suivantes :
  - Appuyez sur Ctrl+F5 dans votre navigateur pour vider le cache, puis testez si le problème persiste.
  - Définissez Cached-Seconds sur 0 dans la règle CORS. Cela force chaque requête à récupérer à nouveau l'autorisation CORS depuis le serveur.
    
    Remarque
    Vous pouvez définir le cache-control d'un objet sur no-cache lors du téléchargement. Pour les objets déjà téléchargés, vous pouvez utiliser ossutil pour modifier ce paramètre. Pour plus d'informations, consultez set-meta (Gérer les métadonnées des objets).
  - Utilisez le CDN pour accélérer OSS, en garantissant que toutes les requêtes desservies par le CDN incluent des en-têtes CORS.
- Si la réponse contient deux en-têtes CORS ou un en-tête qui ne correspond pas à votre configuration OSS, le problème est probablement causé par l'utilisation du CDN pour accélérer OSS :
  1. Connectez-vous à la console CDN et désactivez temporairement l'accélération CDN pour le nom de domaine afin de confirmer que le problème inter-origines est résolu.
  2. Après confirmation, cliquez sur le nom de domaine spécifique, puis accédez à Cache Configuration > Node HTTP Response Header.
  3. Définissez des en-têtes de réponse HTTP personnalisés selon vos besoins.
Si le problème CORS n'est toujours pas résolu, consultez Erreurs courantes et solutions pour CORS OSS pour un dépannage supplémentaire.

Erreur : The 'Access-Control-Allow-Origin' header has a value '...' that is not equal to the supplied origin.

Le serveur a renvoyé un en-tête Access-Control-Allow-Origin, mais sa valeur ne correspond pas à l'Origin de la requête. Il s'agit souvent d'un problème de mise en cache : un navigateur ou un CDN met en cache la réponse pour un domaine et la sert à un autre.

Activez l'option Vary: Origin dans votre règle CORS pour empêcher les conflits de cache entre différents sites web, ou videz le cache de votre navigateur avant de réessayer.

Erreur : Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.

Cette erreur se produit parce que le frontend a envoyé une requête avec informations d'identification (Access-Control-Allow-Credentials est True), mais Access-Control-Allow-Origin est défini sur *. Les navigateurs interdisent cette combinaison pour empêcher tout site d'accéder à des données sensibles comme les cookies ou les jetons Authorization.

Si vous avez besoin d'informations d'identification, changez Sources de * vers un domaine spécifique (par exemple, https://example.com).
Si vous n'avez pas besoin d'informations d'identification, définissez xhr.withCredentials sur false dans votre code frontend et assurez-vous que Access-Control-Allow-Credentials est false sur le serveur.

Comment améliorer la lenteur du chargement inter-origines depuis OSS ?

La vitesse de chargement inter-origines dépend de la latence réseau entre le client et le bucket OSS. Une requête inter-origines inclut un en-tête Origin. Pour les accès longue distance (par exemple, de Chine (Hong Kong) vers la Chine continentale), utilisez un endpoint Transfer Acceleration pour optimiser le chemin réseau.

Remarque

Transfer Acceleration optimise les chemins réseau pour améliorer les vitesses de transfert de données mondiales.