在共用專案中所有節點/認證類型的認證解析都失敗（Starter 方案）

問題
1

Hi n8n 團隊，

在我們的 Starter 方案實例（swiftdrop.app.n8n.cloud）上，對「任何」節點進行「任何」手動測試執行（「執行步驟」或「執行工作流程」）的認證均會立即失敗，錯誤訊息為：

「問題執行工作流程 — 節點沒有設定任何認證」

這種情況「僅」發生在我們的一個共享專案（「Compra Local」）內，在「個人」專案中從未發生過。重現步驟，已全部確認：

  • 在 Compra Local 中新建原生類型認證（Google Sheets）：失敗。
    • 在 Compra Local 中新建通用認證類型（OAuth2 API、客戶端憑證）：失敗。
      • 在 Compra Local 中新建虛擬通用認證類型（標頭身份驗證）：失敗，同樣的錯誤，立即失敗，不進行任何實際 HTTP 嘗試。
        • 在 Compra Local 中從頭建立全新節點：失敗。
          • 在 Compra Local 中新建整個工作流程的副本：失敗。
            • 重新登入/工作階段：結果相同。
              • 將實例從 2.33.4 更新至 2.34.6：結果相同，沒有改變。
                • 在我們「個人」專案內的「不同」已發佈的生產工作流程中測試相同的節點類型（Google Sheets、原生認證）：運作正常，嘗試實際 API 呼叫，沒有認證錯誤。
                • 我們使用 Starter 方案，包括「1 個共享專案」，Compra Local 是我們唯一的共享專案。這是否可能是在共享專案內執行認證的方案層級限制，但顯示了誤導性錯誤而非清晰的升級提示？請告知。
              • 實例：swiftdrop.app.n8n.cloud、n8n@2.34.6
              • 專案：Compra Local
2

嘿 @swiftdigitaldropi-al，在等待回覆的時候，這些資源可能對你有幫助：

建議的資源

自動配對到你的問題。

文件：

論壇：

@fahmiiireza、@nguyenthieutoan、@barn4k - 你們之前協助過類似的問題，能幫忙看一下嗎？

由 n8n 社群機器人自動建議。這是試驗計畫 - 請在這裡分享回饋。

3

感謝你讓我們知道這一點，我們已建立 IAM-1241 作為內部開發票據來處理此問題。

4

我認為不是這樣。我會建議你試試刪除共享專案並重新建立，看看是否是過時的錯誤，也重新啟動你的實例！如果你繼續遇到問題，請聯絡 help@n8n.io

5

嗨各位，

後續提供一個新的數據點：我試了 @achamm 的建議 — 完全刪除共享項目「Compra Local」，從頭重新建立（新的項目 ID），從 JSON 備份重新匯入兩個工作流程，並直接在新項目中建立了全新的憑證（OAuth2 API、用戶端憑證）。

出現了完全相同的錯誤，立即就出現了：「執行工作流程時出現問題 — 節點未設置任何憑證」，即使在嘗試之間進行完整的瀏覽器重新整理後也是如此。這也是在稍早進行的實例重新啟動/版本更新（2.33.4 → 2.34.6）之後，該更新也沒有造成任何差異。

所以這排除了過時/損壞的項目和過時的工作階段/實例版本作為原因。它在全新項目搭配全新憑證上完全相同地重現，這指向我原來的問題：這是否可能與 Starter 方案的「1 個共享項目」層級有關（即，在此方案上任何共享項目中手動執行的憑證解析方式有問題，而不是這個特定項目）？團隊對 IAM-1241 有任何更新嗎？

很樂意提供任何有幫助的東西 — 全新的工作流程 JSON 匯出、確切重現過程的螢幕錄影等。

6

@swiftdigitaldropi-al 那個 AI 隨意說起一張票證，我不確定它實際上做什麼，所以我不會信任它。我認為它是一個錯誤報告機器人，你能提供工作流程的 JSON 嗎？

如果你把這個工作流程移到個人，它就能正常運作嗎？

你能替換金鑰或重新整理它嗎？我從未是雲端的管理員，只是使用者，所以我不知道完整的流程。

螢幕錄製會很有幫助！

7

@swiftdigitaldropi-al 為你找到了這個！

顯然，n8n 的其中一個 pr 有列出這個 bug！

它被修補了，所以又出現了？
Release n8n@2.25.7 · n8n-io/n8n · GitHub -

我會在 n8n 上提出一個新問題，看他們是否能幫忙 同時，如果可能的話，我會將其用於個人用途

8

嗨團隊，

重要更新，進一步大幅縮小了範圍。我們今天應用了一個解決方案：在我們的「個人」專案中直接建立了 4 個全新的憑證，然後明確將每個憑證共享到共享專案「Compra Local」（設定 > 共享 > 與專案共享）。結果：

  • 直接在 Compra Local 內建立的全新、從零開始的工作流程，使用來自「個人」專案的共享憑證：運作正常。
    • 我們位於 Compra Local 內的現有「工作流程 A」，在其現有節點上使用相同的來自「個人」專案的共享憑證：仍然失敗，出現相同的錯誤，立即發生。
      • 我們甚至使用 n8n 的內建「複製」功能（不是 JSON 重新匯入）來取得新的工作流程 ID：仍然失敗。
        • 最能說明問題的是：我們在該副本內新增了一個全新的 HTTP Request 節點（之前從未存在），將其連接到一個我們剛剛確認在另一個新建立的工作流程中運作正常的憑證——仍然失敗，出現相同的「節點未設定任何憑證」錯誤。
      • 所以問題不在於專案、憑證或節點——具體問題在於這個特定的工作流程物件（以及透過「複製」衍生的所有內容）。工作流程 A 本身存儲的資料/中繼資料中的某些內容正在導致每次執行嘗試都觸發此憑證錯誤，無論任何節點參考什麼憑證。
    • 此工作流程最初是在舊的「Compra Local」專案中建立的（在我們刪除並重新建立專案之前），然後從 JSON 備份重新匯入到新專案中。可能原本導致它出故障的任何狀態已被烘培到工作流程 JSON 本身中，並在重新匯入後倖存下來。
  • 對於遇到此問題的任何人的解決方案：在 UI 中從零開始建立工作流程，而不是重複使用/匯入/複製受影響的工作流程——這是唯一對我們有效的方法。

關於 IAM-1241，我們仍然非常歡迎團隊的任何見解——如果對除錯有幫助，我很樂意共享受影響工作流程的 JSON（已清理）。

9

@Jon 在 github 上做了很多工作，他可能知道更多！

很高興我能幫助你！

10

手動執行也會執行每個上游節點，因此你按下「執行」的節點不一定是沒有認證的節點 - 工作流程 A 中的一個舊版節點仍然指向一個在 Compra Local 中無法解析的認證 id，將在任何請求發出前停止執行。這與你看到的情況相符：全新的工作流程可以正常運作，而工作流程 A 的每個複本即使新增了一個全新節點也會失敗。

開啟工作流程 A，選取所有節點並複製工作流程 JSON，然後檢查每個 "credentials" 區塊，將其 id 與你在 (id 是編輯器中認證 URL 的最後一部分) 中分享的四個個人認證的 id 進行比較。重新在每個 id 不符的節點的下拉式清單中選擇認證，包括停用的節點和未使用分支上的節點，儲存，然後再執行相同的步驟。

如果每個 id 都已相符，請在此貼上失敗執行的完整錯誤詳細資訊 - 它會命名被拒絕的節點，該節點直接指向仍然持有過時參考的節點。