@passerbytiny
请教一下, 在令牌里放授权会有什么问题? 之前某个系统的设计中我选择直接将 authority 存储到 jwt payload 增大网关层吞吐量

@blue0125
假如是可信的 client, 可以随着 acess token (jwt) 一起下发一个 refresh token
假如是不可信的 client, jwt 过期后(假如 payload 里设置了过期时间的话) 由 client 自己来做重新登录

@yamedie
其实 #2 说的是一个宽泛的 token 比喻，所有的 token 都可以为获得某种权限的钥匙

但太泛化就会失去细节，jwt 更适合比喻为一纸身份证明，我在上面写上你是叫张三，你允许使用健身房和游泳池（这些叫 payload ），然后啪敲一个大公章（签名）盖住这些字

到时候无论谁拿着这张证明（ jwt ）过来，我都认为他是张三并且可使用健身房游泳池。假如这个人心眼坏，把张三加一竖改成了“张王”，那这一竖就会涂在公章上破坏了签名，这纸证明就无效了

额，忍不住说一句，页面里第一句话就是 inspired by xxx
对我这类之前没见过类似的项目的来说，很有新意

@tabris17
“只有一次性”有点绝对了，jwt 只是一个简单的标准，不是一个完整的方案，只要能正确理解并应用，放到 app 端身份认证或者 oauth 授权（可持续使用）体系里都可以工作的很好。其实我想讲的还是根据具体场景去权衡，尽量避免 pre-judge

很有意思，记住这家公司了

@tabris17 你说得没错，但有两点可供权衡：
1: jwt 的 payload 大部分不需要存储在 redis 里，因为可以用签名来验证，真正需要的只有一个 uuid ；而 session 共享要全都存储。存储成本小
2: jwt 只需要判断一 exist，session 共享需要 get。带宽压力小
当然这里不是说 session 共享不行，jwt 也有很多问题，比如更新 payload 字段需要重新签发，浏览器不会自动发送 Authorization header
另外，我认为不存在绝对的不可接受（也不存在完美的架构），存在的只有针对自身场景的合理权衡，有时候需要两害相权取其轻

@lsongiu
jwt 对 redis 是弱依赖，redis 挂掉只是被踢出的 token 可以正常使用，但不会影响正常的 token。
sessiom 共享对 redis 是强依赖，redis 挂了用户就无法鉴权

@547674115 我居然认真回答了 orz

@ns2250225 L2 模式的话任意挑一个内网的 ip 段就可以

Adidas 黑色, 很阳刚, 气味有点像阿玛尼寄情

应用层双写
订阅 binlog 同步到总库, 用 canal 即可

@rizon 是的

钓鱼?

楼主没看仔细啊, JWT 除了前两段 header, payload 之外, 还有第三段: 签名
服务端签发 JWT 时, 会用自己的密钥(对称 /非对称皆可)生成一个签名, 收到 token 时只需要验签通过即认为合法, 而验签是一个无状态的过程.

平衡树的最差查找时间是有保证的, 一定是 O(LogN)
跳表每层的的链表是随机生成的, 最差查找时间不稳定, 只能说平均是 O(LogN), 但最差是可以 O(N) 的
但跳表插入更快且对并发更友好, 平衡树需要旋转, overhead 比较大

@yishenggudou
当然不是..我没有参与编码

我司(非 BAT, TMD) 自研了一个对标阿里云 DMS 的 MySQL web-ui, 还在上面做了权限和安全

一开始我是反对这个项目的, 认为要做到像 navicat 一样功能全面太难了, 但没想到主程太牛逼了(我见过的最牛逼开发之一), 现在用起来简直比 DMS 还好用的多, 当然比起 navicat 还差一点, 但是中心化的权限与安全管理绝对是 killer feature

今年下半年, 该项目(可能)即将开源, 主程将继续扮演...算了直接两开花吧

@lhx2008
等于说要找出 x 的插入位置保持数组有序对吧? 这个需要在最后判断一次 vec[base] 是否小于 x

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a6854ce2b7b9e5305628dd6af561f600