密码相关

⚠️：如果需要输出日志，禁止输出任何用户输入的密码字段
⚠️：创建的密码限定长度为 8-21 个字符

为了保证安全（阻止彩虹表暴力猜解密码），我们这里使用 SHA + 32 位随机 salt 保证即使管理员也无法反向猜解出密码

1. 为什么不用 bcrypt ？

bcrypt 相对 SHA 更麻烦一点，性能更差极端情况下（参数设置不合理）加密时间可能长达 80ms以上，node 本身对于这种 cpu 密集的运算能力就十分不友好（node v8 引擎无法在这里识别并在 JIT 优化，所以相比较 java/go 可以慢一个数量级）但是更安全，或许目前SHA已经足够安全？

2. 为什么不添加额外的 configSalt
   密码加 salt后 长度已经到达最少 40 位绝大多数的彩虹表并不会包含如此数量的密码

3. randomString 是否足够随机以保证安全？

randomString 的随机程度并不足够，因为依靠 math.random 这个函数本身随机性存在问题

而 crypto.getRandomBytes 同样有问题，他在高位数部分存在显著的偏移

考虑是否使用 SHA 做 CSPRNG 来创建一个 密码学安全的散列 salt ？

admin 操作日志相关

admin 操作是否需要使用 IP + 操作者 + 操作时间记录每一次操作？

用户暴力猜解密码

因为没有设置上线，所以目前是可以暴力猜解密码的

根据给定餐次范围，给出每个餐次中不同wework_corpid的人数

统计选择餐次范围内的所有已点记录中每种餐品的总数

数据库

mongo

餐次 Dining

1. id
2. 点餐开始时间 order_start
3. 点餐截止时间 order_end
4. 取餐开始时间 pick_start
5. 取餐截止时间 pick_end
6. 统计类型（人数、餐品）stat_type
7. 菜单 array menu

用户

1. id
2. 邮箱 email
3. 微信 uid wework_userid
4. 密码 password
5. 微信企业id （xd，xdg，tap）wechat_corpid
6. 用户名 username
7. 头像 avatar
8. 权限 0 只读 1 admin 权限 2 role
9. 部门 department

餐品 dish

（自助可能需要单独解析）

1. id
2. 名称 title
3. desc
4. 供应商 supplier

餐次-用户 order

1. id
2. uid
3. 餐次 id dining_id
4. 菜单编号 menu_id

token 表

1. token
2. 餐次用户id

api

订餐app

1. 获取当前未点餐列表 （订餐页面） GET /dining/list
2. 当前可取菜品（二维码页面）GET /dish
3. 未取餐品列表（首页使用）GET /orders
4. 点踩（首页使用）
5. 添加点餐记录接口（餐次 ids）POST /order

用户相关

1. 邮箱登陆（） POST /user/login
2. 重设密码 POST /user/reset_pwd
3. 微信登陆
4. 注销 GET /user/logout
5. 微信回调 GET /user/wework

pos

1. token 获取点餐记录 GET /token/:id
2. （当前渠道的菜品）

admin

1. csv 导入 POST /admin/user/list
   邮箱 密码 -> 下载 姓名 部门 所属企业
2. 获取餐品列表 GET /admin/dish/list
3. 添加餐品接口 POST /admin/dish
4. 获取指定时间区间的餐次列表 GET /admin/dining/:startTime/:endTime
5. 增加餐次 POST /admin/dining
6. 更新餐次 PUT /admin/dining/:id
7. 按id列表删除餐次（id） DELETE /admin/dining
8. 查询用户列表（名字）（前端py）GET /admin/user/list
9. 查询用户指定时间内的点餐记录 GET /admin/order/:startTime/:endTime
10. 为指定用户添加自助餐（待定）
11. 修改餐品接口 PUT /admin/dish/:id