Proxy par contexte : attribution des routes de travail

Ce que change un proxy par contexte

Un proxy par contexte attribue une route réseau à un contexte du navigateur plutôt qu'à toutes les pages d'un processus. Il convient à des travaux autorisés qui doivent rester séparés, par exemple un parcours d'assistance régional et une vérification qualité distincte. La question n'est pas de paraître venir d'ailleurs, mais de savoir quelle charge autorisée utilise quelle route et comment le vérifier.

Playwright décrit le contexte comme un profil de navigateur isolé et applique son option proxy aux requêtes de ce contexte. La documentation publique de BotBrowser décrit l'attribution de proxies différents à des contextes de navigateur différents. Le contexte est donc une unité raisonnable lorsque la bibliothèque et le déploiement approuvé le prennent en charge.

Une route n'est qu'un intermédiaire entre client et destination, comme le rappelle MDN. Elle ne prouve ni permission de destination, ni résultat régional correct, ni lieu de stockage ou de traitement des données. Le responsable applicatif doit définir ces conditions séparément. Considérez la route comme une dépendance opérationnelle nommée, non comme une déclaration d'identité, de droit, de résidence des données ou de connexion directe.

Une isolation utile mais limitée

Des contextes séparés limitent le partage accidentel de cookies et de données de site. Attribuer la route à cette frontière indique clairement quelle route appartient à quelle tâche. Fermez le contexte à la fin et créez-en un nouveau pour une affectation ultérieure.

Cette frontière ne garantit ni anonymat, ni absence d'attribution, ni indépendance de toutes les ressources. Les contextes peuvent partager hôte, organisation, fournisseur, services et politiques. L'examen de confidentialité doit couvrir comptes, conservation, accès du personnel, contrats fournisseurs et règles de la destination.

Ne déduisez pas non plus la position physique d'une personne d'une route. Elle peut être approximative ou représenter l'infrastructure du fournisseur. Langue, fuseau horaire, consentement et compte de test doivent être définis explicitement dans un plan autorisé; la route ne prouve pas que les obligations régionales concordent.

Choisir la route selon la charge

Tenez un registre concis : libellé de route, application ou test permis, responsable, région utile, période d'approbation et référence du secret. Les identifiants ne vont ni dans tickets, code, captures ni journaux; un gestionnaire de secrets ou la plateforme de déploiement les fournit de façon protégée.

Un libellé de finalité, tel que "support-portal-eu-test", est plus durable qu'un hôte copié. Une nouvelle finalité mérite une nouvelle affectation; réutiliser silencieusement un ancien libellé empêche une revue fiable. Une affectation par contexte, visible à la création, et le plus petit arrangement conforme sont les plus auditables.

Une tâche peut utiliser une route indépendante ou hériter volontairement de la route proxy et de l'identité géographique du profil de lancement lorsqu'aucune route indépendante n'est configurée. Cet héritage reste un choix de route, non une connexion directe. N'utilisez pas un défaut global parce qu'une seule tâche requiert une route : il peut affecter des pages sans rapport. Confirmez l'autorisation du service de destination et de l'organisation propriétaire.

Conservez l'association entre la tâche et la route dans l'enregistrement de déploiement. Cette trace limitée permet au propriétaire de suspendre seulement les travaux concernés lors d'une maintenance ou d'une modification d'accès, sans exposer les identifiants ni les contenus utilisateurs.

Construire un cycle de vie sûr

La documentation publique de BotBrowser indique une licence ENT Tier3 et un navigateur chargé avec un profil comme prérequis. Pour une route indépendante, appliquez la configuration approuvée de route et de métadonnées géographiques au contexte avant sa première requête dépendante. Le moment compte : des réglages appliqués après la création d'une page peuvent ne pas affecter le contexte comme attendu. Gardez la configuration dans le déploiement ou une configuration relue.

Utilisez un contexte neuf si l'affectation change. Cookies, stockage, téléchargements et état accumulés ne constituent pas une base propre pour une autre route. Fermer l'ancien contexte établit une limite nette : un contexte, une tâche déclarée, une route.

Prévoyez les échecs normaux : route indisponible, identifiant expiré, accès refusé. Définissez avant le lancement le périmètre autorisé des requêtes et protocoles, ainsi que les exclusions approuvées. Une route obligatoire doit échouer fermée : ne continuez pas silencieusement par connexion directe ni par repli non approuvé. Consignez seulement un résultat bref, le libellé et la période; escaladez les échecs au responsable.

Séparez secrets d'application et secrets de route. Un identifiant de proxy ne devient pas une connexion à la destination, et inversement. Faites tourner chaque secret avec son propriétaire afin de révoquer une route sans modifier les contrôles de l'application.

Valider le résultat autorisé

