摘要：最近基于開發(fā)了一款圖床插件，現(xiàn)在已經(jīng)開源并上架應(yīng)用商店。通過方法把轉(zhuǎn)成，然后放在里測試一下看來效果是的，接下來就是對圖床插件進行開發(fā)的步驟了。至此，整個插件的開發(fā)發(fā)布流程就已經(jīng)完成了。

最近基于 Github API 開發(fā)了一款圖床 Chrome 插件 Picee，現(xiàn)在已經(jīng)開源并上架 Chrome 應(yīng)用商店。當中的過程涉及到一些有趣的知識點，故將其記錄下來。

Github地址：https://github.com/jrainlau/p...
Chrome商店下載地址：Picee

平時有寫點東西的習(xí)慣，但是奈何一直找不到合適的圖床。有人推薦以微博或者七牛來做圖床，但是總給我一種”受制于人“的感覺，不知道什么時候就會被各種限制，比如禁止圖片外鏈等等。后來發(fā)現(xiàn)其實 Github 是非常適合做圖床的，因為倉庫里的文件都可以通過 https://raw.githubusercontent.com 這個鏈接直接外鏈以供下載。但是如果為了寫個文章而每次添加圖片都需要一頓 Git 操作，那么寫作體驗必定非常不好，如果有更方便的辦法就好了——那就是Github API。

Github 提供了一套完善的 API 以供操作，幾乎涵蓋了開發(fā)一個完整 Github 客戶端的所有功能。API 分為 REST 風(fēng)格的 v3 版本和 GraphQL 風(fēng)格的 v4 版本。為了使用方便，我選擇的是 v3 版本。具體的 API 細節(jié)可以在官方文檔查看。

要制作一個圖床應(yīng)用，我們只需要用到上傳文件的 API 即可。但是在調(diào)用這個 API 之前，首選需要用戶對應(yīng)用進行授權(quán)，也就是所謂的登錄操作。

對于一般的”查看”操作，是不需要授權(quán)的，比如獲取用戶的公開信息，獲取公有倉庫的 issues 等等。但是有兩個場景是需要授權(quán)的，其一是任何對于倉庫的“增刪改查”操作（包括提交 issue，評論等）；其二則是對于某 IP 有 API 的調(diào)用次數(shù)限制，若這個 IP 調(diào)用 Github API 的次數(shù)過多則需要授權(quán)。

那么授權(quán)應(yīng)該怎么做呢？官方提供了三種辦法，分別是 Basic，oAuth2 token和oAuth2 key/secret。

也就是最傳統(tǒng)的賬號密碼授權(quán)方式，我們可以在命令行用 curl 來測試之：

curl -u "賬號:密碼" https://api.github.com

如果是正確的賬號密碼，則會返回一系列的內(nèi)容，否則會返回錯誤信息。

對于開發(fā)來說，我更推薦使用 Postman 來對 API 進行測試：

點開右邊的 code ，可以看到 JS 代碼：

其中 xhr.setRequestHeader("Authorization", "Basic xxxxxx");就是我們需要設(shè)置的授權(quán) header，當中的 xxxxxx 是這么來的：

btoa(username + ":" + password)

對于賬號密碼來說，輕易地在第三方平臺輸入其實并不那么安全，那么有沒有辦法既能保障賬戶的安全，又能實現(xiàn)授權(quán)的需求呢？答案就是 oAuth token。

簡單來說，oAuth token 相當于用戶提供給第三方的一張授權(quán)令牌，第三方通過這張令牌可以獲得用戶所允許使用的一系列權(quán)限，但是卻不會知曉用戶的賬號和密碼，于是便得以在有效保障用戶賬號安全的同時，又能方便地對第三方應(yīng)用進行授權(quán)。

在 Github 里，可以在這個地方設(shè)置生成具有某些權(quán)限的 token：

最后在 Postman 里選擇 OAuth 2.0 或者 Bearer Token，然后把這串 token 粘貼進去即可。

其中的授權(quán) header 為 Bearer token。

這種授權(quán)方式是通過生成一對 key/secret，來允許第三方獲取用戶的公開信息，是一種只讀的授權(quán)方式，無法對倉庫進行改寫操作，主要用于第三方登錄，故在這里不適用。更多關(guān)于 key/secret 的內(nèi)容可以查看阮一峰的《GitHub OAuth 第三方登錄示例教程》，寫得非常生動詳細。

在了解了三種授權(quán)方式之后，我們就可以進行下一步操作，實現(xiàn)圖片的上傳了。

圖片上傳使用了 content API 的 create-a-file 接口，通過 PUT 發(fā)送一條文件內(nèi)容為 base64 的請求到指定的倉庫目錄。

