Atterrissage après connexion

Après la connexion, différents utilisateurs devraient atterrir sur différentes pages — un administrateur sur l'accueil d'administration, un client sur son propre enregistrement. Sovrium exprime cela comme une configuration d'authentification, et non comme une logique de redirection éparpillée dans les pages : chaque rôle déclare un defaultLanding, le bloc auth déclare un point de montage landingPath, et noAccessPath récupère quiconque ne correspond à rien.

app.yaml

auth:
  strategies:
    - type: emailAndPassword
  scopeTables: [clients]
  defaultRole: customer-admin
  landingPath: /portal
  noAccessPath: /403
  roles:
    - name: engineer
      defaultLanding: /admin
    - name: customer-admin
      defaultLanding: /portal/clients/$currentUser.assignments.clients[0]
      pickerLanding: /portal/select/clients

Champs de configuration

Deux champs sur auth, deux sur chaque rôle :

Champ	Niveau	Description
`landingPath`	`auth`	Chemin de montage du résolveur de moteur. Les sessions qui naviguent ici sont redirigées vers le `defaultLanding` du rôle correspondant. Doit commencer par `/`. Obligatoire dès qu'un rôle définit `defaultLanding` ou `pickerLanding`.
`noAccessPath`	`auth`	Chemin de repli lorsqu'aucun `defaultLanding` de rôle ne correspond à la session. Doit commencer par `/`. Par défaut `/403`.
`defaultLanding`	`roles[]`	URL d'atterrissage par rôle. Doit commencer par `/`. Peut contenir au plus un jeton `$currentUser.assignments.<table>[0]`.
`pickerLanding`	`roles[]`	Repli multi-enregistrements pour un `defaultLanding` à modèle. Doit commencer par `/`. Ne doit pas contenir de jeton d'affectation.

landingPath est contrôlé par l'utilisateur — choisissez /portal, /dashboard, /home, ou n'importe quoi d'autre. Il n'y a pas de convention de moteur. Il en va de même pour pickerLanding : /portal/select/clients, /companies-picker, comme bon vous semble.

Trois règles inter-champs sont vérifiées au décodage de la configuration : un atterrissage à moitié câblé échoue donc à sovrium validate au lieu de mal acheminer à l'exécution.

auth.landingPath doit être défini dès qu'un rôle déclare defaultLanding ou pickerLanding.
Un rôle doté d'un pickerLanding doit aussi déclarer defaultLanding — le sélecteur est un repli, pas un atterrissage à part entière.
Ce defaultLanding doit être à modèle. Un pickerLanding à côté d'une URL simple ne pourrait jamais se déclencher : il est rejeté plutôt que laissé en configuration morte.

Logique de résolution

Lorsqu'une session authentifiée navigue vers auth.landingPath, le moteur parcourt auth.roles[] dans l'ordre de déclaration et applique le premier rôle que l'utilisateur détient. L'ordre est donc signifiant : déclarez le rôle le plus spécifique en premier.

Forme de `defaultLanding`	Nombre d'affectations pour la `<table>` à modèle	Action du moteur
URL simple (sans jeton)	s.o.	Rediriger vers `defaultLanding` sans condition.
À modèle (un jeton)	Exactement une affectation	Substituer l'ID d'affectation, rediriger là.
À modèle (un jeton)	Plus d'une affectation	Rediriger vers le `pickerLanding` du rôle.
Aucun rôle concordant / aucune affectation	s.o.	Rediriger vers `noAccessPath` (par défaut `/403`).

Interpolation `$currentUser.assignments`

Déplacé vers Affectations et gardes d'atterrissage.

La page `landingPath` est le garde d'accès

Déplacé vers Affectations et gardes d'atterrissage.

Exemple complet

app.yaml

auth:
  strategies:
    - type: emailAndPassword
  scopeTables: [clients]
  defaultRole: customer-admin
  landingPath: /portal
  noAccessPath: /403
  roles:
    - name: engineer
      defaultLanding: /admin
    - name: customer-admin
      defaultLanding: /portal/clients/$currentUser.assignments.clients[0]
      pickerLanding: /portal/select/clients

pages:
  - name: portal-landing
    path: /portal
    access: { require: authenticated, redirectTo: /login }
    components: []
  - name: client-detail
    path: /portal/clients/:id
    access: authenticated
    components: []
  - name: client-picker
    path: /portal/select/clients
    access: authenticated
    components: []
  - name: admin-home
    path: /admin
    access: [engineer]
    components: []
  - name: forbidden
    path: /403
    access: authenticated
    components: []

Dans cette application, un engineer atterrit sur /admin ; un customer-admin avec un seul client atterrit sur la page de détail de ce client ; avec plusieurs, sur le sélecteur ; et quiconque le résolveur ne peut placer atteint /403.

Pages connexes

Affectations et gardes d'atterrissage — le jeton d'interpolation et la page de garde.
Rôles & RBAC — là où defaultLanding / pickerLanding sont déclarés.
Sessions — scopeTables, user_access et $currentUser.activeAssignment.
Pages — path, access et dataSource.filter de page.

Dernière mise à jour 11 août 2026

← PrécédentGroupes Suivant →Affectations et gardes

Modifier cette page Signaler un problème

Cette documentation a été rédigée avec de l'IA : des erreurs ou du contenu obsolète sont donc possibles. Sovrium est en bêta. Les contributions et corrections sont les bienvenues.