n8n Token 管理最佳實踐：從單一憑證到多專案靈活配置

前言

在 Day 20 的內容中，我們運用了權限控管功能，主要用於設定 HTTP Request 的 token。本文將詳細說明在免費版 n8n 中儲存憑證的方法。

新增 Credential 操作步驟

步驟一：建立新憑證

前往最外層分頁，點選「+ credential」按鈕。

步驟二：選擇憑證類型

選擇要儲存的憑證類型，這裡以 GitLab API 為例。

步驟三：輸入憑證資訊

填入 GitLab Server 與 Access Token 相關資訊。

步驟四：儲存並測試連線

點擊右上角的「Save」按鈕，確保連線測試成功。

步驟五：設定 HTTP Request 節點

回到 Code Review 工作流程的 HTTP Request 節點，可以使用 PRIVATE-TOKEN 來帶入對應的 Access Token 值。

步驟六：修改驗證設定

在 Authentication 選項中，將原本的「None」改為「Predefined Credential Type」。

步驟七：選擇憑證類型

在 Credential Type 中選擇「GitLab API」。

步驟八：完成設定

選擇在步驟一至四中建立的憑證名稱，即可完成設定。

為何在示範中不使用此方式？

在 Day 20 的示範中，我們採用了不同的做法。為了支援多專案的設定，我選擇不使用 Predefined Credential，而是透過程式碼來讓多個專案都能靈活控制其 token。這樣的好處是不需要為每個新專案重複設定相同的工作流程。

參考資料：根據 社群討論，n8n 目前尚未支援在同一個工作流程中使用不同憑證的功能。

工作流程架構

多專案 Token 控制程式碼

// 專案 token 設定: 格式 key:id, value:token
var mapToken = new Map();
mapToken.set("4835", "callduck token"); // callduck
mapToken.set("5036", "beacon token");   // beacon

return $input.all().map(item => {
  const projectId = item.json.body.project.id;
  const iid = item.json.body.object_attributes.iid;
  const token = mapToken.get(projectId.toString());
  const sourceBranch = item.json.body.object_attributes.source_branch;
  
  return {
    json: {
      projectId: projectId,
      iid: iid,
      token: token,
      sourceBranch: sourceBranch
    }
  };
});

小結

透過本文，我們學習了如何使用 Predefined Credential 功能，以及為什麼在多專案場景下，採用程式碼控制 token 的方式會更加靈活實用。這兩種方法各有其適用場景，可以根據實際需求選擇最合適的解決方案。