Cognitive Overhead

Cet article est la suite de la première partie : "Créer un proxy personnalisé avec launchd (1/2)"

Coder votre proxy personnalisé.

C'est théoriquement l'étape du travail la plus intéressante, puisque c'est ici que l'on peut exprimer toute sa créativité, et surtout apporter la réponse à un de ses problèmes. Comme le programme sera lancé à la demande par launchd, et que c'est ce dernier qui va gérer le socket de communication avec le client, la tâche est simplifiée. En contrepartie, le programme ne peut pas être trop lourd, car des lancements à répétition seraient alors pénalisants pour le reste du système.
Mac OS X est livré avec de nombreux langages de script et de programmation (C, Java, PHP, Python, Ruby, Perl, Shell…). Contrairement à mon habitude, j'ai choisi de coder mon proxy en PHP. De la sorte, je pouvais réutiliser mon code dans un autre contexte au cas où le fonctionnement en proxy ne donnait pas satisfaction.
Voici le squelette de mon script PHP, à titre d'exemple :

#!/usr/bin/php
<?php
// get request from http client
$request = explode(" ", trim(fgets(STDIN)));
$MyGET = $request[1];
// curl request
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $MyGET);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$output = curl_exec($ch);
// cleanup
curl_close($ch);   

// callback
function fetch_author($matches) {
    ../..
    return $matches[1].$matches[2].$author[1]." ".$matches[3];
}

// html parsing
$apresreplace = preg_replace_callback('/.../',"fetch_author",$output);

// output
echo $apresreplace;
?>

J'ai volontairement simplifié et tronqué mon code. La seule chose qui compte est le squelette du programme. Première remarque, le script fonctionne en mode "ligne de commande". C'est du PHP, mais il ne sera pas interprété par Apache, donc les variables intéressantes de $_SERVER, de $_GET, ... n'existent pas. Je récupère la requête du client HTTP en lisant tout simplement la première ligne de STDIN.
Ensuite, j'utilise les fonctions de la librairie CURL pour aspirer le contenu distant qui correspond à l'URL transmise par le client. Puis je fais sur ce contenu un rechercher-remplacer via la fonction preg_replace_callback et via la fonction attachée que j'ai créée (dite fonction de callback).
Les détails ne sont pas importants, à ce stade ce qu'il faut bien comprendre, c'est que mon script de proxy a reçu l'URL demandée par le client. Il a téléchargé le contenu correspondant à cette URL, et il l'a enrichi selon mes besoins. La dernière ligne du script renvoie dans la sortie standard le contenu enrichi. Le client (mon lecteur de flux RSS) reçoit alors la réponse à sa requête.

Lancer le proxy à la demande

Launchd est l'outil idéal pour lancer le proxy dès qu'une connexion est initiée dans sa direction. Le fonctionnement est alors similaire à inetd (ou xinetd). La problématique est la même que dans le cas de la création d'un tunnel ssh à la demande, donc je passe sur les détails.
Voici le fichier plist de configuration qu'il faut charger dans launchd pour activer le proxy :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Debug</key>
        <false/>
        <key>Label</key>
        <string>tld.monsuper.proxy</string>
        <key>ProgramArguments</key>
        <array>
                <string>/chemin/du/programme/de/proxy</string>
        </array>
        <key>Sockets</key>
        <dict>
                <key>Listeners</key>
                <dict>
                        <key>SockNodeName</key>
                        <string>127.0.0.1</string>
                        <key>SockServiceName</key>
                        <string>8080</string>
                        <key>SockType</key>
                        <string>stream</string>
                </dict>
        </dict>
        <key>StandardErrorPath</key>
        <string>/tmp/proxy.err</string>
        <key>inetdCompatibility</key>
        <dict>
                <key>Wait</key>
                <false/>
        </dict>
</dict>
</plist>

Après avoir adapté le Label, le chemin du programme, le port de connexion, et éventuellement le fichier de stderr, il faut enregistrer ce fichier plist dans ~/Library/LaunchDaemons/ (pour vous seul) ou dans /Library/LaunchDaemon/ (pour tous les utilisateurs de la machine). Ensuite il faut le charger via launchctl load /chemin/du/fichier.plist.

