offline_access棄用和方案3和4

Question

每次我讀https://developers.facebook.com/roadmap/offline-access-removal/時，我比以前更加困惑。我正在尋找一些關於場景3和4（服務器端應用程序和客戶端應用程序）的一些項目的說明

對於服務器端應用程序，它聲明「如果在仍有效的情況下該用戶的60天access_token，第二次調用返回的access_token可能是相同的或者可能已經改變，但是在任何一種情況下，到期時間將是新的60天。「

• 這裏提到的「呼叫」是什麼？
• 與最初的OAuth流程中發生的訪問令牌的授權代碼是否相同？
• 還是在客戶端部分描述的端點調用將令牌更新爲60天嗎？
• 如果是前者，那麼在嘗試更新令牌時授權代碼來自何處？
• 與原始回調是相同的授權碼還是必須再次通過授權流程？

簡而言之，服務器端應用程序是否能夠使60天令牌的壽命變得更加清新，如果是這樣，那又如何呢？

關於客戶端使用，文檔指出客戶端必須使該端點調用傳入（除其他外）應用程序的客戶端ID和客戶端密鑰。

• 我對「客戶端」的解釋可能是錯誤的，但是我正在考慮在Web瀏覽器中運行的基於JavaScript的客戶端。
• 如果這就是Facebook在這裏想到的，那麼JavaScript代碼真的應該知道客戶端的祕密嗎？ （如果它被髮送到客戶端，它不會太祕密）。

即使這樣，它表明60天的代幣不能延長他們的壽命，並且必須先創建一個新的2小時代幣獲得並用於獲得60天的令牌。這是在文檔的客戶端部分，但是這個規則是否也適用於服務器端60天令牌？如果沒有，那麼我再問一次：我如何在服務器端更新60天令牌的生命？

最後，這個問題在我腦海中已經燃燒了一段時間：爲什麼Facebook採用了這種策略，而沒有采用OAuth 2規範（Facebook幫助定義的規範）中定義的刷新令牌？

編輯：進一步的想法/問題再次重新閱讀文檔後：

在開始的時候它說：「可在每個用戶revists您的應用程序時予以續期長壽命到期時間」。我最初的假設是更新它的方法是在文檔的稍後部分調用端點。但是，除了端點在「客戶端」標題下描述的事實之外，它還指出「請注意，端點只能用於擴展短期用戶access_tokens。如果您傳遞的access_token具有長期的到期時間，端點將簡單地將相同的access_token傳回給您，而不會改變或延長到期時間。「 （長篇大論的錯字來自FB自己的文檔。）

好的，如果該端點不能用於更新過期時間（並且我自己試圖用該端點更新長壽命令牌證明了這一點），那麼如何在一個長時間內更新過期時間每次他們訪問我的應用程序的移動令牌？

有沒有人理解這應該如何工作？

Answer 1

在閱讀Facebook的文檔（如第五次）和this question/answer的幫助下，這是我的結論。

這裏提到的「呼叫」是什麼？

它引用OAuth調用來獲取訪問令牌。

是否在最初的OAuth流程中發生訪問令牌 的授權代碼的相同交換？

是的，我相信就是這樣。

或者它是在客戶端部分描述的端點調用 將令牌變爲60天嗎？

不，該端點僅對短期訪問令牌有效。

與原始回調是相同的授權碼還是我 必須再次通過授權流程？

您必須再次通過授權流程。

我該如何續訂長時間令牌上的到期時間？每次訪問我的應用程序時都會使用 ？

使用客戶端端點不能更新長期存取令牌。用戶將不得不重新授權應用程序以獲得新的應用程序。 根據Facebook的文檔：

如果調用（OAuth授權呼叫）製成，而仍然有一個有效的長期用戶 的access_token該用戶，返回的用戶從該 第二個電話ACCESS_TOKEN可能是相同或可能已更改，但在任一情況下， 的到期時間將設置爲較長的​​到期時間。

一旦應用程序重新授權，您將獲得新的到期時間。 Facebook可能會返回一個新的長期訪問令牌，因此您應該抓住它並替換您已有的信息。

結論： 似乎沒有任何方法可以在沒有用戶干預的情況下更新長期訪問令牌。要獲得新的到期時間/訪問令牌，他們必須重新授權您的應用。我的建議是，建議用戶在到期日前幾天重新授權。 此外，這Facebook how-to可以派上用場檢查過期的訪問令牌。