Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Authentifizierungsablauf mit Blockierfunktionen anpassen

In diesem Dokument wird gezeigt, wie Sie die Identity Platform-Authentifizierung mit Cloud Functions-Blockierfunktionen erweitern.

Mit Blockierfunktionen können Sie benutzerdefinierten Code ausführen, der das Ergebnis einer Nutzerregistrierung oder Anmeldung bei Ihrer Anwendung ändert. Sie können beispielsweise verhindern, dass ein Nutzer sich authentifizieren kann, wenn er bestimmte Kriterien nicht erfüllt, oder seine Informationen aktualisieren, bevor sie an die Clientanwendung zurückgegeben werden.

Hinweis

Erstellen Sie eine Anwendung mit Identity Platform. Weitere Informationen dazu finden Sie in der Kurzanleitung.

Informationen zu Blockierfunktionen

Sie können Blockierfunktionen für zwei Ereignisse registrieren:

  • beforeCreate: Wird ausgelöst, bevor ein neuer Nutzer in der Identity Platform-Datenbank gespeichert wird und bevor ein Token an die Clientanwendung zurückgegeben wird.

  • beforeSignIn: Wird ausgelöst, nachdem die Anmeldedaten eines Nutzers überprüft wurden, aber bevor Identity Platform ein ID-Token an Ihre Client-App zurückgibt. Wenn Ihre Anwendung die Multi-Faktor-Authentifizierung verwendet, wird die Funktion ausgelöst, nachdem der Nutzer den zweiten Faktor überprüft hat. Hinweis: Durch das Erstellen eines neuen Nutzers wird zusätzlich zu beforeCreate auch beforeSignIn ausgelöst.

Beachten Sie bei der Verwendung von Blockierfunktionen Folgendes:

  • Ihre Funktion muss innerhalb von sieben Sekunden antworten. Nach 7 Sekunden gibt Identity Platform einen Fehler zurück und der Clientvorgang schlägt fehl.

  • Andere HTTP-Antwortcodes als 200 werden an Ihre Clientanwendungen weitergeleitet. Achten Sie darauf, dass der Clientcode alle Fehler verarbeitet, die von der Funktion zurückgegeben werden.

  • Funktionen gelten für alle Nutzer in Ihrem Projekt, einschließlich der in einem Mandanten enthaltenen Nutzer. Identity Platform stellt der Funktion Informationen über Nutzer bereit, einschließlich aller Mandanten, zu denen sie gehören, damit Sie entsprechend reagieren können.

  • Wenn Sie einen anderen Identitätsanbieter mit einem Konto verknüpfen, werden alle registrierten beforeSignIn-Funktionen ausgelöst.

  • Die anonyme Authentifizierung und die benutzerdefinierte Authentifizierung unterstützen keine Blockierfunktionen.

Blockierfunktion erstellen

So erstellen Sie eine Blockierfunktion:

  1. Rufen Sie in der Cloud Console die Identity Platform-Seite Einstellungen auf.

    Zur Seite "Einstellungen"

  2. Wählen Sie den Tab Trigger aus.

  3. Wählen Sie zum Erstellen einer Blockierfunktion für die Nutzerregistrierung unter Vor dem Erstellen (beforeCreate) das Drop-down-Menü Funktion aus und klicken Sie dann auf Funktion erstellen Zum Erstellen einer Blockierfunktion für die Nutzeranmeldung erstellen Sie eine Funktion unter Vor der Anmeldung (beforeSignIn).

  4. Erstellen Sie eine neue Funktion:

    1. Geben Sie unter Name einen Namen für die Funktion ein.

    2. Wählen Sie im Feld Trigger die Option HTTP aus.

    3. Wählen Sie im Feld Authentifizierung die Option Nicht authentifizierte Aufrufe zulassen aus.

    4. Klicken Sie auf Next (Weiter).

  5. Usingffnen Sie index.js mit dem Inline-Editor. Löschen Sie den helloWorld-Beispielcode und ersetzen Sie ihn durch einen der folgenden Werte:

    Zum Antworten auf die Registrierung:

    import * as gcipCloudFunctions from 'gcip-cloud-functions';
    
    const authClient = new gcipCloudFunctions.Auth();
    
    exports.beforeCreate = authClient.functions().beforeCreateHandler((user, context) => {
      // TODO
    });
    

    Zum Antworten auf die Anmeldung:

    import * as gcipCloudFunctions from 'gcip-cloud-functions';
    
    const authClient = new gcipCloudFunctions.Auth();
    
    exports.beforeSignIn = authClient.functions().beforeSignInHandler((user, context) => {
      // TODO
    });
    
  6. Öffnen Sie package.json und fügen Sie Folgendes hinzu:

    "dependencies": {
      "gcip-cloud-functions": "^0.0.1"
    }
    
  7. Klicken Sie auf Bereitstellen, um die Funktion zu veröffentlichen.

  8. Klicken Sie auf der Seite "Identity Platform-Blockierfunktionen" auf Speichern.

