每種類型的登入流程都有各自的要求權限方法,視乎您的平台和您所選的整合「Facebook 登入」方式而定:
FB.login
函數呼叫中使用 scope
選項。scope
參數加入流程重新導向的登入對話框網址。scope
參數。請注意,上述許多 API 均可以在應用程式的使用壽命期間隨時用於要求獲取其他權限,而不只是在首次登入時要求獲取權限。
一般而言,應用程式要求獲取的權限越多,用戶就越不可能使用 Facebook 登入您的應用程式。事實上,我們的研究結果顯示,如果應用程式要求獲取多於四項權限,完成登入流程的人數就會大幅降低。
以下幾項守則可供您在登入前後要求權限時作參考之用:
只要求對應用程式所必需的權限。
只在有必要的情況下要求獲取權限。例如,如果您的應用程式要顯示用戶所在地點附近的景點,請您在顯示這項資訊前要求獲取 user_location
,讓用戶更加了解您要求獲取這項權限的原因。
分別要求獲取讀取和發佈權限。如需詳細資訊,請參閱下文。
切勿預先要求獲取您認為日後可能會用到的權限。用戶會感到可疑,更有機會因此拒絕使用您的應用程式。
事前告訴用戶您要求權限的原因。解釋您為什麼要存取某些資訊,這樣做可能會加強用戶同意分享這些資訊的意願。
應用程式應要分別要求獲取讀取和發佈權限。規劃應用程式時,您應該在用戶首次登入時要求獲取最低限度的讀取權限,待用戶確實需要額外權限(例如用戶想從應用程式內建立開放式圖表動態)時,您才應再要求獲取任何發佈權限。這樣做可以提供最佳的用戶體驗,並能優化轉換。
如果您的應用程式接連要求讀取和發佈權限,您有可能會收到開發人員警示。若要停止收到這些警示,您可以分別提出要求,或者按照以下例外狀況適用的守則操作。
在少數狀況下,您的應用程式需要預先要求發佈權限(例如您的應用程式只會將用戶心情發佈到 Facebook),此時您只應在首次登入時要求最低限度的讀取權限。當用戶登入後,再向用戶顯示畫面,解釋為什麼您的應用程式需要發佈權限,然後讓用戶點擊按鈕,選擇同意發佈權限的要求。這樣做可以向用戶提供更多說明,並能改善轉換。
唯獨有一種情況,您可能必須接連要求獲取讀取和寫入權限,那就是在您第一次將以電郵為基礎的帳戶與用戶的 Facebook 帳戶建立關聯的時候。當用戶想在 Facebook 生活時報分享動態時,通常就會這樣做。當您的應用程式建立登入對話框時,用戶將會連續看到兩個對話框,一個用來將帳戶連結至您的應用程式,另一個則是要求獲取發佈權限。在這種情況下,請確保您要求獲取的讀取權限只有 public_profile。由於用戶想從您的應用程式發佈內容,而且通常沒有興趣提供額外的讀取權限,因此這樣做可以提供最佳的用戶體驗,並能改善轉換。
Facebook 讓用戶可對應用程式的授權擁有完整控制權,而這種控制權超出用戶在看到登入對話框時所要求的範圍。用戶可以在登入流程期間選擇拒絕授予特定權限,也可以隨時在 Facebook 私隱設定中撤銷權限。應用程式必須先檢查權限是否有效,然後再在需要使用這些權限時執行 API 呼叫。例如,首先檢查應用程式是否仍有 email
權限,然後再傳送訊息。
如果是網頁應用程式,則我們會提供 Graph API 端點,以供您檢索獲授予權限的清單:
GET /{user-id}/permissions
這種呼叫必須配合用戶存取憑證或您的應用程式存取憑證一同使用。呼叫將會傳回 JSON 字串,其中包含應用程式已獲授予的權限名稱及其狀態:
{ "data": [ { "permission": "public_profile", "status": "granted" }, { "permission": "email", "status": "granted" }, { "permission": "user_friends", "status": "declined" } ] }
當應用程式要求獲取權限時,用戶可能會完全拒絕這些權限、未完全授予這些權限,或在稍後變更權限。為了提供出色的使用體驗,應用程式的設計應該要具備處理這些情況的能力。
首先,應用程式應該要能夠處理任何已要求但未獲授予的權限:
{ "error": { "message": "(#200) The user hasn't authorized the application to perform this action", "type": "OAuthException", "code": 200 } }
如果偵測到用戶已拒絕部分權限或全部權限,應用程式可能會將用戶再一次導向登入流程,然後要求獲取任何所需的權限。不過,這是欠佳的使用體驗,請盡可能避免此類情況。如果用戶主動選擇拒絕向應用程式授予特定權限,這些用戶就不太可能改變心意,就算一直提示用戶結果也是一樣。請改為採取以下操作:
如果用戶拒絕登入對話框,請提前明確地解釋您會要求每項權限的原因,然後再讓用戶點擊或點按以選擇返回權限要求對話框。請勿在未提供解釋前便即時將用戶重新導向權限要求對話框。
除非您將 auth_type=rerequest
連同您的要求一併傳遞,否則如果用戶拒絕向您的應用程式授予任何權限,登入對話框都不會讓您的應用程式重新要求獲取權限。
在用戶已授予某些權限但未授予其他權限的情況下,請只在需要使用未獲授予的權限時才提示用戶授予相關權限。例如,如果您的應用程式會向用戶傳送確認電郵,則只需在用戶提交訂單時才要求獲取 email
。
除非您在登入對話框中所要求獲取的權限對您應用程式的功能至關重要,而且應用程式的部分功能無法在沒有這些權限的情況下運作,否則請讓用戶在不授予這類權限的情況下繼續使用您的應用程式。
如果在用戶拒絕授予權限之後,您的應用程式一再將用戶導向權限對話框,您就有可能會收到開發人員警示。若要停止收到這些警示,請按照這些守則操作。
應用程式可以讓用戶撤銷先前授予的權限。例如,應用程式可以提供一個設定頁面,以便用戶停止接收電郵訊息。該設定頁面也可同時撤銷 email
權限。
您可以向 Graph API 端點執行呼叫,以撤銷特定權限:
DELETE /{user-id}/permissions/{permission-name}
您必須使用用戶存取憑證或目前應用程式的應用程式存取憑證,方可作出這種要求。如果這項要求成功,您將收到 true
回應。
您也可以讓用戶完全解除對應用程式的授權或撤銷登入,方法是向此 Graph API 端點執行呼叫:
DELETE /{user-id}/permissions
您必須使用有效的用戶存取憑證或目前應用程式的應用程式存取憑證,方可作出這種要求。如果這項要求成功,您的應用程式將收到 true
回應。如果這項呼叫成功,則這名用戶的任何用戶存取憑證都將設定為無效,而且用戶將須再次登入。因為您正在將您的應用程式解除授權,所以用戶也將必須向您的應用程式授予存取權限,情況就如用戶首次登入時一樣。