Nach der Anmeldung

Die Nach der Anmeldung-Action (Post sign-in Action) aktualisiert einen bestehenden Benutzer am Ende einer erfolgreichen Anmeldung. Sie wird nach allen Authentifizierungsfaktoren, einschließlich Multi-Faktor-Authentifizierung (MFA), falls erforderlich, und bevor Logto die OIDC-Interaktion abschließt und Tokens ausstellt, ausgeführt.

Sie läuft für SignIn-Interaktionen, unabhängig davon, ob sich der Benutzer mit einem Passwort, einem Verifizierungscode, einem sozialen Connector, Enterprise SSO, Passkey oder einer anderen unterstützten Methode authentifiziert hat. Sie wird nicht während der Registrierung ausgeführt.

Ereignis-Payload

Das Ereignis enthält den finalen Benutzerkontext für die aktuelle Anmeldung:

type PostSignInEvent = {
  // Aus Kompatibilitätsgründen nach der Umbenennung des Features in Actions beibehalten.
  key: 'inlineHook.postSignIn';
  interactionEvent: 'SignIn';
  user: PostSignInUserContext;
};

event.user enthält das Standard-Benutzerprofil, sowie:

Feld	Beschreibung
hasPassword	Ob der Benutzer ein lokales Passwort hat
ssoIdentities	Enterprise SSO-Identitäten, die mit dem Benutzer verknüpft sind
mfaVerificationFactors	MFA-Faktortypen, die für den Benutzer konfiguriert sind
roles	Globale Rollen und deren API-Ressourcen-Berechtigungen
organizations	Organisationen, denen der Benutzer angehört
organizationRoles	Organisationsrollen, die dem Benutzer zugewiesen sind

Der Kontext enthält außerdem Felder wie applicationId, lastSignInAt, createdAt und updatedAt. Er enthält keine Klartext-Passwörter, Passwort-Hashes, MFA-Geheimnisse oder Connector-Token-Set-Geheimnisse.

Ergebnis und No-Op-Verhalten

Gib dieses Ergebnis zurück, um den Benutzer zu aktualisieren:

type PostSignInResult = {
  action: 'updateUser';
  user?: ActionUserPatch;
};

user darf nur die unterstützten Benutzer-Patch-Felder enthalten.

Gib undefined, null, {} oder { action: 'updateUser' } zurück, um ohne eine Action-Benutzeraktualisierung fortzufahren. Andere Aktionsnamen, primitive Werte, Arrays, user: null oder nicht unterstützte Benutzerfelder sind ungültig und führen dazu, dass die Anmeldung fehlschlägt.

hinweis:

Die allow-Skriptfehler-Policy greift nur, wenn die Skriptausführung fehlschlägt. Sie erlaubt kein fehlerhaftes Ergebnis. Gib immer ein unterstütztes Update oder einen No-Op-Wert zurück.

Aktualisierung von Anmelde-Identifikatoren

Im Gegensatz zu Nach der ersten Faktor-Verifizierung kann diese Action die Identifikatorfelder username, primaryEmail und primaryPhone ändern, einschließlich des Identifikators, mit dem sich der Benutzer gerade angemeldet hat. Die Authentifizierung ist bereits abgeschlossen, wenn die Action ausgeführt wird, daher betrifft die Aktualisierung nur das gespeicherte Profil und nicht die aktuelle Anmeldeentscheidung.

Zwei Konsequenzen sind zu beachten:

• Der zukünftige Anmelde-Identifikator des Benutzers ändert sich. Ein Benutzer, der sich mit old@example.com angemeldet hat, kann diese Adresse danach nicht mehr verwenden. Stelle sicher, dass der Benutzer einen nutzbaren Identifikator behält, und behandle den neuen Wert als bestätigt, da Logto ihn ohne zusätzlichen Verifizierungsschritt als primäre E-Mail-Adresse oder Telefonnummer des Benutzers speichert.
• Eine Kollision bricht die Anmeldung ab. Wenn der neue Identifikator bereits einem anderen Benutzer gehört, lehnt Logto die Aktualisierung mit einem 422-Fehler wie user.email_already_in_use ab und die Interaktion schlägt fehl. Diese Prüfung erfolgt außerhalb des Skripts, sodass die allow-Skriptfehler-Policy sie nicht unterdrückt. Löse oder überspringe Konflikte innerhalb des Skripts, anstatt dich auf die Fehler-Policy zu verlassen.

Gib ein Identifikatorfeld nur zurück, wenn der Wert aus einer vertrauenswürdigen Quelle stammt, wie einem Upstream-Identitätsanbieter oder einem System of Record.

Anreicherungsbeispiel

Dieses Beispiel ruft aktuelle Profildaten von einem externen Dienst ab und speichert ausgewählte Felder in Logto:

const runAction = async ({ event, environmentVariables = {} }) => {
  const response = await fetch(
    `${environmentVariables.PROFILE_API_URL}/users/${encodeURIComponent(event.user.id)}`,
    {
      headers: {
        authorization: `Bearer ${environmentVariables.PROFILE_API_TOKEN}`,
      },
    }
  );

  if (response.status === 404) {
    return;
  }

  if (!response.ok) {
    throw new Error(`Profile service returned ${response.status}`);
  }

  const externalProfile = await response.json();

  return {
    action: 'updateUser',
    user: {
      ...(externalProfile.name && { name: externalProfile.name }),
      customData: {
        profileSource: 'external',
        customerTier: externalProfile.customerTier,
        profileSyncedAt: new Date().toISOString(),
      },
    },
  };
};

Die Aktualisierung wird abgeschlossen, bevor Logto die Anmeldung beendet. Wenn die entsprechenden OIDC-Berechtigungen angefordert werden, können Ansprüche, die aus dem aktualisierten Benutzer abgeleitet werden, wie Profilansprüche im ID-Token, daher die neuen Werte der aktuellen Anmeldung widerspiegeln.

Reihenfolge und Fehlerverhalten

Bevor diese Action ausgeführt wird, hat Logto möglicherweise bereits normale Anmelde-Nebeneffekte wie lastSignInAt, während der Interaktion vorgenommene Profiländerungen, MFA-Status, SSO-Identitätssynchronisierung und Just-in-Time-Organisationsbereitstellung gespeichert. Das Blockieren der Anmeldung macht diese Änderungen nicht rückgängig.

Wähle die Fehler-Policy basierend auf der Rolle der externen Daten:

• Verwende block, wenn das Update für eine gültige Anmeldung erforderlich ist. Dies ist die Standardeinstellung.
• Verwende allow, wenn veraltete oder fehlende Anreicherungsdaten akzeptabel sind. Wenn die Skriptausführung fehlschlägt, setzt Logto die Anmeldung ohne Anwendung des Action-Updates fort.

Halte das Update idempotent und die externe Abhängigkeit schnell. Eine Nach der Anmeldung-Action wird bei jeder zutreffenden Anmeldung ausgeführt.