受管理 Meta 帳號和第三方整合

總覽

受管理 Meta 帳號是用於 Meta 商業工具的一種帳號類型。組織可以使用單一登入(SSO)支援、自動佈建帳號等管理功能來管理這些帳號。有了這些帳號,個人可以透過工作憑證來存取 Meta 的商業工具(例如企業管理平台),而不需要使用個人 Facebook 帳號。

由於受管理 Meta 帳號的用意就是只用於工作,因此受管理 Meta 帳號類型具有下列限制:

  • 沒有社群時間軸或 Facebook 動態消息
  • 無法在 Facebook.com 上存取面向消費者的產品或介面,但可存取粉絲專頁發佈的貼文
  • 無法擁有個人資產權限(必須透過商業帳號)
  • 只能授予商業應用程式類型的權限,無法授予 user_* 相關權限,例如 user_friendsuser_posts。請注意,受管理 Meta 帳號仍可完成登入流程要求,但會忽略 user_* 相關權限。
發生錯誤
播放此影片時發生問題。

第三方應用程式整合

正在移轉至受管理 Meta 帳號的商家,會將用戶從使用 Facebook 帳號轉換為使用工作憑證來存取 Meta 的商業工具。用戶必須在截止日期(於商家層級決定)之前完成移轉程序,以維持對 Meta 第一方和第三方工具的存取權限。請特別注意,截止日期是由組織為特定業務部門內的個人用戶專門設定。成功完成移轉後,用戶就能使用其受管理 Meta 帳號(而不是 Facebook 帳號)登入企業管理平台,繼續存取必要的工具和資源。

如果您的應用程式是使用系統用戶存取權杖合作夥伴分享來存取客戶的商家資產,您的第三方整合應該不會受影響。如果您的應用程式使用的是用戶存取權杖(或從用戶存取權杖產生的粉絲專頁存取權杖),則由 Facebook 帳號授予應用程式的權限和商家資產存取權限不會自動轉換到新的受管理 Meta 帳號。用戶必須使用新的受管理 Meta 帳號,重新授予這些商家資產的權限,才能保留應用程式對這些資產的存取權限。




技術供應商準則

