Notes de version de Axe MCP Server version 1.7.0

This page is not available in the language you requested. You have been redirected to the English version of the page.

Link to this page copied to clipboard

Not for use with personal data

Date de sortie

12 octobre 2026

Vue d'ensemble

Cette version v1.7.0 ajoute la prise en charge des réseaux d'entreprise restreints. Si votre organisation exige que le trafic sortant passe par un proxy ou signe ses sites avec sa propre autorité de certification (CA), vous pouvez désormais configurer Axe MCP Server pour qu'il fonctionne avec eux. Si vous n'utilisez aucun des deux, rien ne change pour vous. Cette version explique également les problèmes de démarrage et de navigateur en termes simples.

important

Pour obtenir cette version :

Docker — re-téléchargez l'image : docker pull dequesystems/axe-mcp-server:latest
npm — aucune étape d'installation séparée n'est requise ; npx exécute la dernière version publiée. Voir Choisir une distribution.

Nouvelles fonctionnalités

Prise en charge des proxy

Si votre réseau n'autorise le trafic sortant que via un proxy, tel que Zscaler, vous pouvez désormais définir HTTPS_PROXY (ou HTTP_PROXY pour un serveur axe http://) et le serveur envoie tout son trafic au serveur axe via ce proxy, y compris le démarrage, les vérifications de clé API et la remédiation. Les hôtes listés dans NO_PROXY se connectent directement. Si vous ne définissez pas de proxy, le serveur se connecte directement, comme auparavant.

{
  "env": {
    "HTTPS_PROXY": "http://proxy.example.com:3128",
    "NO_PROXY": "intranet.example.com"
  }
}

Lorsqu'un proxy est configuré, le navigateur qui scanne vos pages l'utilise également. Listez tous les sites intranet que vous scannez dans NO_PROXY. Avec la distribution npm, localhost et d'autres adresses locales se connectent toujours directement, donc les analyses des serveurs de développement locaux ne sont pas affectées. Avec Docker, ajoutez également l'adresse de votre hôte Docker à NO_PROXY. Voir Variables de proxy.
Le navigateur de scan ne peut pas utiliser un proxy qui nécessite un nom d'utilisateur et un mot de passe. Le serveur enregistre un avertissement si vous en configurez un.
Si l'URL du proxy que le serveur utilise n'est pas une adresse http:// ou https:// valide, le serveur s'arrête au démarrage avec un message qui nomme la variable.

Si vous utilisez OAuth 2.0, configurez également NODE_USE_ENV_PROXY=1 afin que l'interface en ligne de commande @deque/axe-auth vous connecte et rafraîchisse les jetons via le proxy. Cela nécessite Node.js 22.21 ou une version ultérieure. Voir Variables de proxy.

Voir Variables de proxy pour plus de détails.

Instructions plus claires pour les certificats non fiables

Lorsqu'un scan échoue parce que le navigateur ne fait pas confiance au certificat de la page, votre agent vous indique maintenant comment le corriger :

Linux et Docker — définissez NODE_EXTRA_CA_CERTS sur la CA qui a signé le certificat, puis redémarrez le serveur.
macOS — ajoutez la CA à votre trousseau de connexion, seulement pour les SSL.
Windows — ajoutez la CA à votre magasin d'autorités de certification racines de l'utilisateur actuel, seulement pour les SSL.

Voir Certificats non fiables pour les étapes complètes.

Les délais d'IGT indiquent où l'exécution s'est arrêtée

Lorsqu'un Test guidé intelligent est en attente, l'erreur indique désormais la dernière étape atteinte et depuis combien de temps, ce qui facilite grandement le diagnostic d'un test bloqué :

IGT timed out after 200000ms (last checkpoint: keyboard:tabstops:start 83s ago; last step: analyze-tabstops-ai 61s ago; last tick 2s ago)

Corrections de bugs

Les certificats CA personnalisés fonctionnent maintenant dans le navigateur de scan sur Linux et Docker. Auparavant, NODE_EXTRA_CA_CERTS n'atteignait jamais le navigateur, donc les pages signées par une CA interne échouaient lors de l'analyse.
Configurer NODE_EXTRA_CA_CERTS n'arrête plus le démarrage sur macOS et Windows. Le serveur démarre maintenant normalement et vous indique quel magasin de certificats système utiliser à la place.
Le démarrage explique pourquoi un Chrome personnalisé ne peut pas se lancer. Si AXE_CHROME_PATH pointe vers un navigateur qui ne peut pas démarrer, le serveur indique maintenant pourquoi. Auparavant, il signalait le navigateur comme manquant.
Les bibliothèques système manquantes sont signalées lorsque vous utilisez un Chrome personnalisé. Lorsque AXE_CHROME_PATH est configuré, les erreurs de lancement conservent leur diagnostic complet, y compris la correction pour les bibliothèques Linux manquantes.
Les erreurs de configuration sont lisibles. Un paramètre invalide produit maintenant un message qui nomme le paramètre, au lieu d'une trace de pile brute AssertionError.
Liens de documentation cassés corrigés dans les messages du serveur.