In den folgenden Abschnitten erfahren Sie, wie Sie die Funktion implementieren. Sie müssen die Funktion bei jeder Aktualisierung neu bereitstellen.

Sie können Funktionen auch mit dem gcloud-Befehlszeilentool oder der REST API erstellen und verwalten. In der Cloud Functions-Dokumentation erfahren Sie, wie Sie mit dem gcloud-Befehlszeilentool eine Funktion bereitstellen.

Nutzer- und Kontextinformationen abrufen

Die Ereignisse beforeSignIn und beforeCreate stellen User- und EventContext-Objekte mit Informationen zur Nutzeranmeldung bereit. Legen Sie anhand dieser Werte in Ihrem Code fest, ob ein Vorgang fortgesetzt werden soll.

Eine Liste der im Objekt User verfügbaren Attribute finden Sie in der Referenz zur UserRecord API.

Das EventContext-Objekt weist die folgenden Attribute auf:

Name Beschreibung Beispiel
locale Die Sprache der Anwendung. Sie können die Sprache mit dem Client SDK festlegen oder indem Sie die Sprachheader in der REST API übergeben. fr oder sv-SE
ipAddress Die IP-Adresse des Geräts, über das sich der Endnutzer registriert oder anmeldet. 114.14.200.1
userAgent Der User-Agent löst die Blockierfunktion aus. Mozilla/5.0 (X11; Linux x86_64)
eventId Die eindeutige Kennung des Ereignisses. rWsyPtolplG2TBFoOkkgyg
eventType Der Ereignistyp. Dadurch werden Informationen zum Ereignisnamen wie beforeSignIn oder beforeCreate und die zugehörige Anmeldemethode wie Google oder E-Mail/Passwort zurückgegeben. providers/cloud.auth/eventTypes/user.beforeSignIn:password
authType Immer USER. USER
resource Das Identity Platform-Projekt oder der Identity-Plattform-Mandant. projects/project-id/tenants/tenant-id
timestamp Der Zeitpunkt, an dem das Ereignis ausgelöst wurde, im Format RFC 3339. Tue, 23 Jul 2019 21:10:57 GMT
additionalUserInfo Ein Objekt mit Informationen zum Nutzer. AdditionalUserInfo
credential Ein Objekt mit Informationen zu den Anmeldedaten des Nutzers. AuthCredential

Registrierung oder Anmeldung blockieren

Wenn Sie einen Registrierungs- oder Anmeldeversuch blockieren möchten, geben Sie in der Funktionen den Fehler HttpsError aus. Beispiel:

Node.js

throw new gcipCloudFunctions.https.HttpsError('permission-denied');

In der folgenden Tabelle werden die Fehler, die Sie ausgeben können, zusammen mit der Standard-Fehlermeldung angezeigt:

