我第一次串接 Facebook Graph API：從建立Meta應用程式到取得Access Token

圖片說明：Meta應用程式的Facebook Login設定頁，我先以localhost回呼網址測試OAuth授權流程。

建立 Meta 應用程式後，我先處理 OAuth 設定

決定開始串接 Facebook Graph API 後，我先在 Meta for Developers 建立自己的應用程式，並加入 Facebook Login 相關功能。

這也是 PageFlow 從靜態原型進入實際串接階段的第一步。前一個階段，我主要使用模擬資料確認帳號管理、粉絲專頁和排程流程；到了這裡，才真正開始處理 Facebook 的登入與授權問題。

建立應用程式後，我取得了 App ID 和 App Secret。App ID 用來識別應用程式，而 App Secret 屬於敏感資料，所以我沒有把它寫進前端程式，也不會放進文章或公開截圖中，而是透過後端環境變數管理。

我先用 localhost 測試 OAuth 回呼流程

實際設定時，我首先需要確認的是 OAuth 回呼網址。

使用者完成 Facebook 登入和授權後，Meta 需要把使用者帶回預先設定的網址，因此後臺設定的 Valid OAuth Redirect URI 必須和程式實際使用的回呼網址一致。

在目前的開發階段，我先使用 localhost 測試 OAuth 流程，確認登入、授權和回傳流程能夠接起來，再規劃正式部署環境使用的回呼網址。

這個步驟看起來只是填寫一個網址，但它其實是我從 PageFlow 靜態介面走向真正 Facebook 帳號授權的第一個實作環節。

圖片說明：Facebook OAuth登入畫面，使用者在Facebook官方頁面完成登入與授權，系統不需要儲存Facebook密碼。

OAuth 授權不是把 Facebook 密碼交給 PageFlow

實際開始串接 OAuth 後，我更清楚地理解到一件事：PageFlow 並不需要取得或儲存使用者的 Facebook 密碼。

登入過程是在 Facebook 官方頁面完成。PageFlow 負責把使用者導向 Facebook 的登入與授權頁面，使用者完成登入並同意相關許可權後，Facebook 再把授權結果帶回我設定好的回呼網址。

這也是我實際測試 Facebook Login 時特別注意的地方。密碼輸入發生在 Facebook 的頁面，而不是 PageFlow，因此我的系統不應該設計任何要求使用者輸入 Facebook 密碼的功能。

Access Token 才是後續串接需要處理的資料

完成授權後，後續 API 操作會涉及 Access Token。對 PageFlow 來說，真正需要管理的是授權後取得的 Token、它對應的帳號、取得了哪些許可權，以及這個帳號實際可以管理哪些 Facebook 粉絲專頁。

Access Token 也不是 Facebook 密碼，更不代表取得 Token 之後就自動擁有所有粉絲專頁的操作許可權。實際能做哪些事情，仍然取決於使用者授予的許可權、Facebook App 的設定，以及該帳號本身具有的粉絲專頁許可權。

因為 Token 屬於敏感的授權資料，所以我不會把完整 Token 放進文章、公開截圖或前端頁面。正式開發 PageFlow 時，這些資料也需要在後端妥善儲存和管理。

對我來說，做到這一步之後，PageFlow 才真正開始從「登入 Facebook」走向下一個問題：如何取得這個帳號實際可以管理的粉絲專頁，並把它們加入 PageFlow。

圖片說明：Meta應用程式發布頁面列出隱私權政策、公司驗證與存取許可權驗證等要求，測試成功不代表應用程式已經正式上線。

取得 Access Token，不代表 PageFlow 已經可以正式使用

一開始測試 Facebook Login 時，我以為只要登入流程能夠完成，而且成功取得 Access Token，就代表 PageFlow 已經具備基本的使用條件。

但實際測試後，我才發現「OAuth 能夠跑通」和「應用可以正式提供給其他 Facebook 使用者」其實是兩件不同的事情。

在開發階段，我可以使用已經加入應用程式的帳號進行登入和授權測試，所以整個流程看起來已經可以正常運作。但這並不代表其他 Facebook 帳號也能直接使用 PageFlow 完成授權。

如果之後要讓更多符合條件的帳號正式使用，還需要繼續處理應用程式的基本資料和正式發布要求，例如隱私權政策網址、應用程式圖示、應用程式類別和資料刪除相關設定。至於 PageFlow 最後需要使用的 Facebook 許可權，我也需要按照實際功能確認是否涉及進一步的 App Review 或其他驗證要求。

這次測試讓我把 PageFlow 的開發分成兩個階段：

第一階段是讓 Facebook Login、OAuth 回呼和 Access Token 流程真正跑通；第二階段才是確認正式環境需要完成哪些設定和審核。

對我來說，這個差別很重要。因為測試帳號成功登入，只能證明目前的串接流程可以工作，並不能直接代表 PageFlow 已經符合正式發布的所有條件。

