我正在升級帳戶以使用新的plus.login
範圍,因此我測試了添加一個僅具有userinfo
範圍的用戶,然後使用plus.login
添加了重新登錄。其結果是引入了授權訪問面板中的新條目,並且從後面的訪問返回的訪問令牌僅具有userinfo
權限。我通過進行驗證的令牌調用以及嘗試列出人來測試了這一點。使用Google OAuth更改權限
這是預期的行爲,如果是這樣,我應該提前撤銷舊的令牌嗎?我發現/revoke
行動是可能的。 Server side removal of Oauth token
更新:Relevant Gist。這是使用Ruby的Omniauth寶石。我實際上並不確定用戶如何在授權訪問面板中看到多於一個條目,但在這種情況下,我可以看到2.在昨天測試了各種場景之後,我有大約6個條目都屬於相同的應用程序!請注意,我並未隨時更改客戶端ID,實際上只有一個客戶端ID。
我希望我描述的情況可以被其他人複製;它只是簡單地通過黑客入侵Google端URL來刪除plus.login範圍,然後再次登錄,同時保留URL。
更新(2):我還發現this gotcha:「您不應該請求userinfo.profile或plus.me與此範圍相結合,因爲它們隱式包含在內,並且會爲您的用戶創建令人困惑的權限對話框。事實上,這不僅僅是一個UX權限問題,看起來谷歌實際上並不存儲針對用戶的「plus.me」範圍,所以這意味着即使用戶已經授予權限,它也會始終顯示OAuth權限對話框(我認爲它是通過簡單的相等性檢查和通知加.me被請求,但不是針對用戶存儲的)。
更新(3):有關使用錯誤登錄的錯誤是由我的代碼執行類似user.login || user.signup而不更新登錄中的令牌數據。所以現在每次登錄後都會更新訪問令牌和刷新令牌。 (我仍然不明白爲什麼每個客戶端用戶組合需要多於一個令牌。)
謝謝,這個演示基本上覆制了大部分我感到困惑的東西,也就是說我還有第二個入口,因爲我認爲升級只會覆蓋它,但我看到它是預期的行爲。 (雖然我仍不確定爲什麼錯誤的令牌回來了,我會重新測試一下。) 我仍然有關於升級現有令牌的最佳實踐的相同實際問題,因爲我最好只想一個令牌(即使我每次都可以用正確的令牌準確地打電話,這是不必要的)。所以我想我的服務器應該在升級的令牌回來時撤銷「所有其他令牌」? – mahemoff 2013-03-15 15:36:00
添加到答案中的其他註釋,因爲註釋中的空間不足。 – class 2013-03-15 15:42:24
謝謝,這對確認其他人應該被撤銷非常有用。所以聽起來好像你在暗示當用戶點擊登錄按鈕時,我的服務器應該首先嚐試撤銷任何現有的令牌,並且只有在收到來自Google服務器的成功響應時才請求新的令牌。換言之,服務器到服務器之間的往返發生在用戶請求和應用服務器的重定向到Google響應之間。 – mahemoff 2013-03-15 15:57:36