Un proxy local à l’écoute à côté d’une application ne reproduit pas un réseau qui exige un accès par proxy. L’application peut ignorer le proxy configuré, se connecter directement et néanmoins signaler un succès.

Séparez le réseau de l’application du chemin sortant du proxy. Une disposition à base de conteneurs place l’application uniquement sur un réseau interne et donne au proxy un second réseau de sortie. Dans une définition Compose existante, les rattachements réseau peuvent ressembler à ceci :

services:
  app:
    networks: [clients]
  proxy:
    networks: [clients, egress]
networks:
  clients:
    internal: true
  egress: {}

Il s’agit d’un fragment de réseau pour des services déjà définis. Configurez séparément le proxy de transfert approuvé et le client réel de l’application. Docker documente les réseaux internes comme isolés de l’extérieur ; seul le proxy dispose du réseau extérieur supplémentaire dans cette disposition.

Ajoutez un cas négatif sans usage du proxy : la requête externe de l’application doit échouer. Pour un proxy HTTP authentifié, un compte refusé doit produire son échec d’authentification, tandis que le compte accepté doit atteindre la cible avec une observation correspondante du proxy.

Testez séparément les cas autorisés et les cas refusés du proxy. Gardez l’application hors des autres réseaux externes et évitez d’ajouter un mode réseau hôte qui contourne le proxy. Une requête réussie n’est une preuve utile qu’une fois que le test expose bien le chemin prévu.

Articles similaires