Une distribution CloudFront utilise une identité d'accès à l'origine (OAI) pour accéder à un compartiment S3 privé. Le compartiment refuse l'accès à toute autre personne. L'application exige que les utilisateurs consultent une page de connexion publique, puis reçoivent des cookies signés pour accéder aux répertoires privés. La distribution utilise le comportement de cache par défaut avec un accès restreint aux utilisateurs, pointant vers l'origine S3. L'accès à la page de connexion renvoie une erreur 403 Forbidden. Comment le développeur peut-il autoriser l'accès non authentifié à la page de connexion tout en protégeant le contenu privé ?

La bonne approche consiste à ajouter un second comportement de cache. Les comportements de cache CloudFront sont évalués dans l'ordre, du plus spécifique au plus général. En créant un nouveau comportement de cache avec un modèle de chemin spécifique pour la page de connexion (par exemple, /login.html) et en le plaçant avant le comportement par défaut, CloudFront peut appliquer des paramètres d'accès différents. Pour ce comportement spécifique, l'accès peut être défini comme "non restreint", permettant aux utilisateurs non authentifiés de charger la page de connexion. Le comportement de cache par défaut, qui est plus général (souvent ), resterait inchangé avec un accès restreint, protégeant ainsi le contenu privé. Les autres options sont incorrectes car : Modifier le comportement par défaut pour la page de connexion et le rendre non restreint compromettrait la sécurité du contenu privé. L'ajout d'une origine de basculement n'est pas la bonne solution pour gérer les différents niveaux d'accès au contenu au sein de la même origine. L'ajout d'une politique de compartiment S3 pour un accès direct à l'objet spécifique de la page de connexion contournerait CloudFront et ne permettrait pas de gérer l'accès via des cookies signés pour le contenu privé.