Middlewares — Pièges et Solutions

Un middleware (une « couche », layer dans Tower) enveloppe le service suivant. La requête traverse les couches de l'extérieur vers l'intérieur, la réponse les retraverse dans l'autre sens.

Une couche peut :

Conséquence : une couche ne peut utiliser que ce qu'ont préparé les couches plus extérieures. Le CSRF lit la session : la session doit être à l'extérieur du CSRF.

Ce piège a causé un bug pendant la construction de Runique : le CSRF se retrouvait à l'extérieur de la session. Il cherchait un jeton dans une session pas encore chargée, et refusait toutes les requêtes POST en 403, sans message clair.

Le bug ne se voit pas toujours tout de suite : si le CSRF est désactivé ou contourné en développement, il peut arriver en production sans avoir jamais été visible.

Plutôt que de dépendre de l'ordre d'écriture, Runique attribue à chaque middleware un numéro de slot fixe. Au moment du build, les couches sont triées par slot et appliquées dans le bon ordre, quel que soit l'ordre dans lequel le développeur les configure.

Lecture : un slot bas est extérieur. La requête traverse dans l'ordre croissant :

Chaque position a une raison, écrite dans le commentaire :

Technique : le tri par slot transforme une règle que le développeur devait retenir en une règle que le framework applique. C'est la même idée que les types de colonnes (une faute devient impossible) ou le typestate du builder (cours traits-avances).

La protection CSRF repose sur un jeton secret lié à la session, que chaque formulaire doit renvoyer. Le middleware CSRF doit lire ce jeton pour valider une requête POST.

Les slots fixent Session(50) → SessionUpgrade(55) → Auth(57) → CSRF(60). Le CSRF est toujours actif : il n'y a pas de méthode pour le désactiver globalement.

La seule exception prévue est explicite et limitée à des chemins précis, pour les points d'entrée appelés par un service tiers qui signe ses requêtes :

RuniqueAppBuilder::new(config)
    .middleware(|m| {
        m.csrf_exempt(vec!["/webhook/stripe", "/webhook/github"])
    })

Ces routes doivent alors vérifier elles-mêmes la signature du service (en temps constant) : l'exemption remplace une protection par une autre, elle ne la supprime pas.

Ajouter un en-tête X-Temps-Reponse à chaque réponse.

use axum::{extract::Request, middleware::Next, response::Response};
use std::time::Instant;

// 1. Une fonction async avec from_fn (le plus simple)
async fn temps_reponse(req: Request, next: Next) -> Response {
    let debut = Instant::now();
    let mut reponse = next.run(req).await;                 // avant : rien ; après : on modifie la réponse
    let ms = debut.elapsed().as_millis().to_string();
    if let Ok(v) = ms.parse() {
        reponse.headers_mut().insert("x-temps-reponse", v);
    }
    reponse
}

let app = axum::Router::new()
    .route("/", axum::routing::get(|| async { "ok" }))
    .layer(axum::middleware::from_fn(temps_reponse));

