Bases, stockage, routing

Redirections d'URL

Rediriger un sous-domaine Network ou Customer vers une route applicative existante, via un composant HAProxy mutualisé.

Version v1.04 min de lecture

Redirections d'URL

📍 Où trouver ça dans l'UI

Niveau Network : Organisation → Réseaux → configuration d'un réseau → Redirections d'URL

Niveau Customer : Organisation → Clients → configuration d'un client → Redirections d'URL

Une redirection d'URL est une ressource déclarée à un niveau Network ou Customer (scopeType: NETWORK | CUSTOMER, jamais les deux à la fois) qui répond HTTP 302 sur une URL "source" vers une URL "destination" pointant vers une route existante d'une app, dans un environnement donné.

Contrairement au routing applicatif standard (voir URLs et routing), une redirection ne route pas de trafic applicatif : elle se contente de rediriger le navigateur vers l'URL finale.

Bloc Source — immuable après création

Champ	Description
Domaine	Un domaine `CUSTOM` appartenant à l'app, ou un domaine `PLATFORM_MANAGED` commun à toute la plateforme (ex. `y.wakastart.app` sur dev)
Sous-domaine	Un label unique, validé comme les sous-domaines de service (caractères DNS valides, un seul label — pas de points)

L'URL source réelle n'est pas saisie : elle est calculée automatiquement à partir du sous-domaine, du domaine, et — si le domaine est PLATFORM_MANAGED — du shortname de l'app :

<sous-domaine>.<préfixe-env-cible?>.<shortname-app-si-domaine-plateforme?>.<domaine>

Important : le préfixe d'environnement inséré dans l'URL source vient de l'environnement CIBLE choisi dans le bloc Destination — il n'existe pas d'environnement propre à la source. Conséquence directe : changer l'environnement cible d'une redirection change son URL source (le DNS est migré automatiquement), sans jamais toucher à l'URL ni à l'infra de la destination elle-même.

Exemple concret :

text
Sous-domaine       : monclient
Domaine            : y.wakastart.app (PLATFORM_MANAGED)
App shortname      : 7owwaa
Env cible (préfixe): dev

→ URL source : monclient.dev.7owwaa.y.wakastart.app

Deux redirections peuvent partager le même sous-domaine + domaine tant que leurs environnements cibles ont des préfixes différents — il n'y a alors aucune collision DNS réelle (le préfixe d'env fait partie du FQDN final).

Bloc Destination — éditable à tout moment

Champ	Description
Route (AppRoute)	Route existante de l'app à cibler
Environnement	Environnement dans lequel la route est provisionnée
Path	Chemin ajouté à l'URL de destination (optionnel)
Query string	Paramètres de requête ajoutés à l'URL de destination (optionnel)

Le domaine/host de la destination n'est jamais saisi manuellement : il découle exclusivement de la route + de l'environnement sélectionnés, recalculé automatiquement à chaque changement.

Important : modifier la destination (route, environnement, path ou query) ne déploie et ne modifie jamais l'infra réelle de cette destination. L'AppUrl / la route cible reste gérée exclusivement par l'architecture applicative de l'app — la redirection ne fait que mettre à jour sa propre configuration HAProxy interne.

Statuts

Cycle de vie standard des ressources Wakastart :

Statut	Signification
`PENDING`	Redirection créée en DB, en attente de traitement par l'operator
`PROVISIONING`	Ressources K8s en cours de création
`PROVISIONED`	Redirection active — l'URL source répond bien en 302 vers la destination
`FAILED`	Échec du provisioning
`DESTROYING`	Suppression en cours
`DESTROYED`	Redirection supprimée

Un drift est détecté si l'URL réelle de la route cible a changé depuis la dernière réconciliation (par exemple si l'app a modifié son architecture entre-temps) — la redirection reste fonctionnelle mais nécessite une resynchronisation.

Mécanisme technique

Le routing applicatif classique de Wakastart passe par Gateway API + Istio, via une HttpRoute avec un filtre RequestRedirectFilter pour les redirections simples. Ce mécanisme ne suffit pas ici : Gateway API ne supporte pas la réécriture de query string dans une redirection, or les redirections Wakastart doivent pouvoir ajouter/modifier des paramètres de requête.

Un composant HAProxy dédié et mutualisé pour toute la plateforme (namespace wakastart-redirects) prend donc en charge la réécriture effective :

text
https://monclient.dev.7owwaa.y.wakastart.app
            │
            ▼
   DnsRecord + ListenerSet + HttpRoute (standard, côté API infra)
            │
            ▼
   HttpRoute route vers le Service HAProxy partagé
   (au lieu du Service applicatif classique)
            │
            ▼
   HAProxy lit sa map (host → URL cible) et répond 302
            │
            ▼
   https://<host-calculé-de-la-route-cible>/<path>?<query>

Chaque redirection crée donc, côté ws-serv-infra, les mêmes ressources standard qu'une route applicative (DnsRecord, ListenerSet, HttpRoute) — seule différence : la HttpRoute pointe vers le service HAProxy partagé plutôt que vers un ServiceInstance applicatif.

La configuration effective (mapping host → URL cible) est un fichier map_str généré par l'operator et poussé dans une ConfigMap. Chaque changement (création, modification de destination, suppression) déclenche un rollout automatique du déploiement HAProxy pour recharger la map à jour.

Limites connues

RBAC : pas de contrôle d'accès fin au-delà de WakaAdmin / OwnerAdmin (accès complet aux redirections), en plus du cloisonnement Network/Customer standard.
Plafond : 20 redirections maximum par scope. Il s'agit d'une limite de sécurité technique actuelle, sans justification fonctionnelle — elle peut évoluer.
Suppression : contrairement aux autres ressources infra qui bloquent leur suppression tant que des enfants existent, supprimer une redirection ne bloque jamais sur l'état de sa destination — la route/l'environnement ciblé n'est pas affecté.