https://github.com/zep03/koa-coderhub/commits/main

一、coderhub功能接口說明

Coderhub旨在創建一個程序員分享生活動態的平臺。
完整的項目接口包括：

面向用戶的業務接口；

面向企業或者內部的后臺管理接口；

完成的功能如下：
1.用戶管理系統
2.內容管理系統
3.內容評論管理
4.內容標簽管理
5.文件管理系統
其他功能其實都是非常相似的

二、項目的搭建

功能一：目錄結構的劃分：

按照功能模塊劃分；

按照業務模塊劃分；

功能二：應用配置信息寫到環境變量

編寫.env文件

通過dotenv加載配置的變量

npm 官方文檔的這樣介紹 dotenv: Dotenv 是一個零依賴的模塊，它能將環境變量中的變量從 .env 文件加載到 process.env 中。

功能三：創建和啟動服務器

• 基于koa創建app；
  -啟動服務器；

三、用戶注冊接口

用戶注冊接口編寫流程：

注冊用戶路由router編寫；

處理函數的控制器controller編寫；

操作數據庫的service編寫；

數據庫連接操作：mysql2
5. 創建數據庫連接；
6. 測試數據庫連接是否成功；

注冊用戶校驗

用戶名或密碼不能為空

用戶名沒有被注冊過

密碼加密存儲:

四、用戶登錄接口

用戶登錄接口編寫流程：

授權router的編寫；

處理函數的controller編寫；




實現動態加載路由：

驗證的中間件：
3. 賬號和密碼是否為空；
4. 用戶名是否存在；
5. 校驗密碼是否一致；

登錄成功返回憑證：
6. cookie+session；
7. Token令牌；

五、為什么需要登錄憑證呢？

web開發中，我們使用最多的協議是http，但是http是一個無狀態的協議。

無狀態的協議？什么叫做無狀態協議呢？
舉個例子：
我們登錄了一個網站 www.coderhub.com（當然這個網站不存在，是我要開發一個的）;
登錄的時候我們需要輸入用戶名和密碼：比如用戶名coderwhy，密碼Coderwhy666.;

登錄成功之后，我們要以coderwhy的身份去訪問其他的數據和資源，還是通過http請求去訪問。

• coderhub的服務器會問：你誰呀？
• coderwhy說：我是coderwhy呀，剛剛登錄過呀；
• coderhub：怎么證明你剛剛登錄過呀？
• coderwhy說：這。。。，http沒有告訴你嗎？
• coderhub：http的每次請求對我來說都是一個單獨的請求，和之前請求過什么沒有關系。

看到了吧？這就是http的無狀態，也就是服務器不知道你上一步做了什么，我們必須得有一個辦法可以證明我們登錄過。

六、認識cookie

Cookie（復數形態Cookies），又稱為“小甜餅”。類型為“小型文本文件，某些網站為了辨別用戶身份而存儲在用戶本地終端（Client Side）上的數據。

• 瀏覽器會在特定的情況下攜帶上cookie來發送請求，我們可以通過cookie來獲取一些信息；

Cookie總是保存在客戶端中，按在客戶端中的存儲位置，Cookie可以分為內存Cookie和硬盤Cookie。

• 內存Cookie由瀏覽器維護，保存在內存中，瀏覽器關閉時Cookie就會消失，其存在時間是短暫的；
• 硬盤Cookie保存在硬盤中，有一個過期時間，用戶手動清理或者過期時間到時，才會被清理；

如何判斷一個cookie是內存cookie還是硬盤cookie呢？

• 沒有設置過期時間，默認情況下cookie是內存cookie，在關閉瀏覽器時會自動刪除；
• 有設置過期時間，并且過期時間不為0或者負數的cookie，是硬盤cookie，需要手動或者到期時，才會刪除；

七、cookie常見的屬性

cookie的生命周期：

• 默認情況下的cookie是內存cookie，也稱之為會話cookie，也就是在瀏覽器關閉時會自動被刪除；
• 我們可以通過設置expires或者max-age來設置過期的時間；
  expires：設置的是Date.toUTCString()，設置格式是;expires=date-in-GMTString-format；
  max-age：設置過期的秒鐘，;max-age=max-age-in-seconds (例如一年為60*60*24*365)；

cookie的作用域：（允許cookie發送給哪些URL）

Domain：指定哪些主機可以接受cookie

• 如果不指定，那么默認是 origin，不包括子域名。
• 如果指定Domain，則包含子域名。例如，如果設置 Domain=mozilla.org，則 Cookie 也包含在子域名中（如developer.mozilla.org）。