// 2. Avec un état partagé : from_fn_with_state
#[derive(Clone)]
struct Etat { prefixe: &'static str }

async fn avec_etat(
    axum::extract::State(etat): axum::extract::State<Etat>,
    req: Request,
    next: Next,
) -> Response {
    tracing::info!("{} {}", etat.prefixe, req.uri());
    next.run(req).await
}

// .layer(axum::middleware::from_fn_with_state(Etat { prefixe: "web" }, avec_etat))

// 3. Une couche de tower-http toute faite
// .layer(tower_http::timeout::TimeoutLayer::new(Duration::from_secs(10)))

Le corps d'une requête est un flux : les octets arrivent du réseau et sont consommés à la lecture. Il n'y a pas de retour en arrière.

async fn handler(req: axum::extract::Request) {
    let corps = axum::body::to_bytes(req.into_body(), 2 * 1024 * 1024).await;
    // req a été consommée par into_body : il n'existe plus de corps à lire
}

Le système de types le montre : into_body(self) prend la requête. Impossible de la relire, c'est une erreur de compilation.

Si un middleware lit le corps (pour journaliser, valider...), le handler reçoit un corps vide, sauf à le reconstruire.

Le corps n'est lu qu'une seule fois, par l'extracteur Request. C'est pour cela que Request est toujours le dernier paramètre d'un handler : axum exige que l'extracteur qui consomme le corps soit le dernier.

Les données analysées sont gardées dans la requête (request.prisme), et request.form("nom") construit le formulaire à partir d'elles, sans relire le flux. Les middlewares ne touchent jamais au corps ; ce dont ils ont besoin passe par les extensions (section 5.3).

pub async fn connexion(request: Request) -> AppResult<Response> {
    let form: LoginForm = request.form("login");   // rempli depuis les données déjà analysées
    // ...
}

Les limites de taille sont vérifiées avant et pendant cette lecture unique (en-tête Content-Length, puis limite pendant la lecture : 2 Mo pour un formulaire, RUNIQUE_MAX_UPLOAD_MB par fichier, RUNIQUE_MAX_BODY_MB pour la requête entière) : un corps trop gros est refusé en 413 sans avoir été chargé en mémoire.

À l'affichage (GET), le remplissage ignore les champs password : un mot de passe n'est jamais réaffiché dans la page. À la soumission (POST, PUT, PATCH), request.form("nom") les remplit comme les autres champs.

add_value(nom, valeur) pose une valeur depuis le code (pré-remplissage, colonne que le visiteur ne choisit pas) :

let mut form: LoginForm = request.form("login");
form.add_value("username", &valeur);

Il est tentant de n'écrire que le handler POST. Mais le formulaire HTML doit d'abord avoir été affiché : c'est à ce moment que le jeton CSRF masqué et le nom du formulaire sont insérés dans la page.

// Seul un POST : la page qui contient le formulaire n'a jamais été rendue par Runique,
// le navigateur n'a donc ni jeton CSRF, ni nom de formulaire à renvoyer.

Les middlewares configurés par le builder (session, CSRF, CSP, validation de l'hôte...) s'appliquent à toutes les routes. C'est voulu : une protection de sécurité qui comporte des exceptions est une faille potentielle, et une route oubliée ne doit pas se retrouver sans protection.

Pour un besoin propre à une route, Runique fournit des extensions de routeur. Exemple réel, la limite de tentatives sur la suppression de compte de runique.io :

// demo-app/src/url.rs (extrait)
.rate_limit(
    "/profil/supprimer",
    "supprimer_compte",
    view!(supprimer_compte),
    3,                       // au plus 3 requêtes...
    300,                     // ...par fenêtre de 300 secondes
    vec![Method::POST],      // seules les soumissions comptent
)

rate_limit crée le limiteur, le pose en route_layer sur cette seule route, et lance son nettoyage périodique (cours concurrence, section 13). Pour une couche quelconque, route_layer sur un Router axum reste possible.

Pendant le développement, une URL inexistante ne renvoyait pas 404 : elle redirigeait vers /admin/login.

GET /une-page-qui-nexiste-pas  →  302  →  /admin/login

La garde d'authentification de l'admin était posée avec layer sur tout le routeur : elle interceptait toutes les requêtes non authentifiées, y compris celles qui ne correspondaient à aucune route (section 8.1), avant que le routeur puisse répondre 404.

Requête → garde admin (redirige si non connecté) → routeur (jamais atteint)

La garde ne doit concerner que les routes de l'admin : elle est posée en route_layer, sur les seules routes de l'admin.

let admin = axum::Router::new()
    .route("/admin/{*chemin}", axum::routing::get(handler))
    .route_layer(axum::middleware::from_fn(garde_admin));

Dans l'admin actuel, cette garde est declared_route_access (runique/src/admin/middleware/admin_middleware.rs), posée sur les routes de l'admin seulement. Les routes publiques ne sont plus interceptées, et les 404 remontent normalement jusqu'au gestionnaire d'erreurs.

Un flash message est stocké en session pour être affiché à la requête suivante, typiquement après une redirection.

success!(request.notices => "Profil mis à jour.");
return Ok(Redirect::to("/profil").into_response());
// stocké en session → affiché sur /profil, puis effacé

C'est le schéma « POST, puis redirection, puis GET » : recharger la page après la redirection ne renvoie pas le formulaire une seconde fois.

Une détection automatique (stocker en session si la réponse est une redirection, injecter sinon) demanderait d'inspecter la réponse après le handler, puis de modifier le rendu déjà produit. Le choix explicite entre deux écritures reste plus simple et plus prévisible.

Dans quel ordre la requête traverse-t-elle ces couches ?

Router::new()
    .route("/", get(h))
    .layer(a)
    .layer(b)
    .layer(ServiceBuilder::new().layer(c).layer(d));

Réponse : c, d, b, a, puis le handler. Le ServiceBuilder est ajouté en dernier, donc il est le plus extérieur, et à l'intérieur de lui, c est avant d.

Écris un middleware qui refuse en 401 une requête sans en-tête x-cle-api égal à une clé connue, en comparant en temps constant.

// Solution :
use subtle::ConstantTimeEq;

async fn cle_api(req: Request, next: Next) -> Response {
    const CLE: &[u8] = b"cle-secrete-de-demo";
    let fournie = req.headers().get("x-cle-api").map(|v| v.as_bytes()).unwrap_or(b"");
    if fournie.ct_eq(CLE).unwrap_u8() == 0 {
        return axum::http::StatusCode::UNAUTHORIZED.into_response();
    }
    next.run(req).await
}

ct_eq compare tous les octets quelle que soit la position de la première différence : la durée ne révèle pas le début correct de la clé. (Une clé réelle se lit depuis la configuration, jamais en dur dans le code.)

Une garde qui redirige vers la page de connexion est posée avec .layer() sur le routeur public. Quel est le symptôme, et la correction ?

Réponse : toute URL inexistante redirige vers la connexion au lieu de renvoyer 404 (section 9). Correction : .route_layer(), sur les seules routes protégées.