La validation doit tester le résultat de la charge autorisée, non étudier les défenses du navigateur ou de la destination. Pour un centre d'aide régional, vérifiez que le compte de test approuvé atteint la page prévue avec la langue ou politique attendue. Pour une intégration, vérifiez le résultat documenté et conservez des preuves minimales.

Comparez un changement à une base approuvée en gardant, si possible, version du navigateur, application, compte et finalité stables. Plusieurs changements simultanés ne permettent pas d'attribuer un résultat. Un déploiement progressif par groupe est plus réversible.

La santé de la route et celle de l'application sont différentes. L'infrastructure peut accepter une connexion alors que le flux échoue pour permissions, maintenance, compte ou disponibilité. Une valeur de configuration ou une page chargée ne prouve pas la sortie réelle. Pour le périmètre autorisé, comparez le libellé au relevé du point de terminaison autorisé du fournisseur ou de l'organisation. Rapportez cette observation séparément du résultat applicatif. Une voie directe inattendue, une exclusion non approuvée ou une route obligatoire indisponible fait échouer la validation.

Consignez le résultat d'acceptation dans deux champs distincts : preuve de route et résultat applicatif. Marquez le contrôle en échec si la preuve de route requise manque ou si le flux autorisé produit un résultat inattendu. Une réponse correcte de la page ne peut ainsi masquer une route non vérifiée, et le responsable sait quelle récupération décider.

Si un échec risque de dupliquer une action client ou des enregistrements, arrêtez les nouveaux travaux du groupe. Gardez les preuves minimales, restaurez une affectation approuvée si cela est sûr et demandez une enquête. Essayer une autre route n'est pas neutre lorsque règles ou impact sont incertains.

Les réglages régionaux sont explicites

BotBrowser documente une résolution géographique indépendante par contexte : fuseau, paramètres régionaux et langue laissés sur auto dérivent du proxy de ce contexte. Les réglages explicites sont aussi résolus indépendamment par contexte et par valeur. Sans route indépendante, un contexte hérite de la route et de l'identité géographique du profil de lancement. Attendez les mises à jour proxy et géographiques avant les pages dépendantes. Une langue ou un fuseau peut rester fixé par une exigence approuvée.

Notez les exceptions volontaires : valeur fixe, approbateur et raison. Revoyez-les lors d'un changement de route, d'application ou de plateforme. Une ancienne surcharge de langue ou de fuseau peut être syntaxiquement valide mais incorrecte pour la tâche.

Ne promettez pas une interprétation géographique du placement d'un proxy. La géolocalisation ne remplace pas une règle métier et un fournisseur peut modifier une route. Pour les exigences légales, contractuelles ou de consentement, appliquez la conformité de l'organisation et les contrôles documentés de la destination.

Liste opérationnelle et limites

Confirmez l'autorisation, choisissez le libellé approuvé, créez un contexte neuf, obtenez les secrets protégés, exécutez le flux documenté minimal, gardez un résultat limité et fermez le contexte. Cela fournit une trace utile sans transformer un contrôle courant en collecte étendue.

Évaluez la capacité avec la charge autorisée réelle : pages, médias, extensions, téléchargements et application consomment des ressources. Une page vide ne garantit pas la capacité de production. Fixez des limites prudentes et une marge pour les pics.

Support proxy, authentification, périmètre des requêtes et protocoles, exclusions approuvées et disponibilité des protocoles dépendent de la bibliothèque, du navigateur, du service et du déploiement. Les métadonnées géographiques peuvent servir à la résolution régionale, mais ne prouvent pas le routage et ne remplacent pas une affectation de route approuvée. Consultez la documentation proxy BotBrowser avant un changement approuvé.

Vérification de routage à deux contextes

Matrice d’acceptation synthétique (conception de test applicatif)

Cette matrice définit des assertions observables pour un dispositif synthétique ; il s’agit d’une conception de test, pas d’un résultat d’exécution runtime. Conservez séparément la preuve de sortie et le résultat applicatif afin d’éviter toute fausse attribution.

Cas	Préparation synthétique	Preuve de route observable	Résultat applicatif observable	Acceptation
Route indépendante positive	Un nouveau Contexte A reçoit une route indépendante approuvée et une requête de fixture sans effet de bord.	La référence de sortie autorisée correspond à l’étiquette, à la requête et au protocole du Contexte A.	La fixture renvoie le résultat attendu pour A.	Réussir seulement si les deux champs correspondent ; sinon fermer l’accès.
Route héritée ou manquante négative	Le Contexte B n’a pas de route indépendante, ou la route requise manque.	La fiche indique la route héritée documentée ou l’absence de preuve ; elle ne l’attribue jamais à A.	La fixture est bloquée ou produit le résultat hérité documenté ; aucun repli direct n’est accepté.	Seul le résultat négatif déclaré est accepté.
Échec fermé et récupération	Rendre indisponible la route requise de A, puis restaurer l’affectation approuvée dans un nouveau contexte.	L’échec n’a aucune sortie approuvée ; la récupération référence la route restaurée pour la même requête autorisée.	L’échec ne termine pas le travail synthétique ; la récupération le termine une seule fois.	Aucun repli direct ou non approuvé ; la récupération est une tentative distincte.
Réconciliation de nouvelle tentative et absence de fausse attribution	Utiliser un brouillon synthétique dont le premier résultat serveur est incertain, puis réconcilier avant de réessayer.	Chaque tentative possède sa référence de route ; l’incertitude n’est jamais attribuée à une route ultérieure.	Le brouillon reste modifiable jusqu’à la réconciliation ; la nouvelle tentative produit au plus un résultat confirmé.	Réussir seulement si la réconciliation précède la nouvelle tentative et si les champs restent appariés.