C'est terminé. Toutes les briques du proxy personnalisé sont en place. Le client (si il honore bien les préférences systèmes) utilisera le proxy désigné dans le fichier .PAC. Launchd recevra la requête et la transmettra au programme du proxy. Ce dernier fera les traitements sur les données téléchargées, et renverra le résultat au client.

edit : style et coquilles
edit : ajout de l'IP 127.0.0.1 pour le bind, ça évite que le proxy puisse êtes utilisé par n'importe qui sur le réseau… :)

Related posts

Liste francophone des scripts shell

"builtin" : quelques subtilités

Quelques notions sur les boucles dans bash

Gadget Apple pour le monitoring : BigTop

Pourquoi un proxy personnalisé ?

De temps en temps, on aimerait modifier pour son confort personnel des flux de données que l'on ne maîtrise pas. Ces derniers jours par exemple, j'ai été confronté à un flux RSS qui ne contient pas toutes les données dont j'ai besoin. J'ai donc créé un proxy HTTP personnalisé pour enrichir le flux RSS et obtenir un résultat complètement satisfaisant.
On peut bien sûr appliquer le même principe à tout un tas de choses. Le gros avantage de l'opération, c'est que l'on est libre de coder avec le langage de son choix, sans se compliquer la vie : launchd prend en charge la partie "réseau local" et les préférences système s'occupent de publier les réglages de proxy auprès des clients. Il ne reste finalement à s'occuper que de la partie intéressante du code : la transformation des données reçues (ou envoyées).

Vue d'ici, la partition peut sembler complexe à jouer : il faut faire communiquer un client avec un serveur au travers d'un proxy lancé à la demande par launchd, le tout en s'appuyant sur les préférences système de proxy. Il y a donc quelques pré-requis de base. Il faut que la version de Mac OS X supporte la configuration automatique de proxy (testé sur 10.5 et 10.6). Et il faut aussi que le client supporte l'utilisation des proxy définis dans les préférences système.

Configurer les préférences de proxy de Mac OS X.

Il s'agit de ne pas de faire passer tout le trafic au travers de notre script maison, mais seulement des requêtes bien particulières. On utilise pour cela les préférences de configuration automatique de proxy. La configuration automatique de proxy s'appuie sur un fichier en javascript, qui fournit les règles de proxy que l'on souhaite utiliser. Normalement ce fichier est distribué automatiquement via DHCP, ou mis à disposition sur le réseau via une URL standardisée. Ici, nous allons procéder à la main.
La première étape consiste à créer un fichier PAC contenant les règles souhaitées. C'est un simple fichier texte. Voici le contenu du fichier "proxy.pac" que j'ai créé pour répondre à mes besoins :

function FindProxyForURL(url, host) {
      if (shExpMatch(url, "*cfsl.net/forum*/feed.php*"))    {
         return "PROXY localhost:8080";
      } 
      // All other requests go directly to the WWW:
      return "DIRECT";

Le fichier décrit les règles suivantes :
- si l'URL que je demande contient *cfsl.net/forum*/feed.php*, alors utilise le proxy à l'adresse localhost:8080.
- dans tous les autres cas, n'utilise pas de proxy.

Vous trouverez d'autres exemples de fichiers PAC sur wikipedia et ailleurs.

La seconde étape est l'activation de ces règles dans les préférences système. Il faut pour cela ouvrir les préférences réseau, et entrer dans les paramètres avancés de l'interface réseau active. Sous l'onglet "Proxy", on retrouve une case à cocher correspondant au mécanisme de configuration automatique de proxy. Il faut cocher cette case, et désigner le chemin du fichier PAC créé à la première étape :

Et voilà, maintenant il ne reste plus qu'à créer le programme de proxy et son plist de lancement.
Lire la suite !

Related posts

Liste francophone des scripts shell

"builtin" : quelques subtilités

Quelques notions sur les boucles dans bash

Gadget Apple pour le monitoring : BigTop