減少範圍變更對使用者影響的步驟
- 如果您的應用程式需要已驗證使用者的電子郵件地址,且您先前曾使用
profile.emails.read
來做這件事,請改用email
。 - 使用已核准的驗證申請,取得
profile.emails.read
的核准。請參閱「如何送交驗證」一節。 - 將先前的使用者權杖撤銷到要從移除範圍中移除,或完全移除應用程式存取權。舉例來說,具有
profile.emails.read
存取權的符記應予以撤銷。建議您在使用者使用應用程式時撤銷授權,以便立即取得使用者的同意。 - 提示使用者透過新的範圍 (例如
email
) 重新取得同意聲明,不使用profile.emails.read
。 - 從 Google API OAuth 同意畫面設定中移除要逐步淘汰的範圍。
如要將應用程式從 Google+ 登入服務遷移至 Google 登入服務,您必須更新登入按鈕、要求的權限,以及如何從 Google 擷取個人資料資訊的操作說明。如需完整操作說明,請參閱 Google 登入 (Android 版) 說明文件。
更新登入按鈕時,請勿提及 G+ 或使用紅色。請遵守新版品牌宣傳規範。
大多數 Google+ 登入應用程式都要求以下範圍的組合:plus.login
、plus.me
和 plus.profile.emails.read
。使用 GoogleSignInOptions.Builder
搭配 DEFAULT_SIGN_IN
選項,系統會自動要求 profile
範圍,提供使用者的名稱和個人資料相片。如果您也需要使用者的電子郵件地址,請在建構 Google 登入選項時呼叫 .requestEmail()
。
許多 Google+ 登入功能導入者都使用代碼流程。也就是說,Android、iOS 或 JavaScript 應用程式會向 Google 取得 OAuth 授權碼,而用戶端會將該程式碼連同跨網站要求偽造保護。接著,伺服器會驗證程式碼,並取得重新整理和存取權杖,以便從 people.get
API 提取使用者個人資料。
Google 目前建議您要求 ID 權杖,並將 ID 權杖從用戶端傳送至伺服器。ID 權杖內建跨網站偽造防護機制,且可在您的伺服器進行靜態驗證,避免透過額外的 API 呼叫從 Google 伺服器取得使用者個人資料。按照操作說明在伺服器上驗證 ID 權杖。
如果您仍想使用程式碼流程來取得個人資料,可以這麼做。一旦伺服器取得存取權權杖,您就需要從「登入」Discovery 文件中指定的 userinfo
端點取得使用者個人資料。API 回應的格式與 Google+ 個人資料回應不同,因此您需要將剖析作業更新為新格式。
如果您使用 GoogleAuthUtil.getToken
或 Plus.API
,請改用最新的 Sign-In API,以提高安全性並改善使用者體驗。