Facebook 登入

要求和撤銷權限

每種類型的登入流程都有自己要求權限的方式，端視您的平台以及您如何選擇整合 Facebook 登入而定：

網頁

行動應用程式

  • Android 登入可以使用許多不同的類別來要求及管理權限。如需詳細資訊，請參閱我們的 Android 登入教學導覽。
  • iOS 登入可以使用許多不同的方法來要求權限。如需詳細資訊，請參閱我們的 iOS 登入教學導覽。
  • Windows Phone 在啟動 URI 關聯時，會使用 scope 參數。

請注意，上列許多 API 在應用程式後續使用期間還可以用來要求其他權限，而不只是用在初始登入。

最佳化權限要求

一般而言，應用程式要求的權限愈多，用戶使用 Facebook 登入您應用程式的可能性就愈小。事實上，我們的研究顯示，要求超過四項權限的應用程式，完成登入的次數會大幅降低。

使用守則

以下是在登入期間和之後要求權限時，所應遵循的一些守則：

  • 僅要求對應用程式必要的權限。

  • 在需要權限的背景資料中要求權限。例如，如果您的應用程式想要顯示用戶所在位置附近的熱門地點，在要顯示該資訊之前才要求 user_location，用戶會更加理解為什麼會要求該權限。

  • 將讀取和發佈權限的要求分開。如需詳細資訊，請參閱下文。

  • 切勿要求您認為將來可能會需要的權限。用戶會產生懷疑，並且可能會拒絕您的應用程式。

  • 提前告知用戶您要求權限的原因。解釋您為什麼需要存取某些東西，會增加用戶願意分享的機會。

發佈權限

應用程式應將讀取和發佈權限的要求分開。請將應用程式規劃為在初始登入時僅要求最低限度的讀取權限，然後在用戶實際需要時，才要求任何發佈權限，例如當用戶想要從應用程式中建立開放社交關係圖動態時。如此可提供最佳用戶體驗，並最佳化轉換率。

如果應用程式接連要求讀取和發佈權限，您可能會收到「開發人員重要通知」。若要停止接收這些通知，請將要求分開，或針對特殊情況遵循以下守則。

在極少數情況下，應用程式會預先需要發佈權限（例如，只是用來將用戶心情發佈至 Facebook 的應用程式），則在初始登入時僅要求最低限度的讀取權限。在用戶登入後，向用戶顯示一個畫面，說明應用程式為什麼需要發佈權限，並讓用戶以點擊按鈕的方式選擇同意發佈權限要求。如此可提供用戶更多背景資訊，並提高您的轉換率。

您可能需要接連要求讀取和寫入權限的案例之一，就是第一次將採用電子郵件的帳號與用戶的 Facebook 帳號連結時。當用戶想要在 Facebook 動態時報上分享動態時，通常會這麼做。當應用程式建立登入對話方塊時，用戶會接連看到兩個對話方塊，一個是將用戶的帳號連結至您的應用程式，另一個則是要求發佈權限。就此情況而言，請確認您要求的唯一讀取權限是 public_profile。如此可提供最佳用戶體驗，因為用戶想要從您的應用程式發佈，而且通常無意提供額外的讀取權限。如此可提高您的轉換率。

檢查目前的權限

Facebook 提供用戶完整控制權，可控制他們授予應用程式的權限。該控制權並不僅止於他們看到登入對話方塊時範圍。他們可以在登入過程中選擇不授予特定權限，也可以隨時在 Facebook 隱私設定中撤銷權限。應用程式應先檢查權限的有效性，再嘗試執行需要權限的 API 呼叫。例如，先確認用戶仍授予 email，再傳送訊息。

針對網頁應用程式，我們有提供圖形 API 端點來擷取授予的權限清單：

GET /{user-id}/permissions

您必須以用戶存取權杖或應用程式存取權杖來發出呼叫。該呼叫會傳回 JSON 字串，其中包含已授予應用程式的權限名稱及其狀態：

{
  "data": [
    {
      "permission": "public_profile",
      "status": "granted"
    },
    {
      "permission": "email",
      "status": "granted"
    },
    {
      "permission": "user_friends",
      "status": "declined"
    }
  ]
}

我們也在 iOS 和 Android SDK 中提供方法，以平台適用的表示法來提供用戶已授予應用程式的權限。

處理缺少的權限

當應用程式要求權限時，用戶可能會完全拒絕授予那些權限、不完全授予那些權限，或稍後再加以變更。為了提供良好的體驗，所建置的應用程式應該要能夠處理這些情況。

首先，應用程式應該要能夠處理所要求但未經授予的任何權限：

  • 先檢查已授予的權限，再嘗試使用需要這些權限的 API。
  • 偵測在沒有正確權限的情況下發出 API 要求時所傳回的權限錯誤。錯誤訊息範例如下：
{
  "error": {
    "message": "(#200) The user hasn't authorized the application
     to perform this action",
    "type": "OAuthException",
    "code": 200
  }
}

一旦應用程式偵測到用戶已拒絕某些或所有權限，就可以透過登入流程將這些權限傳回一次，並要求任何必要的權限。然而，這樣會造成體驗不佳，應盡量避免。如果用戶主動選擇不授予特定權限給應用程式，即使會不斷看到提示，也不太可能會改變心意。您可以改為使用下列方法：

  • 如果用戶拒絕登入對話方塊，請清楚並坦誠地說明您要求每個權限的原因。然後讓他們點擊或點按選擇回到權限要求對話方塊。請勿在未說明的情況下，立即將他們重新導向到權限要求對話方塊。

  • 如果用戶拒絕授予權限給您的應用程式，除非您將 auth_type=rerequest 與您的要求一起傳遞，否則登入對話方塊不會讓您的應用程式重新要求權限。

  • 如果用戶授予了某些權限，但未授予其他權限，則只在需要缺少的權限時，才提示授予權限。例如，如果應用程式會傳送訂單確認訊息到用戶的電子郵件，則只在用戶下訂單時要求 email。

  • 除非您在登入對話方塊中要求的權限對應用程式的功能極為重要，而且如果沒有這些權限無法執行功能，請讓用戶在未授予權限的情況下繼續使用您的應用程式。

如果您的應用程式在用戶拒絕授予權限後，反覆將用戶導向至權限對話方塊，您可能會收到「開發人員重要通知」。若要停止收到這些通知，請遵循上述守則。

撤銷權限

應用程式可以讓用戶撤銷之前授予的權限。例如，您的應用程式可能有設定頁面，可讓用戶停止傳送電子郵件訊息給他們。該設定頁面可能還可以同時撤銷 email 權限。

您可以呼叫圖形 API 端點來撤銷特定權限：

DELETE /{user-id}/permissions/{permission-name}

您必須以目前應用程式的用戶存取權杖或應用程式存取權杖來發出此要求。如果要求成功，您會收到 true 的回應。

撤銷登入

您也可以呼叫此圖形 API 端點，讓用戶完全取消對應用程式的授權或撤銷登入：

DELETE /{user-id}/permissions

您必須以目前應用程式的有效用戶存取權杖或應用程式存取權杖來發出此要求。如果要求成功，您的應用程式會收到 true 的回應。如果呼叫成功，該用戶的任何用戶存取權杖都將失效，而必須重新登入。由於您是要取消授權應用程式，所以用戶也必須授予對應用程式的存取權限，就像第一次登入一樣。

平台指南

AndroidiOS網頁