Name Code Nachricht
invalid-argument 400 Der Client hat ein ungültiges Argument angegeben.
failed-precondition 400 Die Anfrage kann im aktuellen Systemzustand nicht ausgeführt werden.
out-of-range 400 Der Client hat einen ungültigen Bereich angegeben.
unauthenticated 401 Fehlendes, ungültiges oder abgelaufenes OAuth-Token.
permission-denied 403 Der Client verfügt nicht über die erforderliche Berechtigung.
not-found 404 Die angegebene Ressource wurde nicht gefunden.
aborted 409 Konflikt aufgrund von gleichzeitig ausgeführten Aktionen, beispielsweise ein Read-Modify-Write-Konflikt.
already-exists 409 Die von einem Client zu erstellende Ressource ist bereits vorhanden.
resource-exhausted 429 Es wurde entweder das Ressourcenkontingent überschritten oder das Ratenlimit erreicht.
cancelled 499 Die Anfrage wurde vom Client abgebrochen.
data-loss 500 Es ist ein dauerhafter Datenverlust oder Datenkorruption aufgetreten.
unknown 500 Unbekannter Serverfehler.
internal 500 Interner Serverfehler.
not-implemented 501 Die API-Methode wurde vom Server nicht implementiert.
unavailable 503 Dienst nicht verfügbar:
deadline-exceeded 504 Die Frist der Anfrage wurde überschritten.

Sie können auch eine benutzerdefinierte Fehlermeldung angeben:

Node.js

throw new gcipCloudFunctions.https.HttpsError('permission-denied', 'Unauthorized request origin!');

Das folgende Beispiel zeigt, wie Sie Nutzer, die nicht Mitglieder einer bestimmten Domain sind, daran hindern, sich bei Ihrer Anwendung anzumelden:

Node.js

