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.07 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 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é. Elle peut être déclarée à trois niveaux (scopeType), exclusifs entre eux :

Scope	Qui la déclare	Cas d'usage typique
`NETWORK`	Un réseau (tenant en aval de l'app)	Redirection au niveau d'un réseau
`CUSTOMER`	Un client (tenant en aval de l'app)	Redirection au niveau d'un client
`APP`	L'équipe de l'app elle-même	`www.monsupersite.com` ↔ `monsupersite.com`

Les scopes NETWORK et CUSTOMER — décrits dans le reste de cette page — désignent les tenants en aval de l'app et restent inchangés. Le scope APP, décrit plus bas, concerne l'app elle-même ; c'est un modèle dédié, pas une variante des deux autres.

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.

Redirections à l'échelle de l'app (App-scope)

Les scopes NETWORK et CUSTOMER ci-dessus s'adressent aux tenants en aval de l'app. Le scope APP répond à un autre besoin : permettre à l'équipe de l'app elle-même de rediriger une URL vers une autre au sein de sa propre app — typiquement basculer entre www.monsupersite.com et monsupersite.com.

Un modèle dédié, pas une extension des scopes existants. Le scope APP s'appuie sur des ressources qui lui sont propres (AppUrlRedirect / AppUrlRedirectInstance). Les redirections NETWORK/CUSTOMER ne sont pas modifiées et restent gérées comme décrit plus haut.

Réservé aux domaines CUSTOM. Comme pour l'apex (voir URLs et routing), une redirection App-scope n'est possible que sur un domaine CUSTOM rattaché à l'app — jamais sur un domaine PLATFORM_MANAGED partagé.

AppUrlRedirect (Architecture) → AppUrlRedirectInstance (par environnement)

Comme le reste de l'architecture, une redirection App-scope se déclare une fois, sans jamais choisir d'environnement, puis s'instancie par environnement :

Niveau	Ressource	Ce que tu décris
Architecture	`AppUrlRedirect`	La source (domaine `CUSTOM` + sous-domaine source, ou l'apex si aucun sous-domaine) et la cible : soit une URL existante de l'app, soit son apex.
Environnement	`AppUrlRedirectInstance`	La matérialisation de cette redirection dans un environnement donné — c'est là que le provisioning réel a lieu.

La cible reste toujours au sein de la même app : une URL déjà déclarée dans l'architecture, ou l'apex de l'app. Il n'y a donc pas de redirection ouverte possible — la destination est résolue côté serveur.

Même mécanisme technique

Une redirection App-scope réutilise exactement le composant HAProxy mutualisé (wakastart-redirects) décrit ci-dessus : mêmes ressources standard côté API infra (DnsRecord, ListenerSet, HttpRoute pointant vers le service HAProxy partagé), même map host → URL cible rechargée à chaque changement. Rien de spécifique à provisionner.

Avertissement à la source apex. Si la source d'une redirection App-scope est l'apex (aucun sous-domaine), la même modale de confirmation bloquante que pour l'exposition à la racine (voir URLs et routing) s'applique : la plateforme ne vérifie pas ce qui résout déjà sur ce domaine. Un domaine ne peut d'ailleurs pas porter à la fois un apex et une redirection App-scope apex-source.

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é.