主動減少可能發生的 API 呼叫中斷,建議應用程式提供以下功能:

  • 能夠在權杖失效之前主動重新授權資產(例如粉絲專頁、廣告帳號)。此舉可透過定期檢查每個資產的 user_access_expire_time 欄位,並在傳回時間戳記時提示用戶重新授權來完成。
  • 用戶能夠為中斷連結或即將中斷連結的資產批量重新授權資產。此舉可透過在應用程式中提供「重新連結」或「替換過期權杖」按鈕來完成,該按鈕允許用戶一次重新連結所有商家資產,而不是逐一重新連結。該按鈕應觸發伺服器的 API 呼叫,其中包含商家資產編號清單和新存取權杖作為參數。然後,您的伺服器即可為清單中的每個商家資產使用新的存取權杖,並將其安全地儲存在應用程式的資料庫或儲存空間中。
  • 開始測試

    建立沙箱,驗證您的整合可支援受管理 Meta 帳號。

    測試受管理 Meta 帳號

    我們在應用程式主控板的「測試用戶」區塊中,提供用來建立及管理模擬受管理 Meta 帳號的方法,可測試應用程式的「Facebook 登入」實作,以及應用程式使用的任何權限或功能。您可以利用「測試用戶工具」的功能來建立及管理 Meta 帳號測試用戶,以確保在將「Facebook 登入」功能整合至應用程式的過程中,登入受管理 Meta 帳號的用戶能夠有更順暢的體驗。

    這些測試帳號不能與真實的用戶互動,而且您以測試用戶身分產生的任何資料,只有應用程式的其他測試用戶,或是具有應用程式管理員、開發人員或測試人員等角色的真實用戶可以看見。您只能透過應用程式主控板(而不是透過圖形 API)來建立、編輯、刪除及登入測試用戶。

    限制

    請參閱主要文件,瞭解有關測試用戶限制的其他詳細資訊。Facebook 測試用戶的相關限制同樣適用於測試受管理 Meta 帳號,不同的是應用程式僅限 1 個測試受管理 Meta 帳號。

    建立測試工作帳號

    您可以在應用程式主控板中建立測試用戶,請前往「角色」>「測試用戶」面板中的「測試用戶」區塊,選擇「受管理 Meta 帳號」頁籤,然後點擊「建立測試用戶」按鈕。這會開啟可讓您測試帳號的對話方塊。

    「建立測試帳號」對話方塊可讓您:

    • 建立單一測試帳號。
    • 選擇所建立的測試帳號是否要預設安裝應用程式。
    • 選擇要在呼叫中使用的圖形 API 版本
    • 為每個測試用戶授予應用程式的權限

    建立完成後,測試用戶會顯示在「受管理 Meta 帳號」表格中。

    使用受管理 Meta 帳號進行測試

    若要使用測試帳號來測試應用程式,您可以在「Facebook 登入」中使用測試受管理 Meta 帳號的憑證,並授予應用程式所需的任何權限。您也可以代表測試用戶授予權限給應用程式,請前往「受管理 Meta 帳號」表格,在給定的測試用戶那一列中,點擊「選項」欄中的省略符號圖示(•••)。點擊省略符號圖示後,所出現的選項可讓您編輯測試用戶已授予應用程式的權限、為測試用戶產生用戶存取權杖,以及登入測試用戶的帳號。

    在您登入測試帳號後,建議您指派所需的商家資產,以順利完成應用程式整合。您可以前往「企業管理平台設定」來管理測試用戶的商家資產管理組合,以及指派給測試用戶的資產,例如粉絲專頁、廣告帳號和商品目錄。

    使用測試用戶模擬移轉

    您可以模擬 Facebook 用戶轉換到受管理 Meta 帳號時所發生的商家權限變更,進而測試用戶移轉對應用程式的影響。若要使用此功能,請瀏覽 Facebook 測試用戶,點擊「選項」欄中的省略符號圖示(•••),點擊「將商家權限轉移到受管理 Meta 帳號」,然後依照指示操作。

    若要使用此功能,必須滿足下列先決條件:

  • 建立 Facebook 測試用戶
  • 確認 Facebook 測試用戶能夠存取包含資產(例如粉絲專頁或目錄)的商家資產管理組合
  • 確認 Facebook 測試用戶已授予商家資料權限
  • 建立測試用戶,以將商家權限轉移至該測試用戶
  • 完成轉移後,您將能夠:

  • 使用該帳號登入,以預覽用戶引導體驗
  • 使用 Facebook 測試用戶的用戶存取權杖,擷取 user_access_expire_time 欄位
  • Webhook

    Webhook 是一種工具,可讓應用程式在用戶對特定資料資產的存取權限發生變更時,接收相關的自動通知。Webhook 工具可提供及時的自動更新資訊,以增強您的開發應用程式。訂閱後,Webhook 會傳送通知給您的開發應用程式。此通知包含裝載,提供用戶的應用程式範圍編號和過期時間。

    主要功能:

    • 30 天通知:當用戶啟動受管理 Meta 帳號移轉或延長移轉期時,此工具會提前 30 天提醒您。
    • 存取過期提醒:此工具會準確通知您何時會因為移轉而失去存取權限。

    注意:在移轉開始後的 30 天期限開始時會觸發此 Webhook 通知。這可以確保在用戶資料存取權限發生任何重要變更時,您的應用程式能夠及時收到相關通知,讓資料資產的轉移和管理工作順暢無虞。

    訂閱

    若要接收通知,您需要訂閱用戶的受管理 Meta 帳號移轉資訊。我們會建立一個新的 Webhook 供您訂閱。

    如果您是 Webhook 產品的新用戶,請按照我們的 Webhook 入門指南來設定您的 Webhook 配置,以及測試您訂閱的 Webhook 主題。

    若要設定受管理 Meta 帳號 Webhook,請在「應用程式主控板」中,前往「產品」>「Webhook」,從下拉式功能表中選擇「受管理 Meta 帳號」,然後點擊「訂閱此物件」。

    通知

    每當受管理 Meta 帳號移轉到期日(當用戶的混合模式結束時)發生變更時,我們都會發出 Webhook 事件通知。這會是在建立移轉期間,以及如果用戶要求延長其混合模式,並獲准延長混合模式時間時。

    受管理 Meta 帳號事件通知範例:

    {
      "field": "migration_expire_time",
      "value": {
        "user_id": "4444444444",
        "migration_expire_time" => "2024-05-04T10:00:00Z"
      }
    }
    

    移轉 API 和疑難排解

    受管理 Meta 帳號移轉 API 和疑難排解文件說明如何判定哪些用戶和商業帳號正在移轉、其到期日,以及其是否為受管理 Meta 帳號。is_work_account 是一種布林值回傳類型,可指出用戶是否正在使用受管理 Meta 帳號,其位於用戶物件中。user_access_expire_time 欄位屬於時間戳記,可指示何時撤銷用戶存取特定資產的權限。經過此時間戳記之後,用戶應不再具有存取資產的管理權限。後續的 API 呼叫若使用需要存取這些特定資產的 Facebook 用戶存取權杖,將開始傳回權限錯誤。user_access_expire_time 於以下物件中提供:

    限制

    user_access_expire_time 有特定的限制,就是只傳回用戶經由移轉中商家之商家權限所明顯存取的資產過期時間資料。例如,只有當 Facebook 用戶經由移轉中商業帳號成為粉絲專頁管理員時,資料才會傳回時間戳記。移轉中商家所擁有之未直接指派給用戶的粉絲專頁不會產生時間戳記。

    建議使用方式

    您可以將資料用於各種案例,以增強應用程式的功能,並主動減少終端顧客可能遇到的驗證和權限問題:
    • 針對從顧客收到的存取權杖是否屬於受管理 Meta 帳號進行偵錯
    • 針對用戶存取商家資產的權限何時過期時進行偵錯
    • 當用戶存取特定資產的權限即將過期時,傳送通知或提醒給用戶,並提示用戶授權使用帳號來保留功能
    • 處理 API 錯誤,偵測已過期的存取權限,並提供適當的錯誤訊息或指示給用戶,以連結有權存取這些商家資產的帳號

    圖形 API 呼叫範例

    1. 擷取 is_work_account 狀態

    要求
    GET /<API_VERSION>/<USER_ID>?fields=is_work_account
    
    回應
    {
      "id": "<USER_ID>",
      "name": "Romane Richter"
      "is_work_account": true
    }
    2. 擷取 30 天期間的 user_access_expire_time

    要求
    GET /<API_VERSION>/<OBJECT_ID>?fields=user_access_expire_time&access_token=<ACCESS_TOKEN>
    回應
    {
       "user_access_expire_time": "2023-06-23T12:00:00+00:00"
    }
    3. 移轉前的欄位要求將傳回空資料

    要求
    GET /<API_VERSION>/<OBJECT_ID>?fields=user_access_expire_time&access_token=<ACCESS_TOKEN>
    回應
    {}
    
    4. 移轉 30 天後(user_access_expire_time 之後)的要求可能會引發錯誤

    要求
    GET /<API_VERSION>/<OBJECT_ID>?fields=user_access_expire_time&access_token=<ACCESS_TOKEN>
    回應
    {
      "error": {
        "message": "(#100) Object does not exist, cannot be loaded due to missing permission or reviewable feature, or does not support this operation. This endpoint requires the 'pages_read_engagement' permission or the 'Page Public Content Access' feature or the 'Page Public Metadata Access' feature. Refer to https://developers.facebook.com/docs/apps/review/login-permissions#manage-pages, https://developers.facebook.com/docs/apps/review/feature#reference-PAGES_ACCESS and https://developers.facebook.com/docs/apps/review/feature#page-public-metadata-access for details.",
        "type": "OAuthException",
        "code": 100,
        "fbtrace_id": "AZdHiJUBflrZnE-RNKrHAah"
      }
    }
    

    權限和錯誤

    若要存取 user_access_expire_time 並對其發送 API 呼叫,開發人員應確認獲得授予載入這些物件的必要權限。在提供的範例中,如果 object-id 參照商家物件編號,則用戶必須至少獲得授予載入物件的 business_management 權限。詳情請參閱這裡
    若在過期後嘗試存取資產,API 回應會傳回 100 且類型為 OAuthException. 的一般錯誤。這表示無法再透過 API 存取該物件,因為用戶不再擁有存取該資產的權限。

    另請參閱

    請前往技術供應商常見問題

    API call disruptions related to managed Meta account migrations might be caused by:

    1. Users failing to migrate before the deadline set by their business/organization
    2. Users failing to re-authenticate with your apps using the managed Meta accounts