// Import the Cloud Auth Admin module.
const gcipCloudFunctions = require('gcip-cloud-functions');
// Initialize the Auth client.
const authClient = new gcipCloudFunctions.Auth();
// Http trigger with Cloud Functions.
exports.beforeCreate = authClient.functions().beforeCreateHandler((user, context) => {
  // If the user is authenticating within a tenant context, the tenant ID can be determined from
  // user.tenantId or from context.resource, eg. 'projects/project-id/tenant/tenant-id-1'
  // Only users of a specific domain can sign up.
  if (user.email.indexOf('@acme.com') === -1) {
    throw new gcipCloudFunctions.https.HttpsError('invalid-argument', `Unauthorized email "${user.email}"`);
});

Unabhängig davon, ob Sie eine Standard- oder benutzerdefinierte Nachricht verwenden, gibt Cloud Functions den Fehler als internen Fehler an den Client zurück. Wenn Sie beispielsweise den folgenden Fehler in der Funktion ausgeben:

throw new gcipCloudFunctions.https.HttpsError('invalid-argument', `Unauthorized email user@evil.com}`);

In Ihrer Clientanwendung wird ein Fehler wie der folgende zurückgegeben. Wenn Sie das Client SDK verwenden, wird der Fehler als interner Fehler verpackt:

{
  "error": {
    "code": 400,
    "message": "BLOCKING_FUNCTION_ERROR_RESPONSE : HTTP Cloud Function returned an error. Code: 400, Status: \"INVALID_ARGUMENT\", Message: \"Unauthorized email user@evil.com\"",
    "errors": [
      {
        "message": "BLOCKING_FUNCTION_ERROR_RESPONSE : HTTP Cloud Function returned an error. Code: 400, Status: \"INVALID_ARGUMENT\", Message: \"Unauthorized email user@evil.com\"",
        "domain": "global",
        "reason": "invalid"
      }
    ]
  }
}

Ihre Anwendung erkennt den Fehler und reagiert entsprechend. Beispiel:

JavaScript

// Blocking functions can also be triggered in a multi-tenant context before user creation.
// firebase.auth().tenantId = 'tenant-id-1';
firebase.auth().createUserWithEmailAndPassword('johndoe@example.com', 'password')
  .then((result) => {
    result.user.getIdTokenResult()
  })
  .then((idTokenResult) => {
    console.log(idTokenResult.claim.admin);
  })
  .catch((error) => {
    if (error.code !== 'auth/internal-error' && error.message.indexOf('Cloud Function') !== -1) {
      // Display error.
    } else {
      // Registration succeeds.
    }
  });

Nutzer ändern

Anstatt einen Registrierungs- oder Anmeldeversuch zu blockieren, können Sie den Vorgang fortsetzen, aber das User-Objekt ändern, das in der Datenbank von Identity Platform gespeichert ist und an den Client zurückgegeben wird.

Wenn Sie einen Nutzer ändern möchten, geben Sie ein Objekt in Ihrem Ereignis-Handler mit den zu ändernden Feldern ein. Sie können die folgenden Felder ändern:

  • displayName
  • disabled
  • emailVerified
  • photoURL
  • customClaims
  • sessionClaims (nur beforeSignIn)

Mit Ausnahme von sessionClaims werden alle geänderten Felder in der Datenbank von Identity Platform gespeichert. Das bedeutet, dass sie im Antworttoken enthalten sind und zwischen Nutzersitzungen erhalten bleiben.

Das folgende Beispiel zeigt, wie ein standardmäßiger Anzeigename festgelegt wird:

Node.js

exports.beforeCreate = authClient.functions().beforeCreateHandler((user, context) => {
  return {
    // If no display name is provided, set it to "Guest".
    displayName: user.displayName || 'Guest';
  };
});

Wenn Sie einen Ereignis-Handler für beforeCreate und beforeSignIn registrieren, beachten Sie, dass beforeSignIn nach beforeCreate ausgeführt wird. Nutzerfelder, die in beforeCreate aktualisiert wurden, sind in beforeSignIn sichtbar. Wenn Sie in beiden Ereignis-Handlern ein anderes Feld als sessionClaims festgelegt haben, überschreibt der in beforeSignIn festgelegte Wert den in beforeCreate festgelegten Wert. Nur für sessionClaims werden sie an die Tokenansprüche der aktuellen Sitzung weitergeleitet, aber nicht dauerhaft gespeichert oder in der Datenbank gespeichert.

Wenn beispielsweise sessionClaims festgelegt sind, werden sie von beforeSignIn mit allen beforeCreate-Anforderungen zurückgegeben und zusammengeführt. Wenn ein sessionClaims-Schlüssel mit einem Schlüssel in customClaims übereinstimmt, werden die übereinstimmenden customClaims in den Tokenanforderungen vom sessionClaims-Schlüssel überschrieben. Der überschriebene customClaims-Schlüssel bleibt jedoch für zukünftige Anfragen in der Datenbank erhalten.

Unterstützte OAuth-Anmeldedaten und -Daten

Sie können OAuth-Anmeldedaten und -Daten übergeben, um Funktionen von verschiedenen Identitätsanbietern zu blockieren. In der folgenden Tabelle sehen Sie, welche Anmeldedaten und Daten für jeden Identitätsanbieter unterstützt werden:

Identitätsanbieter ID-Token Access Token (Zugriffstoken) Ablaufzeit Token-Secret Aktualisierungs-Token Anmeldeanforderungen
Google Ja Ja Ja Nein Ja Nein
Facebook Nein Ja Ja Nein Nein Nein
Twitter Nein Ja Nein Ja Nein Nein
GitHub Nein Ja Nein Nein Nein Nein
Microsoft Ja Ja Ja Nein Ja Nein
LinkedIn Nein Ja Ja Nein Nein Nein
Yahoo Ja Ja Ja Nein Ja Nein
Apple Ja Ja Ja Nein Ja Nein
SAML Nein Nein Nein Nein Nein Ja
OIDC Ja Ja Ja Nein Ja Ja

Aktualisierungstokens

Wenn Sie ein Aktualisierungstoken in einer Blockierfunktion verwenden möchten, müssen Sie zuerst das Kästchen im Abschnitt Trigger im Drop-down-Menü Token-Anmeldedaten einschließen der Cloud Console anklicken.

Aktualisierungstokens werden von Identitätsanbietern nicht zurückgegeben, wenn die Anmeldung direkt über OAuth-Anmeldedaten erfolgt, wie z. B. mit einem ID-Token oder Zugriffstoken. In diesem Fall werden die clientseitigen OAuth-Anmeldedaten an die Blockierfunktion übergeben. Bei dreibeinigen Abläufen kann ein Aktualisierungstoken jedoch verfügbar sein, sofern vom Identitätsanbieter unterstützt.

In den folgenden Abschnitten werden die einzelnen Identitätsanbietertypen sowie die unterstützten Anmeldedaten und Daten beschrieben.

Generische OIDC-Anbieter

Wenn sich ein Nutzer mit einem generischen OIDC-Anbieter anmeldet, werden die folgenden Anmeldedaten übergeben:

  • ID-Token: Wird angegeben, wenn der Ablauf id_token ausgewählt ist.
  • Zugriffstoken: Wird angegeben, wenn der Codeablauf ausgewählt ist Beachten Sie, dass der Codeablauf derzeit nur über die REST API unterstützt wird.
  • Aktualisierungstoken: Wird angegeben, wenn der offline_access-Bereich ausgewählt ist.

Beispiel:

const provider = new firebase.auth.OAuthProvider('oidc.my-provider');
provider.addScope('offline_access');
firebase.auth().signInWithPopup(provider);

Google

Wenn sich ein Nutzer bei Google anmeldet, werden die folgenden Anmeldedaten übergeben:

  • ID-Token
  • Zugriffstoken
  • Aktualisierungstoken: Wird nur angegeben, wenn die folgenden benutzerdefinierten Parameter angefordert werden:
    • access_type=offline
    • prompt=consent, wenn der Nutzer zuvor zugestimmt hat und kein neuer Bereich angefordert wurde

Beispiel:

const provider = new firebase.auth.GoogleAuthProvider();
provider.setCustomParameters({
  'access_type': 'offline',
  'prompt': 'consent'
});
firebase.auth().signInWithPopup(provider);

Weitere Informationen zu den Aktualisierungstokens von Google

Facebook

Wenn sich ein Nutzer bei Facebook anmeldet, werden die folgenden Anmeldedaten übergeben:

  • Zugriffstoken: Ein Zugriffstoken wird zurückgegeben und kann durch ein anderes Zugriffstoken ersetzt werden. Weitere Informationen zu den verschiedenen Arten von Zugriffstokens, die von Facebook unterstützt werden, und wie Sie diese gegen langfristige Tokens tauschen können.

GitHub

Wenn sich ein Nutzer bei GitHub anmeldet, werden die folgenden Anmeldedaten übergeben:

  • Zugriffstoken: Das Token läuft nur ab, wenn es widerrufen wird.

Microsoft

Wenn sich ein Nutzer mit Microsoft anmeldet, werden die folgenden Anmeldedaten übergeben:

  • ID-Token
  • Zugriffstoken
  • Aktualisierungstoken: Wird an die Blockierfunktion übergeben, wenn der offline_access-Bereich ausgewählt ist.

Beispiel:

const provider = new firebase.auth.OAuthProvider('microsoft.com');
provider.addScope('offline_access');
firebase.auth().signInWithPopup(provider);

Yahoo

Wenn sich ein Nutzer bei Yahoo anmeldet, werden die folgenden Anmeldedaten ohne benutzerdefinierte Parameter oder Bereiche übergeben:

  • ID-Token
  • Zugriffstoken
  • Aktualisierungstoken

LinkedIn

Wenn sich ein Nutzer mit LinkedIn anmeldet, werden die folgenden Anmeldedaten übertragen:

  • Zugriffstoken

Apple

Wenn sich ein Nutzer mit Apple anmeldet, werden die folgenden Anmeldedaten ohne benutzerdefinierte Parameter oder Bereiche übergeben:

  • ID-Token
  • Zugriffstoken
  • Aktualisierungstoken

Gängige Szenarien

Die folgenden Beispiele veranschaulichen gängige Anwendungsfälle für Blockierfunktionen:

Registrierung über eine bestimmte Domain zulassen

Das folgende Beispiel zeigt, wie Sie verhindern können, dass sich Nutzer, die nicht zur example.com-Domain gehören, bei Ihrer Anwendung registrieren:

Node.js

export.beforeCreate = authClient.functions().beforeCreateHandler((user, context) => {
  if (!user.email || user.email.indexOf('@example.com') === -1) {
    throw new gcipCloudFunctions.https.HttpsError(
      'invalid-argument', `Unauthorized email "${user.email}"`);
  }
});

Nutzer mit nicht bestätigten E-Mails für die Registrierung blockieren

Das folgende Beispiel zeigt, wie Sie verhindern können, dass sich Nutzer mit unbestätigten E-Mails bei Ihrer Anwendung registrieren:

Node.js

export.beforeCreate = authClient.functions().beforeCreateHandler((user, context) => {
  if (user.email && !user.emailVerified) {
    throw new gcipCloudFunctions.https.HttpsError(
      'invalid-argument', `Unverified email "${user.email}"`);
  }
});

E-Mail-Bestätigung bei der Registrierung anfordern

Das folgende Beispiel zeigt, wie ein Nutzer seine E-Mail-Adresse nach der Registrierung bestätigen muss:

Node.js

export.beforeCreate = authClient.functions().beforeCreateHandler((user, context) => {
  const locale = context.locale;
  if (user.email && !user.emailVerified) {
    // Send custom email verification on sign-up.
    return admin.auth().generateEmailVerificationLink(user.email).then((link) => {
      return sendCustomVerificationEmail(user.email, link, locale);
    });
  }
});

export.beforeSignIn = authClient.functions().beforeSignInHandler((user, context) => {
 if (user.email && !user.emailVerified) {
   throw new gcipCloudFunctions.https.HttpsError(
     'invalid-argument', `"${user.email}" needs to be verified before access is granted.`);
  }
});

E-Mail-Adressen von bestimmten Identitätsanbietern als bestätigt behandeln

Das folgende Beispiel zeigt, wie Nutzer-E-Mails von bestimmten Identitätsanbietern als bestätigt behandelt werden:

Node.js

export.beforeCreate = authClient.functions().beforeCreateHandler((user, context) => {
  if (user.email && !user.emailVerified && context.eventType.indexOf(':facebook.com') !== -1) {
    return {
      emailVerified: true,
    };
  }
});

Anmeldung über bestimmte IP-Adressen blockieren

Im folgenden Beispiel wird gezeigt, wie die Anmeldung aus bestimmten IP-Adressbereichen blockiert wird:

Node.js

export.beforeSignIn = authClient.functions().beforeSignInHandler((user, context) => {
  if (isSuspiciousIpAddress(context.ipAddress)) {
    throw new gcipCloudFunctions.https.HttpsError(
      'permission-denied', 'Unauthorized access!');
  }
});

Benutzerdefinierte Anforderungen und Sitzungsanforderungen festlegen

Im folgenden Beispiel wird gezeigt, wie benutzerdefinierte Anforderungen und Sitzungsanforderungen festgelegt werden:

Node.js

export.beforeSignIn = authClient.functions().beforeCreateHandler((user, context) => {
  if (context.credential &&
      context.credential.providerId === 'saml.my-provider-id') {
    return {
      // Employee ID does not change so save in persistent claims (stored in
      // Auth DB).
      customClaims: {
        eid: context.credential.claims.employeeid,
      },
      // Copy role and groups to token claims. These will not be persisted.
      sessionClaims: {
        role: context.credential.claims.role,
        groups: context.credential.claims.groups,
      }
    }
  }
});

IP-Adressen verfolgen, um verdächtige Aktivitäten zu überwachen

Sie können den Diebstahl von Tokens verhindern, indem Sie die IP-Adresse erfassen, mit der sich ein Nutzer anmeldet, und diese mit der IP-Adresse bei nachfolgenden Anfragen vergleichen. Wenn die Anfrage verdächtig erscheint, z. B. weil die IP-Adressen aus verschiedenen geografischen Regionen stammen, können Sie den Nutzer auffordern, sich noch einmal anzumelden.

  1. Erfassen Sie mithilfe von Sitzungsanforderungen die IP-Adresse, mit der sich der Nutzer anmeldet:

    Node.js

    export.beforeSignIn = authClient.functions().beforeSignInHandler((user, context) => {
      return {
        sessionClaims: {
          signInIpAddress: context.ipAddress,
        },
      };
    });
    
  2. Wenn ein Nutzer versucht, auf Ressourcen zuzugreifen, die eine Authentifizierung mit Identity Platform benötigen, vergleichen Sie die IP-Adresse in der Anfrage mit der IP-Adresse, die für die Anmeldung verwendet wird:

    Node.js

    app.post('/getRestrictedData', (req, res) => {
      // Get the ID token passed.
      const idToken = req.body.idToken;
      // Verify the ID token, check if revoked and decode its payload.
      admin.auth().verifyIdToken(idToken, true).then((claims) => {
        // Get request IP address
        const requestIpAddress = req.connection.remoteAddress;
        // Get sign-in IP address.
        const signInIpAddress = claims.signInIpAddress;
        // Check if the request IP address origin is suspicious relative to
        // the session IP addresses. The current request timestamp and the
        // auth_time of the ID token can provide additional signals of abuse,
        // especially if the IP address suddenly changed. If there was a sudden
        // geographical change in a short period of time, then it will give
        // stronger signals of possible abuse.
        if (!isSuspiciousIpAddressChange(signInIpAddress, requestIpAddress)) {
          // Suspicious IP address change. Require re-authentication.
          // You can also revoke all user sessions by calling:
          // admin.auth().revokeRefreshTokens(claims.sub).
          res.status(401).send({error: 'Unauthorized access. Please login again!'});
        } else {
          // Access is valid. Try to return data.
          getData(claims).then(data => {
            res.end(JSON.stringify(data);
          }, error => {
            res.status(500).send({ error: 'Server error!' })
          });
        }
      });
    });
    

Nutzerfotos bereinigen

Das folgende Beispiel zeigt, wie die Profilbilder der Nutzer bereinigt werden:

Node.js

export.beforeCreate = authClient.functions().beforeCreateHandler((user, context) => {
  if (user.photoURL) {
    return isPhotoAppropriate(user.photoURL)
      .then((status) => {
        if (!status) {
          // Sanitize inappropriate photos by replacing them with guest photos.
          // Users could also be blocked from sign-up, disabled, etc.
          return {
            photoURL: PLACEHOLDER_GUEST_PHOTO_URL,
          };
        }
      });
});

Weitere Informationen zum Erkennen und Bereinigen von Bildern finden Sie in der Cloud Vision-Dokumentation.

OAuth-Anmeldedaten eines Nutzers aufrufen

Das folgende Beispiel zeigt, wie Sie ein Aktualisierungstoken für einen Nutzer abrufen, der sich bei Google angemeldet hat, und den Aufruf der Google Calendar APIs durchführen. Das Aktualisierungstoken wird für den Offlinezugriff gespeichert.

Node.js

const {OAuth2Client} = require('google-auth-library');
const {google} = require('googleapis');
// ...
// Initialize Google OAuth client.
const keys = require('./oauth2.keys.json');
const oAuth2Client = new OAuth2Client(
  keys.web.client_id,
  keys.web.client_secret
);

export.beforeCreate = authClient.functions().beforeCreateHandler((user, context) => {
  if (context.credential &&
      context.credential.providerId === 'google.com') {
    // Store the refresh token for later offline use.
    // These will only be returned if refresh tokens credentials are included
    // (enabled by Cloud Console).
    return saveUserRefreshToken(
        user.uid,
        context.credential.refreshToken,
        'google.com'
      )
      .then(() => {
        // Blocking the function is not required. The function can resolve while
        // this operation continues to run in the background.
        return new Promise((resolve, reject) => {
          // For this operation to succeed, the appropriate OAuth scope should be requested
          // on sign in with Google, client-side. In this case:
          // https://www.googleapis.com/auth/calendar
          // You can check granted_scopes from within:
          // context.additionalUserInfo.profile.granted_scopes (space joined list of scopes).

          // Set access token/refresh token.
          oAuth2Client.setCredentials({
            access_token: context.credential.accessToken,
            refresh_token: context.credential.refreshToken,
          });
          const calendar = google.calendar('v3');
          // Setup Onboarding event on user's calendar.
          const event = {/** ... */};
          calendar.events.insert({
            auth: oauth2client,
            calendarId: 'primary',
            resource: event,
          }, (err, event) => {
            // Do not fail. This is a best effort approach.
            resolve();
          });
      });
    })
  }
});

Nächste Schritte