L'authentification de base par mot de passe HTTP peut-elle interférer avec l'accès CDN?
Je fais de mon mieux pour poser cette question. Je franchis ici plusieurs domaines pour couvrir une autre équipe, MIA, chargée de cette tâche. S'il vous plaît, guidez-moi si la question semble stupide.
Nous avons affaire à un site Web qui serait hébergé via VHost sur des serveurs Apache. Ainsi, lorsque nous consultons blah.oursite.com, bon nombre de nos actifs statiques proviennent en réalité de redirect/proxy/quelque chose d'un CDN pointant vers notre compartiment S3.
Donc, si j'essaie de faire une version visuelle brute de ceci: Utilisateur> Site VHost> redirection/proxy vers CDN> S3
Le site et les actifs du VHost dans ce cas (dans le sous-domaine spécifique blah) sont protégés par ce que nous croyons être l'authentification de base par mot de passe HTTP contrôlée par .htaccess. Ainsi, lorsque nous visitons blah.oursite.com, le navigateur nous présente un popup demandant un nom d'utilisateur et un mot de passe. C'est par conception.
Nous constatons actuellement que les quelques ressources statiques hébergées sur un CDN externe ne peuvent pas être chargées sur le sous-domaine blah. Si nous chargeons www.oursite.com, tous les actifs se chargent sans problème. Par conséquent, l’une de nos théories principales, en tant que novices dans ce domaine particulier, est que la protection des informations d'identification .htaccess interfère avec la capacité du sous-domaine blah d'accéder au contenu CDN.
Cela a-t-il un sens? Est-ce une possibilité? Quelles techniques pouvons-nous utiliser pour tester cette théorie (sans savoir quel type de configuration est défini par l'équipe qui gère les instances Apache) ou pour résoudre le problème? Sommes-nous hors de chance sans plus de coopération de l'autre équipe?
J'aimerais pouvoir fournir plus de détails sur ce qui se passe aux étapes entre User > VHost site > redirect/proxy, mais malheureusement, mon équipe ne possède pas ces étapes dans le processus et l'équipe qui les possède ne joue pas bien avec nous pour résoudre ce problème. Toute aide ou astuce pour nous guider ou nous aider à trouver le problème et sa solution serait extrêmement utile; Je n'ai aucune expérience en administration de serveur.
Nous avons récemment traité ce type de problème lorsque nous avons créé une copie intermédiaire de l'un de nos sites Web. Nous devions charger des actifs via le CDN pour nous assurer qu’il était correctement configuré, mais l’autorisation du mot de passe de base .htaccess a refusé de le connecter, exactement comme vous l’avez décrit.
Pour résoudre ce problème, nous avons utilisé la directive SetEnvIF Directive d'Apache.
Vous pouvez faire correspondre un en-tête de requête HTTP provenant de requêtes CDN, définir une variable d'environnement, puis autoriser le trafic avec cette variable d'environnement via la protection par mot de passe de base.
Pour ce faire, basé sur l'agent utilisateur du CDN, votre fichier .htaccess (pour Apache 2.4) ressemblerait à ceci:
SetEnvIf User-Agent ^cdnUserAgentToMatch$ cdn
AuthType Basic
AuthName "Test Site"
AuthUserFile "/path/to/passwd"
Require valid-user
Require env cdn
ErrorDocument 401 "Authorization Required"
Cela autorisera l'accès à un utilisateur valide ou à une requête avec la variable d'environnement cdn. Remarque: Par défaut, les directives requises sont évalués comme étant enveloppés dans une balise <RequireAny>; Nous n’avons donc pas besoin d’en inclure un même s’il ya deux options.
Etant donné que les agents utilisateur peuvent être usurpés, il serait probablement préférable de faire correspondre l'adresse IP demandée lors de la définition de la variable d'environnement. Ou mieux encore, certains CDN vous permettent de définir un en-tête HTTP personnalisé dans lequel vous pouvez insérer une clé et vérifier en fonction, comme ceci:
SetEvnIf CustomHeader ^5tfasdoqu7891435$ cdn
À moins que les ressources statiques que vous chargez ne contiennent quoi que ce soit qui doit absolument être protégé, il ne devrait pas être nécessaire de les charger via un proxy. Le CDN a pour objectif de rapprocher le contenu de l'utilisateur final et de le distribuer sur un certain nombre de serveurs, de manière à augmenter les temps de chargement des pages et à réduire le nombre d'appels dirigés vers le serveur principal.
Idéalement, ce qui devrait se passer ici est que votre site lui-même soit derrière le mécanisme d'authentification que vous avez choisi (toutefois, c'est à vous de le faire), mais les ressources statiques sur le CDN ne le sont pas. Lorsque vous les placez sur le site protégé BasicAuth, le fait de les charger sur un site non protégé n’est pas différent.
Maintenant, en fonction du schéma d’adressage et si https est utilisé pour votre site, c’est ce qui pourrait vous amener à annuler le chargement des ressources statiques, en particulier si vous accédez aux ressources statiques via une connexion http standard au lieu de https, car la plupart des navigateurs ont gagné " t chargez du contenu non protégé par https sur un site protégé par https pour des raisons de sécurité.
Vous avez également mentionné dans votre question que votre site est hébergé sur un vHost et supposez que le contenu statique est importé via un proxy ou quelque chose de similaire à partir du CDN. Maintenant, bien que je sois au-dessus, j’indique que ce n’est pas la meilleure pratique et que c’est en réalité l’objectif d’utiliser un CDN, j’aimerais souligner ici qu’il est peu probable que cela ait été défini de cette manière en tant que contenu statique, tout en étant ajouté à le html sur votre serveur serait directement extrait du CDN par le navigateur final une fois la page HTML chargée.
Lorsque de tels problèmes se posent, les causes les plus courantes que j'ai trouvées sont l'accès à des ressources http à partir d'un site protégé https ou la tentative d'utilisation de ressources statiques à partir de CDN avec des restrictions de référent (protection par hyperlien) sur des sites qui ne figurent pas dans la liste des sites acceptés.
S'il s'agit du problème https, il vous sera facile de l'identifier car il vous suffira de vérifier si le site utilise le protocole https: // ou non et s'il vérifie le code HTML pour voir si les ressources statiques sont en cours de chargement. une adresse https: // ou une adresse http: //.
S'il s'agit d'un problème de protection de référent, il est un peu plus difficile à identifier. Le moyen le plus simple consiste à charger le site dans votre navigateur, à ouvrir les outils de développement de Google Chrome et à consulter la console en bas. S'il y avait un problème avec le chargement des ressources, il devrait apparaître ici avec le code d'état HTTP et le fichier qui n'a pas pu être chargé.