Facebook 的 Graph API 2.0 升級和 ACS
更新日期：2015 年 7 月 17 日
在 2015 年 4 月 30 日，所有已啟用 Facebook 的應用程式都會自動升級至 Facebook 的 圖形 API v2.0。 如果您使用 Facebook 作為 ACS 命名空間中的識別提供者，您可能需要變更 ACS 中的 Facebook 身分識別提供者設定、變更應用程式的程式碼，或同時避免停機。如需 Facebook 方案的詳細資訊，請參閱 Facebook 平臺升級指南。
背景
ACS 使用下列 Facebook 端點： https://www.facebook.com/dialog/oauth 、 https://graph.facebook.com/oauth/access\_tokenhttps://www.facebook.com/logout.php 和 https://graph.facebook.com/me 。 Facebook 會自動升級這些「無版本」圖形 API要求，以在 2015 年 4 月 30 日使用 v2.0。
在 ACS 中將 Facebook 新增為身分識別提供者時，‘email’ 會設為應用程式權限 (根據預設)。 如果您未在 Facebook 身分識別提供者組態中選擇任何應用程式權限 (空的欄位) 或預設值 (‘email’)，您將無須進行任何應用程式或組態變更。 如果您選擇了其他應用程式權限，則應完整檢閱本主題，以評估影響並採取適當步驟。
.png "Application permissions dialog")
評估影響
您必須考量 Facebook 所做的下列變更：
權限
'basic_info' 權限 (每個 Facebook 要求的隱含部分) 將由 'public_profile' 權限 (也將是隱含的) 取代。 兩者的權限集完全相同，差別在於，使用後者時，好友清單將會是不同權限 'user_friends' 的一部分。 若要取得 'basic_info' 權限的對等功能，您必須明確地要求 'user_friends' 權限。
以 ‘friends’ 為基礎的權限有重大變更。 Facebook 平臺升級指南會詳細說明它們。
Facebook 要求應用程式要求超過 「basic_profile」、「電子郵件」和「user_friends」以外的其他許可權，才能完成其 登入檢閱 程式。
拒絕的權限
Facebook 會透過選擇性拒絕權限的選項，讓使用者選擇要為應用程式授與哪些權限。 應用程式將需要處理這些使用案例。
使用者無法拒絕 'public_profile' 權限。
如果使用者拒絕 'email' 權限，ACS 將不會在權杖中將 'email' 宣告傳回至應用程式。
應用程式範圍的使用者識別碼
在 ACS 權杖中傳送做為「名稱識別碼」宣告的使用者識別碼，將會從全域範圍的 ID (多個 Facebook 應用程式使用相同的使用者識別碼) 變成應用程式範圍的 ID (每個 Facebook 應用程式使用不同的使用者識別碼)。
此情況只適用於新登入應用程式的 Facebook 使用者。 對於之前登入過應用程式的使用者，這具有回溯相容性。
如果應用程式依賴全域範圍的使用者識別碼，將使用者相互關聯到不同的 Facebook 應用程式註冊，則必須進行調整，並使用 Facebook 的商務對應 API 來執行相同的動作。
建議
如果您發現啟用 Facebook 功能的 ACS 應用程式受到影響，請參閱下列非完整建議清單。 並非所有列出的事項皆適用於您。 如需完整清單，請參閱 Facebook 平臺升級指南 。