圖片說明：完成Facebook授權後，PageFlow將授權帳號與可管理的粉絲專頁建立對應關係，測試資料顯示15個帳號與130個粉絲專頁。

我實際串接後發現，Token 並不是隻有一種

完成 OAuth 授權後，我開始處理 PageFlow 要怎麼辨識「這個 Facebook 帳號到底可以管理哪些粉絲專頁」。

這時我才發現，實際串接時不能把所有 Token 都當成同一種資料處理。

系統首先需要處理與授權帳號相關的 User Access Token，並在取得相應許可權的情況下，查詢這個帳號可以管理的 Facebook 粉絲專頁。接著再取得每個粉絲專頁的 Page ID，以及後續操作所需要的授權資料。

對 PageFlow 來說，我最後真正需要建立的是一個很清楚的對應關係：

哪個 Facebook 帳號完成了授權 → 這個帳號可以管理哪些粉絲專頁 → PageFlow 對這些專頁目前具有哪些可用許可權。

這也讓我重新理解 App ID、App Secret 和 Access Token 之間的差別。

App ID 主要用來識別我的應用程式，App Secret 則屬於後端使用的敏感憑證，但它們本身都不能取代 Facebook 使用者的實際授權。要讓 PageFlow 後續對粉絲專頁執行獲準的操作，仍然需要按照 Meta 的授權流程取得相應的 Token 和許可權。

Token 失效也是排程工具必須處理的問題

對一般登入功能來說，授權失效可能只是要求使用者重新登入；但對 PageFlow 這種排程工具來說，問題會更直接。

如果某個帳號的 Token 失效、許可權被取消，或者帳號對粉絲專頁的管理許可權發生變化，原本已經建立好的排程就可能受到影響。

這也是為什麼我不希望等到貼文預定發布的那一刻，才發現授權已經不能使用。

目前我的設計方向是不儲存 Facebook 密碼，只儲存 PageFlow 執行功能所需要的授權資料和帳號對應關係。敏感 Token 只在後端處理，前端管理頁面只需要讓我看到帳號是否已連線、授權狀態是否正常，以及哪些帳號需要重新授權。

這樣一來，前面靜態原型中設計的「帳號狀態」就不再只是一個模擬欄位，而是開始對應到真正的 Facebook 授權狀態。

圖片說明：PageFlow發布佇列記錄實際測試結果，當帳號授權失效或發布許可權不足時，系統會標示失敗並停止繼續發布。

第一次測試發布時，我才發現 API 成功不等於貼文一定正常

完成帳號與粉絲專頁的授權關係後，我開始透過 Facebook Graph API 實際測試貼文發布。

一開始，我主要注意 API 有沒有回傳成功。後來實際測試幾次後才發現，對 PageFlow 這種排程工具來說，只記錄「成功」或「失敗」其實不夠。

我還需要知道這次發布使用的是哪一個授權帳號、目標是哪一個 Page ID、API 回傳了什麼結果，以及最後能不能在預期的粉絲專頁看到貼文。

API 接受請求後，我還會再確認實際發布結果

測試過程中，我也遇過 API 已經接受請求，但貼文的顯示狀態或實際結果和我原本預期不同的情況。

遇到這種問題時，我沒有讓系統直接不斷重送相同內容，而是先檢查目標粉絲專頁是否正確、目前使用的授權資料是否對應該專頁、許可權是否仍然有效，以及應用程式目前的設定狀態。

這個測試也讓我發現，排程工具不能只負責「到了時間就呼叫 API」。如果沒有把每一次發布的結果記錄下來，等到管理的粉絲專頁數量增加後，很難知道到底是哪一個帳號、哪一個粉絲專頁或哪一筆排程出了問題。

我把發布失敗也當成排程流程的一部分

因此，我開始在 PageFlow 的發布佇列中記錄每一筆任務的執行狀態。

如果遇到 Token 失效、許可權不足或需要重新授權等問題，相關任務會被標示為失敗並停止繼續發布，而不是在背景持續重試。

等我確認授權或許可權問題已經處理完成後，再重新安排受影響的發布任務。

對我來說，做到這一步之後，PageFlow 才不只是「可以呼叫 Facebook API 發文」，而是開始具備我真正需要的排程管理能力：知道哪些貼文成功、哪些失敗，以及失敗後應該從哪裡開始檢查。

這次串接讓我確認的事情

這次實作讓我確認，Facebook排程工具真正困難的部分，不只是呼叫一個發布API，而是完整處理應用程式設定、OAuth回呼、帳號授權、Token儲存、粉絲專頁同步、許可權失效及重新授權。

目前這套功能仍是我持續開發中的專案記錄，不是已經對外提供的商業服務。下一階段我會繼續整理Token有效期限、重新授權流程、發布佇列與錯誤記錄，讓系統在管理多個帳號與大量粉絲專頁時，能夠更安全地運作。