manifest.json 權限會原封不動進入建置產物。各目標之間的差別在於哪些權限會被保留,所以請從這裡看起。
各目標如何處理該權限
一份宣告了"proxy" 的資訊清單,建置結果如下:
Safari 建置會印出原因:
設定固定 proxy
在背景 service worker 設定 proxy,那裡可以使用該 API:proxy 權限是必要的,Chromium 建置通常還需要涵蓋目標網站的主機權限。
隨擴充功能提供 PAC 指令碼
PAC 指令碼不是資訊清單欄位,因此打包器不會把它當成進入點。它不會被計算雜湊、改寫路徑,也不會自行進入產物。有兩條可行路線。 把指令碼當成 data 內嵌傳入:public/ 目錄裡的內容會原樣複製進建置產物,所以放在那裡的 PAC 檔案會以同名出現在 dist/<browser>/。從你自己的擴充功能來源以 fetch 讀取它,再把文字當成 data 傳入。public/ 的作用請見特殊資料夾。
處理 proxy 驗證
需要憑證的 proxy 會觸發chrome.webRequest.onAuthRequired。Manifest V3 移除了阻擋式 webRequest,因此要回應該挑戰,除了 webRequest 之外還需要 webRequestAuthProvider 權限。
攔截網路請求介紹了 Manifest V3 保留的請求 API,以及 declarativeNetRequest 在哪些地方取代了阻擋式 API。
Firefox 的機制不同
Firefox 有一個同名權限下的 proxy API,背後的模型並不一樣。Firefox 透過browser.proxy.onRequest 讓擴充功能逐一請求做決定,而不是儲存一份設定物件。
Extension.js 不會針對這個差異提出警告。它的 Gecko 相容性警告涵蓋的是其他 API,因此 Chromium 形態的 chrome.proxy.settings.set 呼叫進入 Firefox 建置時不會有任何訊息。請在 MDN 確認該 API,並在發布前測試 Firefox 目標。
也可以只代理開發用瀏覽器
有時你想代理的是開發期的瀏覽器,而不是擴充功能。這時請傳瀏覽器參數,而不是使用擴充功能 API:browserFlags 設定項。

