Update Article “2023-04-12-un-outil-sans-daemon-pour-gérer-ses-artefacts-de-build”

_posts/2023-04-12-un-outil-sans-daemon-pour-gérer-ses-artefacts-de-build.md

@@ -48,7 +48,7 @@ On peut regarder un peu ce que donne le registre Docker pour Garage :
 }
 ```
 
-On peut reprduire le même contenu sur notre registre en commençant par récupérer tous les manifests qui ne commencent pas par sha256 :
+On peut reproduire le même contenu sur notre registre en commençant par récupérer tous les manifests qui ne commencent pas par sha256 :
 
 ```bash
 aws s3 ls s3://registry.deuxfleurs.org/v2/albatros/manifests/ | \
@@ -58,7 +58,7 @@ aws s3 ls s3://registry.deuxfleurs.org/v2/albatros/manifests/ | \
 # 0.9
 ```
 
-On peut construire le JSON :
+On peut construire le JSON à la main pour cette fois :
 
 ```json
 {
@@ -88,4 +88,15 @@ Bien entendu, il est peu probable que dégainer l'outil `crane` soit la premièr
 
 On pourrait aussi appeler ces fichiers depuis le générateur de site statique, et régulièrement regénérer le site web pour intégrer ces modifications. Aujourd'hui on utilise XHR sur la page de Garage, et ça a quand même l'avantage de la simplicité, alors pas de raison de changer :-)
 
-Voilà comment on va configurer les CORS :
+On va configurer les CORS de sorte que n'importe qui puisse lire notre index. On réalise ce choix car on ne peut pas spécifier de sous-domaine autorisé : c'est tout ou rien. Et vu qu'on ne sait pas par avance tous les sites webs qui pourraient vouloir requêter notre registre, on autorise tout le monde. Par contre on autorise seulement le GET, et voilà ce que ça donne au final :
+
+```bash
+export CORS='{"CORSRules":[{"AllowedHeaders":["*"],"AllowedMethods":["GET"],"AllowedOrigins":["*"]}]}'
+aws s3api put-bucket-cors --bucket registry.deuxfleurs.org --cors-configuration $CORS
+# VVV on fait de même pour les binaires statiques pour plus tard
+aws s3api put-bucket-cors --bucket download.deuxfleurs.org --cors-configuration $CORS 
+```
+
+
+
+