Path：指定主機下哪些路徑可以接受cookie
例如，設置 Path=/docs，則以下地址都會匹配：
/docs
/docs/Web/
/docs/Web/HTTP

八、客戶端設置cookie

js直接設置和獲取cookie：

這個cookie會在會話關閉時被刪除掉：

設置cookie，同時設置過期時間（默認單位是秒鐘）：

九、服務器設置cookie

Koa中默認支持直接操作cookie

• /test請求中設置cookie
• /demo請求中獲取cookie

十、Session是基于cookie實現機制

在koa中，我們可以借助于 koa-session 來實現session認證：

設置secrets加密字符串，用于加密數據：

十一、認識token

cookie和session的方式有很多的缺點：

• Cookie會被附加在每個HTTP請求中，所以無形中增加了流量（事實上某些請求是不需要的）；
• Cookie是明文傳遞的，所以存在安全性的問題；
• Cookie的大小限制是4KB，對于復雜的需求來說是不夠的；
• 對于瀏覽器外的其他客戶端（比如iOS、Android），必須手動的設置cookie和session；
• 對于分布式系統和服務器集群中如何可以保證其他系統也可以正確的解析session？

所以，在目前的前后端分離的開發過程中，使用token來進行身份驗證的是最多的情況：

• token可以翻譯為令牌；
• 也就是在驗證了用戶賬號和密碼正確的情況，給用戶頒發一個令牌；
• 這個令牌作為后續用戶訪問一些接口或者資源的憑證；
• 我們可以根據這個憑證來判斷用戶是否有權限來訪問；

所以token的使用應該分成兩個重要的步驟：

• 生成token：登錄的時候，頒發token；
• 驗證token：訪問某些資源或者接口時，驗證token；

十二、JWT實現Token機制

JWT生成的Token由三部分組成：

header

• alg：采用的加密算法，默認是 HMAC SHA256（HS256），采用同一個密鑰進行
  加密和解密；
• typ：JWT，固定值，通常都寫成JWT即可；
• 會通過base64Url算法進行編碼；

payload

• 攜帶的數據，比如我們可以將用戶的id和name放到payload中；
• 默認也會攜帶iat（issued at），令牌的簽發時間；
• 我們也可以設置過期時間：exp（expiration time）；
• 會通過base64Url算法進行編碼

signature

• 設置一個secretKey，通過將前兩個的結果合并后進行HMACSHA256的算法；
• HMACSHA256(base64Url(header)+.+base64Url(payload), secretKey);
• 但是如果secretKey暴露是一件非常危險的事情，因為之后就可以模擬頒發token，也可以解密token；

十三、Token的使用

當然，在真實開發中，我們可以直接使用一個庫來完成： jsonwebtoken；

十四、非對稱加密

前面我們說過，HS256加密算法一單密鑰暴露就是非常危險的事情：

• 比如在分布式系統中，每一個子系統都需要獲取到密鑰；
• 那么拿到這個密鑰后這個子系統既可以發布另外，也可以驗證令牌；
• 但是對于一些資源服務器來說，它們只需要有驗證令牌的能力就可以了；

這個時候我們可以使用非對稱加密，RS256：

• 私鑰（private key）：用于發布令牌；
• 公鑰（public key）：用于驗證令牌；

我們可以使用openssl來生成一對私鑰和公鑰：

• Mac直接使用terminal終端即可；
• Windows默認的cmd終端是不能直接使用的，建議直接使用git bash終端；
  
  

十五、使用公鑰和私鑰簽發和驗證簽名

注意：

const Koa = require('koa') const Router = require('koa-router') const jwt = require('jsonwebtoken') const fs = require('fs') const path = require('path')const app = new Koa() const testRouter = new Router()const PRIVATE_KEY = fs.readFileSync(path.join(__dirname, './keys/private.key')); const PUBLIC_KEY = fs.readFileSync(path.join(__dirname, './keys/public.key'));// 登錄接口 testRouter.post('/test', (ctx, next) => {const user = {id: 110, name: 'zep'}const token = jwt.sign(user, PRIVATE_KEY,{expiresIn: 60 * 60,algorithm: 'RS256'})ctx.body = token })// 驗證接口 testRouter.get('/demo', (ctx, next) => {const authorization = ctx.headers.authorizationconst token = authorization.replace('Bearer ', '')try {const result = jwt.verify(token, PUBLIC_KEY, {algorithm: ['RS256']})ctx.body = result} catch (err) {console.log(err.message)ctx.body = err.message} })app.use(testRouter.routes())app.listen(8001, (err) => {console.log('服務器啟動成功') })

