# hi-api

**Repository Path**: kellogg2025/hi-api

## Basic Information

- **Project Name**: hi-api
- **Description**: 【害】api接口项目，使用Node+Koa2搭建
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2022-03-11
- **Last Updated**: 2022-09-26

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# hi-api

#### 介绍
【害】api接口项目，使用`Node+Koa2`搭建

#### 依赖说明

``` 
koa         	 // 主要框架
nodemon      	 // 用于热更新
dotenv       	 // 方便读取配置文件.env
koa-router   	 // 路由处理
koa-body    	 // 数据解析
sequelize    	 // 基于 promise 的 Node.js ORM(对象关系映射)
sqlite       	 // 主数据库（由于服务器性能原因放弃mysql）
bcryptjs     	 // 加盐加密（bcrypt依赖过多，所以使用更轻量的bcryptjs）
jsonwebtoken 	 // 给用户颁发token记录登录信息
koa-static       // 静态资源中间件，用于直接访问静态资源。例如图片
```


#### 使用 JWT 的优势
``` 
   使用JWT保护应用安全，至少可以获得以下优势：
   
   更少的数据库连接：因其基于算法来实现身份认证，在使用JWT时查询数据的次数更少(更少的数据连接不等于不连接数据库)，降低服务器查询数据库的次数，可以获得更快的系统响应时间。
   
   构建更简单：如果应用程序本身是无状态的，那么选择 JWT 可以加快系统构建过程。
   
   跨服务调用：可以构建一个认证中心来处理用户身份认证和发放签名的工作，其他应用服务在后续的用户请求中不需要(理论上)在询问认证中心，可使用自有的公钥对用户签名进行验证。
   
   无状态：不需要向传统的Web应用那样将用户状态保存于Session中。
``` 
#### 使用 JWT 的劣势
``` 
   任何技术框架都有 自身的局限性，不可能一劳永逸，JWT 也不例外。它存在以下劣势：
   
   严重依赖于秘钥：JWT 的生成与解析过程都需要依赖于秘钥(Secret)，且都以硬编码的方式存在于系统中(也有放在外部配置文件中的)。如果秘钥不小心泄露，系统的安全性将受到威胁。
   
   JWT 的最大缺点是无法作废已颁布的令牌：由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
   
   服务端无法主动推送消息：服务端由于是无状态的，将无法使用像Session那样的方式推送消息到客户端，例如过期时间将至，服务端无法主动为用户续约，需要客户端向服务端发起续约请求。
   
   冗余的数据开销：一个 JWT 签名的大小要远比一个 Session ID 长很多，如果对有效载荷(payload)中的数据不做有效控制，其长度会成几何倍数增长，且在每一次请求时都需要负担额外的网络开销。如果放在 Local Storage，则可能受到 XSS 攻击。
``` 

#### 安装教程

```
npm install
```

#### 使用说明

```
npm run dev
```

#### 参与贡献

1.  Fork 本仓库
2.  新建 Feat_xxx 分支
3.  提交代码
4.  新建 Pull Request

6.  https://gitee.com/gitee-stars/)