Build

Vous pouvez soit compiler l'outil une fois et utiliser le binaire résultant, soit l'exécuter "comme un script" (la chaîne d'outils Go le compilera à la volée). Pour le développement, cette dernière option est pratique. Pour une utilisation en production, il est recommandé de le compiler une fois (depuis le répertoire cli) et d'utiliser l'exécutable résultant. Grâce au compilateur Go, vous pouvez compiler depuis et pour Linux ou Windows. Au moins la version 1.18 de Go est nécessaire pour la compilation (testé avec Go 1.23).

Compilation depuis Linux

Pour compiler depuis Linux pour Windows ou Linux, définissez simplement GOOS de manière appropriée (exécutez depuis le répertoire cli) :``` GOOS=windows GOARCH=amd64 go build -o wcfproxy.exe

GOOS=linux GOARCH=amd64 go build -o wcfproxy

## Compilation depuis Windows
Pour compiler depuis Windows, exécutez les commandes équivalentes, par exemple depuis PowerShell :```
$env:GOOS='windows'; $env:GOARCH='amd64'; go build -o wcfproxy.exe

RÈGLES CRITIQUES :

• Traduire UNIQUEMENT le texte en langage naturel. NE JAMAIS traduire : code, commandes de terminal, chemins de fichiers, URLs, noms de paquets, identifiants CVE, noms de variables d'environnement, identifiants.
• Préserver INTACTE la structure Markdown : titres, listes, listes imbriquées, tableaux (y compris l'alignement), liens, images, code en ligne, blocs de code, citations, blocs HTML et règles horizontales.
• Préserver la mise en forme exacte : espaces, sauts de ligne, indentation, nombre de colonnes des tableaux et marqueurs d'alignement.
• Préserver les badges, boucliers et images d'état EXACTEMENT tels quels.
• NE JAMAIS ajouter, supprimer ou modifier la ponctuation qui pourrait modifier le comportement du code.
• Retourner UNIQUEMENT le texte traduit. AUCUN préambule, AUCUN « Voici la traduction », AUCUN « Bien sûr ! », AUCUNE explication, AUCUN commentaire, AUCUN méta-texte.
• NE JAMAIS encapsuler votre réponse dans des blocs de code Markdown.
• NE JAMAIS produire de JSON, YAML, XML, tableaux, objets, wrappers clé/valeur, schémas ou champs comme « translated », « language », « markdown », « content » ou « result ».
• Votre réponse doit être uniquement du contenu brut en Markdown/texte brut. Si la source contient des exemples JSON/YAML/XML à l'intérieur de blocs de code, préservez ces exemples textuellement dans le Markdown ; ne transformez pas la réponse entière en un objet structuré.
• Ne posez pas de questions. N'engagez pas de conversation.
• Si vous ne pouvez pas traduire un terme technique en toute sécurité, laissez-le non traduit plutôt que de risquer de le casser.

TRADUIRE :``` $env:GOOS='linux'; $env:GOARCH='amd64'; go build -o wcfproxy

# Utilisation

La configuration pour `wcfproxy` est fournie via un fichier JSON.
Par défaut, le fichier de configuration `config.json` est utilisé, mais le chemin vers un fichier de configuration peut être spécifié avec le paramètre `-config`.
Le fichier de configuration est destiné à contenir un nombre arbitraire de configurations nommées, comme ceci :```json
{
	"my-config": { 
        " ... ": " ... " 
    }
}

La valeur des objets de configuration nommés doit correspondre à la structure Config (voir Config structure). Ce fichier source avec les commentaires inclus sert également de documentation la plus précise pour les options de configuration de wcfproxy. Parmi toutes les configurations fournies, celle à utiliser est identifiée par son nom via l'option de ligne de commande -enable :``` wcfproxy.exe -config config.json -enable my-config

## Structure de la configuration
La structure de plus haut niveau de chaque objet de configuration est la suivante :```json
{
	"listen": "[::1]:8000",
	"connect": "[::1]:9000",
	"retarget": "net.tcp://127.0.0.1:8000/WCFLab/WCFDemoService/nettcp",
    "retarget-map": {
        "nettcps": "net.tcp://localhost:8210/WCFLab/WCFDemoService/nettcps",
        "winauth": "net.tcp://localhost:8220/WCFLab/WCFDemoService/nettcp-winauth"
    },
	"log-level": "debug|info|warn|error",
	"log-file": "path/to/log/file",
	"tls-server": {
        " ... ": " ... " 
    },
	"tls-client": {
         " ... ": " ... "
    },
	"ntlm": {
         " ... ": " ... "
    },
	"interceptor": {
         " ... ": " ... "
    },
	"ctrl": {
         " ... ": " ... "
    }
}

Note that TLS configuration (tls-server and/or tls-client) ne peut pas être fournie si une configuration NTLM est présente.

Options de configuration

• listen - le point d'extrémité TCP sur lequel wcfproxy doit écouter, par ex. 127.0.0.1:8000 ou [::1]:8000
• connect - le point d'extrémité TCP du serveur WCF en amont, par ex. 127.0.0.1:9000 ou [::1]:9000
• retarget - spécification de cible d'origine (et solution de repli pour retarget-map) ; pour une explication, voir Réécriture de cible
• retarget-map - généralisation de retarget ; permet de réécrire la cible pour plusieurs points d'extrémité (utile uniquement si l'on travaille avec plusieurs services WCF sur le même port)
  • si l'une des clés dans retarget-map correspond à la cible actuelle, l'URI cible sera remplacée par la valeur donnée pour la communication en amont
  • si aucune clé dans retarget-map ne correspond à la cible actuelle, retarget sera utilisé à la place
• log-level - niveau de journalisation ; valeurs disponibles : debug, info (par défaut), warn, error
• log-file - chemin vers le fichier de journalisation ; si aucun chemin n'est fourni, la journalisation se fait sur stdout
• tls-server - instance de TlsServerConfig (voir Configuration du serveur TLS) ; requise uniquement si la mise à niveau TLS doit être prise en charge
• tls-client - instance de TlsClientConfig (voir Configuration du client TLS) ; pertinente uniquement si la mise à niveau TLS doit être prise en charge
• ntlm - instance de NtlmConfig (voir Configuration NTLM) ; requise uniquement si la mise à niveau NTLM (directement ou via SPNEGO) doit être prise en charge
• interceptor - instance de InterceptorConfig (voir Configuration de l'intercepteur) ; obligatoire
• ctrl - instance de ControlServerConfig (voir Configuration du serveur de contrôle) qui peut fournir un serveur HTTP de base par défaut (utile avec l'intercepteur HTTP) ainsi qu'une petite API pour contrôler le flux de messages (encore en développement)

Configuration du serveur TLS

La configuration côté serveur TLS permet de contrôler les paramètres de serveur TLS les plus typiquement pertinents. Elle a la structure suivante :```json { "cert-pem": "path/to/certificate", "cert-key": "path/to/certificate-key", "max-version": "1.0|1.1|1.2|1.3", "min-version": "1.0|1.1|1.2|1.3", "client-roots": "path/to/client-ca1,path/to/client-ca2", "client-auth": "none|request|require-any|verify-if-given|require-and-verify", "keylog": "path/to/keylog-file" }

#### Options de configuration du serveur TLS
+ `cert-pem` - chemin vers le certificat X.509 (au format PEM)
+ `cert-key` - chemin vers la clé correspondante pour le certificat
+ `max-version` - version TLS maximale acceptable ; l'une de `1.0`, `1.1`, `1.2`, `1.3` (par défaut)
+ `min-version` - version TLS minimale acceptable ; l'une de `1.0` (par défaut), `1.1`, `1.2`, `1.3`
+ `client-roots` - liste séparée par des virgules de chemins vers les certificats racine acceptables (PEM) pour l'authentification client ; optionnel
+ `client-auth` - politique d'authentification client ; valeurs les plus utiles : `none` (par défaut), `require-and-verify`
+ `keylog` - fichier pour écrire les secrets TLS au format NNS