Passer au contenu principal

Comment héberger des fichiers statiques sur un CDN avec Casdoor : S3, MinIO, Azure Blob et autres fournisseurs de stockage

· Lecture de 11 minutes
Yang Luo
Yang Luo
Casdoor Maintainer

Pour héberger des fichiers statiques sur un CDN, placez-les dans un stockage objet (Amazon S3, MinIO, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud OSS ou Tencent Cloud COS), configurez le CDN pour qu'il tire ses données de ce bucket comme origine, et distribuez les URL sur le domaine du CDN. Dans Casdoor, c'est un seul paramètre : créez un fournisseur de stockage pour le bucket et mettez l'adresse du CDN dans son champ Domain. Casdoor télécharge les avatars et autres fichiers via l'API du fournisseur et enregistre les URL commençant par ce domaine. L'interface frontend de Casdoor peut également provenir d'un CDN, via frontendCdnUrl et staticBaseUrl dans app.conf.

Aperçu des fournisseurs de stockage​

Un fournisseur de stockage décide où Casdoor écrit les fichiers téléchargés : avatars utilisateurs, images de cartes d'identité, pages des conditions d'utilisation, et tout ce qui est téléchargé sur la page Resources. Vous ajoutez le fournisseur à une application, et les téléchargements effectués dans cette application lui sont destinés. La vue d'ensemble des fournisseurs de stockage liste tous les types. Ce tableau couvre ceux dont on demande habituellement :

StockageType de fournisseur CasdoorCasdoor utilise-t-il l'API S3 ?Auto-hébergeableComment l'URL publique est définie
Système de fichiers localLocal File SystemNon, fichiers simples sur disqueOui, c'est le serveur CasdoorServi par Casdoor sous /files/. Le champ Domain est en lecture seule
Amazon S3AWS S3OuiNonDomain : l'URL du bucket ou un domaine CloudFront. Endpoint (Intranet) : un point de terminaison VPC
MinIOMinIOOui, avec des requêtes de type cheminOuiDomain : l'URL MinIO suivie du nom du bucket, ou un domaine CDN
Alibaba Cloud OSSAliyun OSSNon, le SDK OSSNonDomain : un domaine CDN. S'il est vide, il devient bucket.endpoint. Endpoint (Intranet) : le point de terminaison interne
Tencent Cloud COSTencent Cloud COSNon, l'API COSNonDomain : un domaine CDN
Azure Blob StorageAzure BlobNon, l'API BlobNonDomain : un domaine personnalisé ou Front Door. Casdoor ajoute le nom du conteneur au chemin
Google Cloud StorageGoogle Cloud StorageNon, le client Go de GoogleNonDomain : s'il est vide, il devient https://storage.googleapis.com. Casdoor ajoute le nom du bucket au chemin
NAS SynologySynologyNon, l'API DSM File StationOuiPas de champ Domain. L'URL est basée sur Endpoint

Casdoor prend également en charge Qiniu Cloud Kodo, CUCloud OSS, et Casdoor, qui stocke les fichiers dans une autre instance Casdoor. Les guides par fournisseur pour Amazon S3, MinIO, Azure Blob, Google Cloud Storage, Alibaba Cloud OSS, Tencent Cloud COS, NAS Synology et le système de fichiers local indiquent quelle valeur mettre dans quel champ.

Endpoint vs. Domain​

Ces deux champs remplissent des fonctions différentes, et la plupart des problèmes de CDN viennent de leur confusion.

  • Endpoint est l'adresse que Casdoor utilise pour communiquer avec l'API de stockage : téléchargement, suppression, listage. Le CDN n'est pas impliqué.
  • Endpoint (Intranet) remplace Endpoint lorsque isCloudIntranet = true est défini dans app.conf. Cela maintient le trafic de téléchargement sur le réseau interne du fournisseur lorsque Casdoor s'exécute dans le même cloud. Ce champ apparaît pour AWS S3, Aliyun OSS, Azure Blob et CUCloud OSS.
  • Domain est la base de l'URL que Casdoor enregistre et que les navigateurs demandent. Si vous avez un CDN, son domaine se trouve ici.
  • Path prefix est ajouté devant chaque clé d'objet. Avec un préfixe casdoor, un avatar finit sous casdoor/avatar/....

