V2EX › seth19960929 的所有回复 › 第 10 页 / 共 18 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 2 3 4 5 6 7 8 9 10 11 ... 18

❮

❯

2023-06-20 14:09:48 +08:00

回复了 seth19960929 创建的主题 › 问与答 › 每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

@daimubai 1000w 用户都请求有没有 1000w 次, 什么怎么得来的.
@chendy 就网上的帖子来看, JWT 很多时候还是给客户端用的, 而不是你说的内部服务

2023-06-20 09:45:56 +08:00

回复了 seth19960929 创建的主题 › 问与答 › 每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

@QlanQ 对, json web token 从名字看出来它也是一种 token

2023-06-20 08:57:09 +08:00

回复了 seth19960929 创建的主题 › 问与答 › 每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

@daimubai 查一次和一万次能一样吗？这样子说的话，干嘛架构这么多，干嘛用这么多缓存，直接查数据库了
@GeruzoniAnsasu 一直强调更多的怎么去解决 jwt 的问题，我后面说的这么多黑名单，刷新的机智话说都无视了吗
@akira 这是一个讨论贴，可以直接 block

2023-06-19 18:07:45 +08:00

回复了 seth19960929 创建的主题 › 问与答 › 每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

@hongfs 如果 token 有效期一个月, 1000w 肯定有的. 如果是抖音那种日活亿级别的, 那得多少内存存 token
@QlanQ 普通的 token 无任何有效信息, 只是一个唯一值, JWT 的话可以通过秘钥从 token 里解析出 uid 之类的, 这样子有些场景只有 uid 就不用查数据库.

2023-06-19 17:21:05 +08:00

回复了 seth19960929 创建的主题 › 问与答 › 每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

@QlanQ JWT 只是一个标准, 也是 token 的一种. JWT 黑名单用 redis 存的做法, 大家就会觉得为什么不直接把 token 直接存 redis 里.
@mmuggle 1

2023-06-19 17:18:08 +08:00

回复了 seth19960929 创建的主题 › 问与答 › 每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

@mxT52CRuqR6o5 你这个话说的, 如果是和钱相关, 那和 JWT 有什么关系, 这时候不应该发短信, 人脸识别一堆校验, 这时候全面风控早就拦截好了, 你用 JWT 做这个事不合适.

2023-06-19 17:16:07 +08:00

回复了 seth19960929 创建的主题 › 问与答 › 每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

@nothingistrue 说的在理

@ellermister 黑名单下线这个问题, 其实是一个取舍问题, 就是如果不能接受刷新 token 这段等待时间的话, 没什么好说的了, 就是每一次查询都走黑名单查询(其实很多系统第一次打开 app 或者重新登录才去校验), JWT 确实能省很多内存
@QlanQ 嗯嗯, token 也是一种方式, 就是随机字符串存到 redis 映射出 uid, 现在说这种存 redis 和 jwt 哪种更好.
@mxT52CRuqR6o5

2023-06-19 14:08:20 +08:00

回复了 seth19960929 创建的主题 › 问与答 › 每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

@8355 这个是,敏感操作已经和是 token 还是 jwt 没关系
@wunonglin 你说得对
@Masoud2023 sessionid 存取 1000w 数据, 没有哪家的黑名单有 1000w 吧? 并且我可以在刷新 token 的时候再查 redis, 而不是每次请求.

2023-06-19 14:05:57 +08:00

回复了 seth19960929 创建的主题 › 问与答 › 每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

@LeegoYih
只要循环结束, 我一样能破解呀.

for ($i = 1; $i < pow(32, 16); $i++) {
$key = genKey($i);
$result = openssl_decrypt(hex2bin('1fbf2605f954fad3ba18115000735aee'), 'aes-128-cbc', $key, 1, '0000000000000000');
}

2023-06-19 13:39:22 +08:00

回复了 seth19960929 创建的主题 › 问与答 › 每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

@ellermister 嗯嗯, 这是一个讨论帖子.
两种方案:
1. 只在刷新 token 的时候才查询是否在黑名单, 请求可以降低非常多, 有个问题就是会有延迟, 比如 5 分钟刷新一次 token, 那么就会加入后有 5 分钟延迟. 如果是部分场景完全可以用这种(只要 app 左右逻辑处理, 能及时失效, 如果有人窃取了 token, 那么它也只能使用 5 分钟, 到期了刷新就会得知被加入黑名单)
2. 大小还是差别很多的. 往 redis 里存 32 位字符串 key 1000w 个看看. 我等会给一个答案

2023-06-19 13:33:57 +08:00

回复了 seth19960929 创建的主题 › 问与答 › 每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

@LeegoYih 我看了两眼你这个代码, 上来来个碰撞代码就说不安全, 能拿出具体的文献出来吗.
按你这样子说, 世界上没有安全的加密, 我只要写一个碰撞代码, 它们安全只是我现在没有碰撞到, 不代表我做不到.

2023-06-19 13:26:01 +08:00

回复了 seth19960929 创建的主题 › 问与答 › 每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

@CodeCodeStudy 话说不看场景直接就存?
@emric 原理方案差不多的, 总是有些人在说为什么不存 redis 呢. 所以要讲这个东西.

2023-06-19 13:24:49 +08:00

回复了 seth19960929 创建的主题 › 问与答 › 每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

@LeegoYih 我就问一下, 你使用 token 权限更新了怎么办? 这个和 jwt 没关系. 你权限更新其它方式该怎么做就怎么做. 不是我小看, 而是如果还不消耗存储, 不消耗 io 的方式为什么不讨论呢?

@oldshensheep token 的方式, 按用户级别来说, 每次请求来都查 redis, 并且 jwt 包含千万级别的用户数据, 而刷新的时候查询, 减少了 90% 的请求, 并且 redis 的存储只用非常少
@giter 没错了, 那肯定都要存客户端的, 和我说的没区别
@nomagick 你在哪看的定义? 你说的是 oauth2 吧
@ztxcccc 举个栗子
@amlee 又来一个不看解决方案, 上来就说不查库的

2023-06-19 12:16:45 +08:00

回复了 seth19960929 创建的主题 › 问与答 › 每月一争, 为什么 JWT 这么多诟病, 什么下线设备登录 JWT 不是很容易解决吗?

还有 access_token 一个就够了, 为什么还要有 refresh_token, 除了官方说的安全之外, 就是可以作为两个时间点去使用.
access_token 每次都要校验, 可以简单的校验, refresh_token 使用的频次比较少, 这时候可以做更完整的校验.

2023-06-07 10:24:06 +08:00

回复了 chaleaochexist 创建的主题 › 程序员 › 脑补了一个微服务场景, 请问解决方案是什么?

@realpg 很多银行就是转账直接跳到某个等待页面, 快的话马上显示成功, 慢的等 10s.
所以转账提交成功, 和转账成功分两步

2023-06-07 10:11:55 +08:00

回复了 ben548 创建的主题 › Redis › 一个 abtest 实验中 redis 设计的思考

@ben548 按 userid 尾号切分

2023-06-05 18:27:27 +08:00

回复了 ben548 创建的主题 › Redis › 一个 abtest 实验中 redis 设计的思考

上策: 让数据部分自己判断是否同步过
中策: 别存分组, 实时计算, 用个 bitmap 来记录是否同步过
下策: 代码能跑. 百万级你怕什么. 千万级的 hash 都见过