十六、派發令牌和驗證令牌

postman中設置全局變量token:

十七、發布和查詢動態內容

創建新的表 moment

定義發布動態內容的接口

• 定義路由接口
• 驗證用戶登錄
• Controller和Service中處理內容
  
  
  

定義查詢單個內容的接口

• 根據momentId查詢接口內容；

SELECT m.id, m.content, m.createAt, m.updateAt as updateTime, JSON_OBJECT('id', u.id, 'name', u.name) as user FROM moment as m left join user as u on m.user_id = u.id where m.id = 1

定義查詢多條內容的接口

• 查詢所有moment接口內容（根據offset和limit決定查詢數量）

十八、修改和刪除動態內容

定義修改動態內容的接口

• 定義路由接口
• 驗證用戶登錄
• 驗證用戶的權限
• Controller和Service中的處理

定義刪除內容的接口

• 定義路由接口
• 驗證用戶登錄
• 驗證用戶權限
• Controller和Service的處理
  
  
  

十九、發表和修改評論內容

注意：
關系表的級聯更新： on update cascade
on delete cascade 是級聯刪除的意思
意思是 當你更新或刪除主鍵表時，那么外鍵表也會跟隨一起更新或刪除

創建新的表 comment
定義發布評論內容的接口

• 定義路由接口
• 驗證用戶登錄
• Controller和Service中處理內容
  
  
  
  

回復評論接口：

定義修改評論內容的接口

• 定義路由接口
• 驗證用戶登錄
• 驗證用戶的權限
• Controller和Service中的處理
  
  
  
  
  
  
  
  
  
  

二十、刪除和查詢評論內容

定義刪除評論內容的接口

• 定義路由接口
• 驗證用戶登錄
• 驗證用戶權限 p Controller和Service的處理

查詢動態的時候，同時顯示評論信息

• 查詢多個動態時，顯示評論的個數

• 查詢單個動態時，顯示評論的列表
  
  根據動態的id獲取評論詳情：
  
  
  
  

二十一、標簽接口開發

創建標簽的表

定義創建標簽接口

• 路由配置Router
• 驗證用戶登錄
• 創建標簽
  

創建標簽和動態關系表

定義給動態添加標簽的接口

• 給動態添加新的接口
  
  
  
  
  
  
  
  
  

查詢所有標簽列表：

查詢標簽接口

• 查詢動態列表，展示標簽數量
  
  
  

• 根據動態id，展示標簽列表
  

二十二、上傳頭像圖片

上傳頭像邏輯：

定義上傳圖像的接口

定義獲取圖像的接口

請求用戶信息時，獲取頭像

分析實現思路：

• 1.圖片（文件）上傳 /upload/avatar
  目的：服務器端可以保存一張圖片
• 2.提供一個接口，可以讓用戶獲取圖片
  /1/avatar -> 找到圖片\讀取圖片\content-type: image/jpeg\返回圖像的信息
• 3.將URL存儲到用戶信息中
  avatarURL: 頭像的地址
• 4.獲取信息時，獲取用戶的頭像
  

1. 定義上傳圖像的接口，將用戶上傳的圖片保存到服務器本地的uploads/avatar文件夾下，然后再把圖片的信息保存到數據庫中的avatar表中：

2. 定義獲取圖像的接口

3. 請求用戶信息時，獲取頭像

3.1 修改上傳頭像接口，不僅要把上傳的頭像信息保存到數據庫的avatar表中，還要將上傳的用戶頭像的avatarUrl保存到數據庫的用戶表中：

3.2 修改原來的動態查詢接口，增加avatarUrl字段：

二十三、上傳動態的配圖

上傳動態配圖

• 定義上傳動態配圖的接口
• 定義獲取動態配圖的接口
• 獲取動態時，獲取配圖信息

1. 定義上傳動態配圖的接口

2. 定義獲取動態配圖的接口

3. 獲取動態時，獲取配圖信息

根據momentId獲取動態的配圖：

附加：處理上傳的圖片，將圖片分成三種大小

JavaScript 編寫的圖像處理庫 Jimp：https://github.com/oliver-moran/jimp





https://github.com/oliver-moran/jimp/tree/master/packages/plugin-resize

然后修改獲取動態配圖的接口：

總結

以上是生活随笔為你收集整理的Koa框架——coderhub实战的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。