Contexte (retour utilisateur)
Un utilisateur aime le navigateur intégré, qui affiche bien ses projets locaux. Ses environnements de dev et de préprod sont protégés par un .htaccess (HTTP Basic Auth), et il demande comment les ouvrir dans le navigateur intégré.
Constat actuel
- Aucun gestionnaire de l'événement
login d'Electron pour les guests <webview> : la demande d'identifiants est annulée par défaut, et la page affiche une erreur 401 sans jamais proposer de connexion.
- Contournement communiqué :
https://user:pass@host dans la barre d'adresse (normalizeUrl le laisse passer). Pas testé en vrai. Défauts : le mot de passe reste visible dans l'URL et l'historique, il est lisible par les agents, et il faut l'encoder s'il contient @ : /.
- Import des cookies Chrome/Safari : déjà refusé (voir la mémoire
embedded-browser-webview-migration, section « Session partagée par projet »), à ne pas rouvrir ici.
Ce qu'on veut (comme l'extension Chrome MultiPass)
Une liste de règles motif d'URL → identifiant / mot de passe, propre au projet. Le navigateur intégré y répond tout seul quand un site demande une Basic Auth, pour l'utilisateur comme pour les agents qui pilotent le navigateur via le MCP.
Piste proposée : s'appuyer sur le contexte QA (jeux de données / URLs connues)
Le contexte QA (qaContextStore, QAContext) contient déjà des datasets (champs clé → valeur, identifiants compris) et des urls, synchronisés côté serveur par projet. Deux options à trancher :
- Sur une URL connue : un champ optionnel « Authentification HTTP » qui pointe vers un jeu de données (champs
username / password) ou porte ses propres identifiants. Le motif est déduit de l'hôte de l'URL, avec possibilité de mettre un joker (*.preprod.exemple.com).
- Section dédiée « Authentification HTTP » dans le même panneau : une liste de règles motif → identifiants, à la façon de MultiPass.
Comportement attendu
- Main :
webContents.on('login') sur les guests du navigateur intégré uniquement, jamais sur la session de l'app. Si un motif correspond à l'hôte et au realm : callback(user, pass).
- Aucune règle trouvée : afficher une petite modale (identifiant, mot de passe, case « Mémoriser pour ce projet » qui crée la règle). Jamais l'annulation silencieuse d'aujourd'hui.
- Mauvais identifiants (le serveur renvoie un nouveau 401) : ne pas boucler à l'infini, rouvrir la modale avec un message.
- Les sous-ressources (CSS, JS, API sur un autre sous-domaine protégé) doivent passer par la même règle.
- Un agent ne voit jamais le mot de passe : il navigue, et c'est le desktop qui répond au défi.
Points à vérifier / contrats
- Stockage serveur : les règles sont rattachées au projet, comme le contexte QA. Se demander s'il faut chiffrer le mot de passe ou le faire pointer vers le coffre de secrets (
{{secret:NAME}}) plutôt que de le stocker en clair.
- 3 OS : l'événement
login d'Electron est le même partout, à vérifier sous Windows et Linux.
- i18n : modale et réglages traduits dans toutes les locales.
- Mobile : vérifier si un équivalent existe (aperçu web). Sinon, le noter « non porté » dans la fiche.
- Site : mentionner le support des préprods protégées par htaccess sur la page du navigateur intégré, toutes locales.
- Monitoring : mesurer le nombre de défis Basic Auth résolus automatiquement, par règle ou par modale (comptage seulement, jamais d'hôte ni d'identifiant).
- Documenter dans
context/features/BROWSER_PREVIEW_AND_TEST.md.