這里著重圈出了必須把文件進行 base64 編碼，否則接口調(diào)用將會出錯。

通過 btoa("hello world) 方法把 hello world 轉(zhuǎn)成 base64，然后放在 Postman 里測試一下：

看來效果是OK的，接下來就是對圖床插件進行開發(fā)的步驟了。

除了看官方文檔學(xué)習(xí)插件開發(fā)以外，也可以參考由@小茗同學(xué) 所寫的《【干貨】Chrome插件(擴展)開發(fā)全攻略》，里面對于 Chrome 插件的開發(fā)有著詳細的敘述，非常值得一讀。

讀完上面推薦的文章之后，我選擇使用 VueJS 進行開發(fā)。由于項目比較簡單，所以我沒有用任何的打包工具，直接通過 script 的方式引入 VueJS。值得注意的是，Chrome 插件不允許行內(nèi) script 和行內(nèi) style，所以任何的 css 和 js 文件都必須通過本地文件鏈接的方式去使用。另外由于我們的 JS 是運行在 Chrome 環(huán)境的，所以可以放心大膽地使用 es 模塊和 async/await 等高級語法，而無需任何的構(gòu)建工具參與。

但是在使用 VueJS 的第一步我就遇到了問題，綁定了 new Vue() 的 DOM 元素竟然顯示不出來。經(jīng)過查證，原來 Chrome 插件有 Content Security Policy (CSP) 限制，默認是不支持 eval()，new Function() 等方式運行代碼的，而完整版的 VueJS 恰好是這么干的（官網(wǎng)有說），所以就出問題了。那么怎么解決呢？很簡單，在 manifest.json 里面聲明一下就好了：

// manifest.json

{
  // ...
  "content_security_policy": "script-src "self" "unsafe-eval"; object-src "self""
}

這里我采用的是 popup 形式的插件，彈出來的窗口就是項目所定義的 index.html。如果要調(diào)試插件的頁面，可以直接在插件彈出的窗口點擊右鍵，然后點擊“檢查”，就會彈出我們熟悉的開發(fā)者工具了。如果插件文件有改動，除了重新打開插件以外，我們也可以在開發(fā)者工具通過 cmd + r 去直接刷新，省去了多次點擊的麻煩。

經(jīng)過前面的準備，我們已經(jīng)掌握了如何對 Github API 進行授權(quán)然后上傳圖片的辦法，接下來就是在業(yè)務(wù)邏輯里去實現(xiàn)它們。我封裝了一下原生的 fetch 方法，讓它更方便調(diào)用：

const $fetch = (options) => {
  return window.fetch(options.url, {
    method: options.method || "GET",
    headers: {
      "Content-Type": "application/json",
      "Authorization": localStorage.getItem("picee_token")
    },
    body: JSON.stringify(options.body) || null,
    mode: "cors"
  })
    .then(async res => {
      if (res.status >= 200 && res.status < 400) {
        return {
          status: res.status,
          data: await res.json()
        }
      } else {
        return {
          status: res.status,
          data: null
        }
      }
    })
    .catch(e => e)
}

export default $fetch

請求接口時攜帶的授權(quán) header 所需的 token，我把它們存放在插件的 localStorage 下，方便調(diào)用。

有了請求接口的方法以后，接下來就要完成選擇圖片和把圖片轉(zhuǎn)化成 base64 的工作。這里我復(fù)用了另一個作品里的 chooseImg.js 和 paste.js 方法，最終能夠支持以選擇、粘貼、拖拽的方式上傳圖片。

剩下的一些功能細節(jié)就不贅述了，代碼非常簡單，建議讀者們自行查閱。

準備好了 logo，描述等善后工作之后，就可以正式提交應(yīng)用發(fā)布了。我們可以在開發(fā)者信息中心里面把插件提交上去，填入必要的信息以后點擊發(fā)布，等待審核完成。但是在此之前，你必須支付5美元的開發(fā)者注冊費，國內(nèi)的開發(fā)者在完成這一步的時候可能會遇到蠻大的困難，這一個問題在知乎也有討論：如何在中國使用信用卡支付“Chrome 網(wǎng)上應(yīng)用店”開發(fā)者注冊費？。我是通過萬能的淘寶搞定的。

在完成注冊之后和發(fā)布以后，就能看到插件的主頁了：

值得注意的是，剛發(fā)布的插件是暫時不能被搜索出來的，需要等待一段時間以后才能搜索出來。

至此，整個插件的開發(fā)——發(fā)布流程就已經(jīng)完成了。