说到这里，我就想起来一个比较经典的密码学问题。

安全的密码要求人在不同系统使用不同的密码，并且要有高复杂度，这本是好事，但由于系统太多，密码太复杂，没法记清楚，于是大多数用于选择将密码写在便利贴上，以方便登录时候能快速获取密码。然后便利贴被盗了。

@IvanLi127 是的，长期 token 一定更不安全，但是确实有使用场景，比如 git 上面我想要每次发版本时候自动获取项目的一些信息，就得调用 api ，如果只有短期 token ，用户很有可能会把账号密码直接存储下来自动获取 token ，这就不是我们想看到的结果了。

要相对安全点就是得用 api token ，可以申请一个范围很小的，比如只能读项目信息的 token ，相对来说，泄漏后造成的损失也就比较小了。方便和安全之中总要取得某些平衡。

@SSang 嗯，不如说，是用了 json 格式的 token ，实际上不用来做 JWT 的无状态校验。

@Chad0000

嗯，感觉纠结半天还是用回了 JWT 。

上次有个有个帖子有人说 JWT 存有状态就是 ** 我还给他点了个赞。（笑哭）

@Chad0000

我比较核心的使用场景是，用于 CI 中调用，或用于命令行脚本调用。这种场景，比如 CI 这种无交互的就不能用户登录，必须提前把 token 配进去，然后他的有效期一般都是以年为单位的，甚至有些低权限的是永久有效期。

这种场景感觉用 refresh token 就有点奇怪，一是因为我用命令行实际上不好存 access_token ，如果是 CI 里面，存缓存也有点奇怪。二是定时任务往往超过 access_token 的有效期，比如每个月只执行一次的任务，相当于每次我其实都是拿 refresh_token 去请求，和 access_token 就没关系了。

@3dwelcome

> 你是怕 token 时间太长泄露吗？我个人觉得问题不大，后台都是可以控制的。

不是，我是觉得 refresh_token + access_token 的使用场景，一般适用于相对短期的认证，比如比较主流的 oauth 、oidc 就是用户先通过用户密码登录，然后服务端返回 refresh_token 和 access_token ，当 access_token 过期时，拿 refresh_token 刷新。和 git 上面的 用户令牌 是由用户申请，之后直接拿 token 访问 api 不太相同。

> 类似 B 站的 cookie, 接近一年前的我都还在用，也没啥问题。

这种隐私性不高的页面一般确实长时间持有 token 也问题不大，但是比较敏感的，比如 阿里云的后台，AWS 的后台界面，这种，他们就不会长时间持有 token （没记错的话他们两个的有效期都是 18 小时）

@3dwelcome 那这种就是数据库存 token 的 hash 值了吗，比如像 gitlab 还有 personal_access_token 他可以创建好多个，那登录时候，如果有加随机盐，就得一个一个地取盐然后 hash 校验，这个索引效率就很低了。

@Chad0000 确实，OAuth 就是这么设计的，但实际上这个 RefreshToken 的有效期也不会很长，比如默认是 30 天，像 gitlab 、github 的 token 往往有 90 天，180 天，甚至是永久有效期。所以感觉实际设计时候不太能用这种方式。

然后其实我想讨论的就是这个 Refresh Token 要怎么存，要不要带用户信息，如果不带如何索引等。这个比较纠结，其实如果能想明白这个，我就不纠结用不用 Refresh Token 了

你先把 F J 和符号键装上就知道了吧

其实写死在环境变量也行，只要客户不知道怎么查环境变量，你就说，看文件里面没有，忽悠他就好了

而且我有个问题，楼上说的，解密密钥写代码，配置文件存密文，这不是一样没用吗
我好像不需要知道你怎么解密的，我只要知道密文然后传给你就好了
这不是和加盐，做 md5 、哈希什么的一样吗
可靠的加密应该只能是非对称加密吧，但这要求必须有权威认证机构

用环境变量传呗（用 export ），只有部署时候需要用到，启动时候读完就写进内存，然后环境变量就失效了，但要是挂了就还得再手动部署

记错了，oss 不是查 api ，是 ossutil 工具
给你找了，https://www.alibabacloud.com/help/zh/doc-detail/179388.htm#concept-1937458
所以其实你根本也不需要获取更新列表，直接调对象存储或网盘的 API 或接口就好了

顺便，网盘你去找他的 api 文档，现在比较主流的网盘基本都是支持增量的

rsync 本身就能支持增量，你要获取列表 tee 日志输出一下就好了

oss 也支持增量，参考一下 api 文档，就是一个 -u 参数的事情

这个还挺有趣的，git 其实就是文档仓库，存啥的都有，能火主要是因为宣传和作者的知名度吧。

我自己也喜欢用 github 存[食谱]( https://github.com/gitsang/kanban/projects/8)，不过我用的是看板，优点是很直观，缺点是不能接受贡献。

@buddyy 同意 Default is Best 。

然后说说为什么我希望给 C 盘大一点的空间。

1. 因为默认的就是最好的，他不会有转移成本，且开箱即用。

软件默认安装路径是 C 盘，那就放 C 盘，防止出现奇怪的问题。
win 默认的下载、图片、视频、音乐就是在 C 盘的 User 目录，那我就按照这个来分目录，可以直接使用上 win 系统的一些导航。

2. 同盘转移数据不用拷贝

3. 我有很多个盘，有放本机的大机械，有服务器上的网络硬盘，容量本身就很充足，一张实体硬盘做一件事。