Casdoor construit l'URL du fichier à partir du schéma et de l'hôte de Domain, puis du chemin de Domain, puis du préfixe de chemin, puis du chemin du fichier. Un Domain sans schéma reçoit https://. La partie chemin de Domain fait aussi partie de la clé d'objet, donc https://cdn.example.com/casdoor/ stocke les fichiers sous casdoor/ dans le bucket. Pour Azure Blob et Google Cloud Storage, Casdoor ajoute le nom du conteneur ou du bucket comme premier segment de chemin après l'hôte. Votre CDN doit servir ce chemin.

Si Domain est vide, Casdoor le remplit à partir du point de terminaison du fournisseur lors de sa première utilisation, et l'enregistre. Parfois, le résultat fonctionne, comme avec OSS et GCS. Parfois non : pour un point de terminaison S3 sans le nom du bucket, ou pour MinIO, où les requêtes en mode chemin mettent le nom du bucket dans le chemin, l'URL générée omet le bucket. Définissez Domain vous-même, téléchargez un avatar de test, et ouvrez l'URL renvoyée par Casdoor avant que quiconque ne l'utilise.

Le fournisseur que Casdoor utilise pour les avatars copiés depuis les connexions sociales provient de defaultStorageProvider dans app.conf. C'est le nom d'un fournisseur appartenant à admin (voir la référence de configuration) :

defaultStorageProvider = provider_storage_s3
isCloudIntranet = false

Buckets publics, buckets privés et URLs signées​

Casdoor enregistre une URL simple et permanente dans le champ avatar de l'utilisateur et dans l'enregistrement des ressources. Il ne crée pas d'URLs signées ou expirantes pour ces fichiers. Donc, tout ce qui se trouve à Domain doit répondre à une demande GET anonyme. Il y a deux façons de faire cela.

Rendez les objets publics. Avec AWS S3 et MinIO, Casdoor téléverse chaque objet avec l'ACL canned public-read. Avec Aliyun OSS, la bibliothèque client fait la même chose par défaut. Sur S3, cela entre en conflit avec les valeurs par défaut des nouveaux buckets : selon AWS, les nouveaux buckets utilisent le paramètre Bucket owner enforced, qui désactive les ACLs, et un téléversement qui définit une ACL comme public-read échoue avec AccessControlListNotSupported. C'est pourquoi le guide Amazon S3 vous demande d'activer les ACLs et de désactiver Block all public access. Sur OSS, une ACL d'objet prime sur l'ACL du bucket, donc un objet public-read peut être lu même dans un bucket privé. MinIO n'utilise pas l'ACL pour les lectures anonymes. Il utilise une politique de bucket :

mc anonymous set download myminio/casdoor

Azure nécessite que l'accès anonyme soit autorisé sur le compte de stockage et que le conteneur soit défini sur le niveau d'accès Blob. Google Cloud Storage nécessite que le rôle Storage Object Viewer (roles/storage.objectViewer) soit accordé à allUsers sur le bucket.

Gardez le bucket privé et laissez seul le CDN le lire. Le CDN signe ses demandes vers l'origine, et les visiteurs passent par le CDN sans signature. Chaque fournisseur a sa propre version :

  • CloudFront dispose du contrôle d'accès à l'origine (OAC). AWS exige Bucket owner enforced pour OAC, ou Bucket owner preferred si vous avez besoin d'ACLs.
  • Alibaba Cloud CDN peut récupérer depuis un bucket OSS privé après autorisation.
  • Tencent Cloud CDN dispose d'une authentification de récupération d'origine pour les buckets COS privés.
  • Azure Front Door Premium peut atteindre un compte de stockage via Private Link.
  • Le guide Cloud CDN de Google couvre également l'accès aux buckets privés, où le rôle Storage Object Viewer est attribué à un compte de service au lieu de allUsers.

Cela masque l'URL propre du bucket, mais les fichiers restent publics via le CDN. Avec les types AWS S3 et Aliyun OSS, les objets restent également lisibles à leurs URLs de bucket, à cause de l'ACL public-read définie par Casdoor.