Utilisez deux contextes neufs pour deux charges approuvées. Le contexte A reçoit sa route indépendante approuvée et la configuration associée avant sa première page. Le contexte B n'a volontairement aucune route indépendante et doit donc hériter de la route et de l'identité géographique du profil de lancement. Donnez à chacun un libellé, un périmètre, un responsable et un résultat attendu. Une route proxy ne prouve ni stockage, ni traitement, ni conservation, ni base légale des données de destination.

Attendez les mises à jour proxy et géographiques avant les pages dépendantes. Laissez les valeurs du contexte A sur auto seulement si les valeurs dérivées du proxy sont voulues; consignez séparément toute surcharge approuvée. Exécutez ensuite le flux minimal avec une page de test publique, une donnée synthétique ou un contrôle interne qui ne peut créer de transaction client.

Pour A, vérifiez la sortie réelle avec le relevé du fournisseur ou du réseau approuvé; pour B, vérifiez la route héritée avec l'affectation du profil de lancement. Un titre de page, un réglage navigateur ou une réponse réussie ne remplace pas cette vérification. Une route indisponible, une voie directe inattendue ou une exclusion non approuvée échoue, sans poursuivre par une autre route.

Rendez le relevé de sortie assez précis pour répondre à une question opérationnelle sans exposer identifiant ni point de terminaison dans le résultat du travail. Il peut identifier le relevé du fournisseur ou du réseau, le libellé de route, le protocole permis, l'heure et le contexte. Le fournisseur ou le responsable réseau conserve ses données de connexion; le travail applicatif ne garde que la référence et le résultat. Une divergence reste ainsi exploitable sans transformer l'exécution du navigateur en journal réseau non maîtrisé.

La vérification doit correspondre à la requête réellement faite par la charge approuvée. Le résultat d'un contrôle HTTP simple n'établit pas la route d'un flux HTTPS, et le relevé d'un protocole permis n'en couvre pas automatiquement un autre. Si la tâche autorise des exclusions, indiquez leur finalité et leur périmètre exacts. Une exclusion est un chemin attendu distinct, non la preuve de l'usage du proxy. Lorsqu'une version applicative modifie les requêtes ou protocoles, revoyez l'affectation avant d'élargir l'exécution.

Avant l'acceptation, rendez la route de A indisponible et confirmez qu'aucun repli direct ne réussit. Testez une exclusion approuvée seulement dans son périmètre. Avec un brouillon synthétique, vérifiez que l'échec le laisse modifiable, qu'une annulation n'est pas terminée et qu'un résultat serveur incertain est réconcilié avant un nouvel envoi. Ce sont des exigences applicatives, non des garanties du proxy.

Séparez les prérequis produit des résultats applicatifs dans la fiche d'acceptation. Les prérequis sont l'habilitation ENT Tier3 documentée, le profil chargé, l'affectation de route approuvée, le périmètre de requêtes et de protocoles autorisé, ainsi que les mises à jour proxy et géographiques du contexte terminées avant toute page dépendante. Les résultats sont à la fois le résultat attendu de l'application et une référence d'attribution de sortie pour la requête et le protocole exacts. Marquez l'exécution réussie uniquement si tous les prérequis et les deux résultats sont présents; sinon, échouez en mode fermé, arrêtez le contexte concerné, conservez les preuves minimales, restaurez l'affectation approuvée précédente lorsque c'est sûr et réconciliez tout résultat applicatif incertain avant de réessayer.

La fiche de transmission indique les deux contextes, la révision du profil de lancement, la route indépendante, périmètre et exclusions, mode géographique ou surcharges, horaires, résultat de sortie, résultat applicatif et responsable. Excluez identifiants, contenu de navigation et traces complètes.

Voir aussi configuration proxy, changement dynamique de proxy et isolation des comptes. Ces pages ne remplacent pas autorisation, confidentialité ou contrôle des changements.

Sources publiques

• BotBrowser : Per-Context Proxy
• Option proxy de Playwright Browser.newContext
• MDN : serveurs proxy et tunnels