小闷家的价格比较可以，13 寸默认配置是 11330。
话说这个配置，低了点，16G 才好用

代码写得好，默认就很好用了。不需要额外设置

更正：
当第五个客户端登录时，服务端检测当前用户已有四个令牌了，拒绝登录。
当第五个客户端登录时，服务端检测当前用户已有四个口令了，拒绝登录。

令牌 -> 口令

我不确定 jwt 是否考虑了客户端拷贝 token 来实现更多客户端同时使用

在上面的身份鉴定的基础上，另外使用一次性口令。

登录或注册成功后，服务端签发身份令牌和生成并保存新口令，然后将身份令牌和口令同时返回客户端，客户端将身份令牌和口令保存。下一次请求时，客户端携带口令和身份令牌，服务端做两个验证，一是请求的口令是否与已存在的匹配，二是身份令牌是否有效。两者都有效才通过。都验证通过后，返回时，生成新的口令返回给客户端(不需要更新身份令牌)，服务端和客户端都需要更新保存新口令，下次请求同理。登出时删掉服务端对应的口令和客户端信息即可。

当第五个客户端登录时，服务端检测当前用户已有四个令牌了，拒绝登录。
当用户拷贝 http headers 试图突破限制时，第五个客户端接收了新的口令，原客户端的口令就会失效，所以还是四个客户端

可以使用随机数做口令，因为是一次性的，具有排他性，所以不需要考虑重放攻击。但是有可能和自己已存在的口令冲突，可以用时间戳+随机数做口令，不需要加密或签名

你要做的其实是 http 的身份鉴定和令牌有效期。

大致流程是在登录或注册成功后，服务端签发一个令牌返回给客户端，令牌常见存放在 cookie 中。客户端在下次请求时携带令牌，服务端验证令牌来判别此次请求的有效性，若令牌有效，说明此次请求的用户就是其声明的身份。反之不能证明身份的就不能通过。

其中的核心就是令牌，令牌中包含两部分信息，数据和签名，由服务端负责签发和验证。

举一个最小化的例子. ID 为 10000 的用户登录成功了，服务端对 ID 进行数字签名。服务端将 ID + 签名结果 拼接起来组成字符串令牌放到 cookie 中返回给客户端。客户端下次请求时将令牌带上，服务端校验令牌格式和数字签名的有效性。签名的目的是防止伪造和篡改，比如数据部分被改成 10001，这个在服务端就不能通过验证。目前比较推荐的签名算法是 ed25519。

如果你需要限制令牌的有效期，原理也是一样的，将用户 ID 和截止时间一起签名返回给客户端。下次验证是否已过截止时间就可以了。

为了美观和统一, 可以将数据部分 base64 编码后再和签名拼接，用 . 号分隔。

不嫌烦的话 jwt 可以做到这个事，虽然它定义的标准很糟糕。

若要考虑修改密码后吊销所有令牌，在设计上又稍微复杂一点。

将一次 request - response 当成一次 session 不可以解决吗？想不通为何一定要整个长 session

还有车位吗？

化工方式出油率高，机械压榨方式出油率很低

这种不把面试者当回事的公司，不爆名字留着过端午 ？

人家用云的招牌卖虚拟机的，什么 SDK 什么文档，就做做样子。你若想：我买的是虚拟机，一切就都合理了

@ruimz 看样子戳到你的痛处了

海军即将登陆。
1. 小程序又不是最占资源的，难道你其它应用不占资源吗？
2. 现在手机内存这么大，这么点内存不算啥？
3. 又没人让你用
4. 你的手机有问题
...

简单一句：微信🌶️🐔

有做成笔记带分类目录带计划吗 ？

完全可以做，不过插件可能达不到开箱即用