Chrome onAuthRequired : vérifier isProxy avant d’envoyer des identifiants
Le rappel d’authentification de Chrome peut décrire un défi de proxy ou un défi d’origine. Fournir les mêmes identifiants aux deux est un défaut de portée des identifiants.
Une extension de navigateur peut rencontrer des défis d’authentification venant de deux endroits différents : le proxy qui achemine la requête et le site web de destination. Ils ne doivent pas recevoir automatiquement le même compte.
Le discriminant utile dans l’événement webRequest.onAuthRequired de Chrome est isProxy. Un rappel qui supprime cette vérification simplement pour faire disparaître une invite peut commencer à fournir les identifiants du proxy à un défi d’origine.
Faire correspondre le proxy auquel vous voulez faire confiance
Vérifier isProxy n’est qu’un début. Limitez aussi le traitement au challenger proxy attendu et au contexte de la requête. Une extension qui gère plusieurs points de terminaison doit sélectionner le compte appartenant à ce point de terminaison, et non un mot de passe global pour chaque défi.
Ne partez pas du principe que la configuration de la route du proxy et la gestion de sa connexion relèvent d’une seule autorisation ou d’un seul appel d’API. Chrome les documente séparément. Utilisez la référence webRequest actuelle pour les données d’événement et les autorisations d’authentification. Un exemple d’enregistrement d’un écouteur Manifest V3 montre l’enregistrement synchrone et la sélection du compte à l’intérieur du rappel.
Vérifier la génération du manifeste
Les exemples qui mentionnent une API WebRequest expérimentale proviennent d’anciennes versions d’extension. Les exigences d’autorisation actuelles dépendent de la génération de manifeste de l’extension et de son modèle de déploiement. En particulier, la gestion de l’authentification dispose de sa propre voie d’autorisation prise en charge ; un exemple obsolète d’écouteur bloquant ne suffit pas à établir qu’une extension Manifest V3 peut l’exécuter sans modification.
Un gestionnaire correct doit aussi éviter de réessayer indéfiniment les mêmes identifiants rejetés. Traitez un second défi après la fourniture d’un compte comme une preuve à examiner, et non comme une demande de rejouer le mot de passe pour toujours.
Les identifiants doivent rester dans la voie de traitement protégée appropriée de l’extension. Ne les publiez pas dans un fichier PAC et ne les codez pas en dur dans un exemple distribué. L’objectif est une connexion proxy étroitement délimitée, pas une règle à l’échelle du navigateur qui répond à chaque défi d’authentification avec le même secret.