Skip to main content
自動化提交到 Chrome Web Store 需要兩個識別碼與一組憑證： OAuth 三件組與服務帳戶只需要其中之一，不必兩者都設。兩者都設定時，服務帳戶優先。

​
前置條件

Chrome Web Store API 無法建立新項目。一個新擴充功能的第一次上傳，必須在開發者 主控台（Developer Dashboard）中手動完成。那組 32 個字元的 extension ID，要到 那次上傳之後才存在。
  1. 在 Chrome Web Store 開發者主控台 註冊一個開發者帳戶。註冊需要一次性支付 5 美元。
  2. 建置一個商店 zip（npx extension build --browser chrome --zip）。
  3. 在主控台中手動上傳這個 zip，藉此建立該項目。
  4. 從該項目的主控台 URL 中複製 extension ID。
  5. 複製 publisher ID：它就是你開發者主控台 URL chrome.google.com/webstore/devconsole/<UUID> 裡的那組 UUID。
Extension.js 不會替你提交到任何商店，因此它從來不會向你索取這些值。 本頁講的是手動路徑：自己建立 OAuth 用戶端，自己產生 refresh token。
不要用 Google OAuth Playground 產生 refresh token。Playground 需要一個 Web application 類型的用戶端與它的重新導向 URI，而 Chrome Web Store 的流程需要 Desktop app 類型的用戶端。把兩者湊在一起會以 redirect_uri_mismatch 失敗。

​
建立 OAuth 用戶端

  1. 在 Google Cloud Console 建立或選擇一個專案。
  2. 為該專案啟用 Chrome Web Store API。
  3. 在憑證頁面建立一個 OAuth client ID，應用程式類型選 Desktop app（桌面應用程式）。Web application 類型的用戶端在這裡行不通。
  4. 複製 client ID 與 client secret。
  5. 用 127.0.0.1 上的 loopback 同意流程為該用戶端產生一組 refresh token， 這正是 Desktop app 類型用戶端接受的重新導向。該權杖必須取得 https://www.googleapis.com/auth/chromewebstore 這個 scope 的授權。 改用服務帳戶可以略過這一步，下一節會說明。
如果你的 OAuth 同意畫面仍處於 Testing（測試）狀態，Google 會在 7 天後撤銷 refresh token。你的第一次提交會成功，而這份憑證一週後就失效了。請把同意畫面 發布出去（In production），或改用服務帳戶，服務帳戶沒有這種到期問題。

​
替代方案：服務帳戶

Google Cloud 服務帳戶完全避開 OAuth 同意流程，是 CI 場景中最穩定的選擇：
  1. 在 Google Cloud Console 中，於那個已啟用 Chrome Web Store API 的同一個專案裡 建立一個服務帳戶。
  2. 為它建立一組 JSON 金鑰並下載該檔案。
  3. 在 Chrome Web Store 開發者主控台中開啟 Account（帳戶），把這個服務帳戶的 電子郵件地址加入你的發布者帳戶。一個發布者帳戶對應一個服務帳戶。
把 JSON 金鑰的內容（或指向該檔案的路徑）作為憑證提供。設定了服務帳戶時， 它會優先於 OAuth 三件組。

​
影響範圍與輪替

Chrome 憑證是發布者帳戶層級的，而不是每個擴充功能各自獨立。一個能發布某個項目 的權杖，也能發布同一個發布者帳戶底下的每一個項目。請據此看待 refresh token 與 服務帳戶金鑰；如果你在替別人管理擴充功能，最好每個客戶各用一個獨立的發布者帳戶。
要輪替憑證，就產生一組新的 refresh token 或新的服務帳戶金鑰，並在存放它的地方 重新填入。

​
名稱對照

每個值對應的環境變數：

​
商店頁中繼資料仍然要手動填

Chrome Web Store API 不接受任何商店頁中繼資料。商店文案、截圖與權限說明都要在 開發者主控台中手動填寫。把它們放在 STORE.md 的 Chrome 小節裡，這樣每次重新提交都從同一份納入版本控制的來源複製。