Schritte zum Minimieren der Auswirkungen von Änderungen am Umfang auf Nutzer
- Wenn Ihre Anwendung die E-Mail-Adresse eines authentifizierten Nutzers erfordert und Sie zuvor
profile.emails.read
zu diesem Zweck verwendet haben, verwenden Sie stattdessenemail
. - Holen Sie die Genehmigung für
profile.emails.read
mit einer genehmigten Überprüfungsanfrage ein. Weitere Informationen finden Sie unter Wie reiche ich die Überprüfung ein? - Widerrufen Sie das bisherige Nutzertoken für den Bereich, der entfernt werden soll, oder entfernen Sie den Zugriff auf die Anwendung vollständig. Beispielsweise sollte ein Token mit
profile.emails.read
-Zugriff widerrufen werden. Wir empfehlen, den Widerruf vorzunehmen, während sich die Nutzer in Ihrer App befinden, damit Sie die Einwilligung der Nutzer sofort einholen können. - Fordern Sie Ihre Nutzer auf, dem neuen Umfang wie
email
ohneprofile.emails.read
noch einmal zuzustimmen. - Entfernen Sie den Bereich, der aus der Konfiguration des OAuth-Zustimmungsbildschirms für Google APIs entfernt werden soll.
Wenn du deine App von Google+ Log-in zu Google Log-in migrieren möchtest, musst du deine Anmeldeschaltfläche, die angeforderten Bereiche und eine Anleitung zum Abrufen von Profilinformationen von Google aktualisieren. Eine ausführliche Anleitung findest du in der Dokumentation zu Google Log-in für Android.
Beziehen Sie sich beim Aktualisieren Ihrer Anmeldeschaltfläche nicht auf G+ und verwenden Sie nicht die Farbe Rot. Sie müssen unsere aktualisierten Branding-Richtlinien erfüllen.
Die meisten Google+ Log-in-Anwendungen haben eine Kombination der Bereiche plus.login
, plus.me
und plus.profile.emails.read
angefordert. Wenn Sie GoogleSignInOptions.Builder
mit der Option DEFAULT_SIGN_IN
verwenden, wird automatisch der Bereich profile
angefordert, der den Namen und das Profilbild des Nutzers enthält. Wenn Sie auch die E-Mail-Adresse des Nutzers verwenden möchten, sollten Sie beim Erstellen der Google-Anmeldeoptionen .requestEmail()
aufrufen.
Viele Nutzer von Google+ Log-in haben den Codeablauf verwendet. Das bedeutet, dass die Android-, iOS- oder JavaScript-Apps einen OAuth-Autorisierungscode von Google erhalten und der Client diesen Code zusammen mit dem websiteübergreifenden Fälschungsschutz an den Server zurücksendet. Der Server validiert dann den Code und ruft Aktualisierungs- und Zugriffstokens ab, um Nutzerprofilinformationen aus der people.get
API abzurufen.
Google empfiehlt jetzt, ein ID-Token anzufordern und dieses von Ihrem Client an Ihren Server zu senden. ID-Tokens haben einen integrierten Fälschungsschutz und können auch statisch auf Ihrem Server verifiziert werden. Dadurch wird ein zusätzlicher API-Aufruf zum Abrufen von Nutzerprofilinformationen von den Google-Servern vermieden. Folgen Sie der Anleitung zum Validieren von ID-Tokens auf Ihrem Server.
Wenn Sie den Codeablauf dennoch verwenden möchten, um Profilinformationen abzurufen, können Sie das tun. Sobald Ihr Server ein Zugriffstoken hat, müssen Sie von den userinfo
-Endpunkten, die in unserem Discovery-Dokument zur Anmeldung angegeben sind, Nutzerprofilinformationen abrufen. Die API-Antwort ist anders formatiert als die Antwort des Google+ Profils. Deshalb müssen Sie das Parsing auf das neue Format aktualisieren.
Wenn Sie GoogleAuthUtil.getToken
oder Plus.API
verwenden, migrate Sie zur neuesten Sign-In API, um die Sicherheit und Nutzerfreundlichkeit zu verbessern.