Si les avatars ne doivent absolument pas être publics, un CDN devant un stockage d'objets est le mauvais outil. Gardez ces fichiers sur un type de stockage que vous contrôlez, et limitez qui peut atteindre cet hôte.

En-têtes de cache et piège des avatars​

Sur S3 et MinIO, Casdoor définit Content-Type à partir de l'extension du fichier lors du téléversement. Il ne définit pas Cache-Control sur aucun fournisseur. Cela signifie que le TTL par défaut du CDN s'applique. Sur CloudFront, les objets sans Cache-Control sont mis en cache pour le TTL par défaut, qui est de 24 heures lorsque vous n'utilisez pas de politique de cache. Pour contrôler cela par objet, ajoutez des métadonnées Cache-Control dans le bucket. Pour un chemin entier, utilisez une règle de cache sur le CDN.

Les avatars ont besoin d'un TTL court. Lorsqu'un utilisateur change son image, Casdoor écrit le nouveau fichier sous la même clé, avatar/<organization>/<username>.<extension>, et enregistre la même URL. Un TTL long signifie que les gens voient l'ancienne image jusqu'à expiration ou jusqu'à ce que vous purgiez ou invalidiez ce chemin. Les autres téléversements reçoivent un suffixe numéroté (-1, -2, ...) lorsque le nom est déjà pris, donc un nouveau téléversement obtient une nouvelle URL et peut être mis en cache longtemps.

Une disposition qui fonctionne :

CheminMise en cache suggérée
avatar/*TTL court (minutes), ou purge sur changement
resource/* et autres téléversementsTTL long
Ressources frontend hachées (assets/*)TTL très long. Le nom de fichier change à chaque build

Le frontend de Casdoor lui-même sur un CDN​

Indépendamment des téléversements utilisateurs, il y a trois façons de déplacer les fichiers statiques propres à Casdoor hors du serveur Casdoor.

frontendCdnUrl. Utilisez ceci si vous installez le frontend depuis le package npm casdoor-web. Pointez-le vers un CDN npm, par exemple :

frontendCdnUrl = "https://cdn.jsdelivr.net/npm/{name}@{version}"

Casdoor lit le nom du package et la version depuis le package.json dans le dossier de build. Il réécrit les liens de script et de feuille de style dans index.html vers ce CDN et garde les chemins locaux en secours. Si un fichier ne se charge pas, le navigateur le charge depuis Casdoor, et un cookie garde ce navigateur sur les fichiers locaux pour le reste de la session. Un frontend que vous construisez vous-même n'a pas de tel package.json, donc ce paramètre n'a aucun effet sur lui.

Le script de déploiement. Pour un frontend que vous compilez à partir des sources, Hébergez les fichiers du frontend sur un CDN explique deployment/deploy_test.go. Il téléverse web/build/assets/ via l'un de vos fournisseurs de stockage et pointe index.html vers le domaine du fournisseur, qui doit se terminer par /. Vite hache ces noms de fichiers, ce qui convient au TTL long indiqué dans le tableau ci-dessus.

staticBaseUrl. Cette variable définit la provenance des images par défaut telles que les logos, les icônes des fournisseurs et l'avatar par défaut. La valeur par défaut est https://cdn.casbin.org, qui sert le dépôt casbin/static. Sur un réseau sans accès Internet, hébergez vous-même une copie de ce dépôt et pointez staticBaseUrl vers celui-ci, comme décrit dans Héberger des fichiers statiques sur un intranet.

Choisir une option​

  • Un seul serveur, petite base d'utilisateurs : Local File System. Montez le répertoire files sur un volume si Casdoor fonctionne dans un conteneur. Casdoor envoie X-Content-Type-Options: nosniff et une Content-Security-Policy d'isolation avec ces fichiers, afin qu'un fichier HTML ou SVG téléversé ne puisse pas exécuter de script sur votre domaine Casdoor.
  • Auto-hébergé et compatible S3 : MinIO. C'est également le type suggéré par la documentation pour les autres magasins compatibles S3.
  • Déjà sur un cloud : utilisez le stockage objet et le CDN de ce cloud, définissez Endpoint (Intranet) là où Casdoor s'exécute dans le même cloud, et définissez Domain sur le CDN.

Références​