V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
SkyLine7
V2EX  ›  Java

jwt 如何做在线踢人功能?

  •  
  •   SkyLine7 · 196 天前 · 8482 次点击
    这是一个创建于 196 天前的主题,其中的信息可能已经有所发展或是发生改变。

    不依赖第三方中间件(比如 redis )

    73 条回复    2023-10-12 17:31:07 +08:00
    bootvue
        1
    bootvue  
       196 天前
    必须依赖中心化的存储机制
    Pythoner666666
        2
    Pythoner666666  
       196 天前
    不配合第三方中间件做不到
    eastjoehan
        3
    eastjoehan  
       196 天前
    token 存在哪,那就在哪把 token 删掉
    codehz
        4
    codehz  
       196 天前
    还是需要一个地方存 revocation list ()
    相比于其他不透明 session 来说,revocation list 可以在后端用 bloom filter 做初筛(因为数量上 revoke 的肯定比较少,分发 bloom filter 的状态更便宜)
    wu00
        5
    wu00  
       196 天前   ❤️ 1
    玩骚的是吧,一次性 token ,从签发处来控制
    BBCCBB
        6
    BBCCBB  
       196 天前
    redis 记录这个 token 是否还能用. 白名单/黑名单都可以.
    nikenidage1
        7
    nikenidage1  
       196 天前
    这就是 jwt 的缺点之一啊
    thinkershare
        8
    thinkershare  
       196 天前   ❤️ 7
    Jwt 主要用来给资源授权的,生命周期很短。几乎不做权限回收控制。如果想要做有状态的会话凭证,又不想维护服务器状态,理论上就是矛盾的。
    luckyrayyy
        9
    luckyrayyy  
       196 天前
    无状态怎么记录状态?开着车怎么走路?
    cp19890714
        10
    cp19890714  
       196 天前
    办法:可以把 JWT 标签存储到服务端,用户访问时,校验当前状态是否有效,如果无效,就禁止访问。

    另外,需要踢人,就不应该用 JWT 。JWT 滥用,V 站都说了很多次了。
    sblid
        11
    sblid  
       196 天前   ❤️ 7
    既然需要状态就不要用 jwt ,否则自己重新实现了一个 session ,不是没事找事么。
    nothingistrue
        12
    nothingistrue  
       196 天前
    做不了。JWT 只是个 Token ,不要只用它来做会话跟踪。在线踢人属于会话跟踪,必须上服务器端会话管理。
    xiaogezz
        13
    xiaogezz  
       196 天前
    JWT 只做好认证的事情就好了,至于具体的访问权限,应该交由权限控制
    ns09005264
        14
    ns09005264  
       196 天前
    我有个想法,那就是做和 session 相反的事,即:把要踢的用户保存在内存里。
    具体是这样的:
    用户改了密码或者要踢某个用户下线,就把该用户的 ID 保存到内存里,因为要踢下线的人一般都是少数,费不了多少空间。
    当然要设置保存期限,和 JWT 的过期时间一样就行。
    比如用户改了密码,就把他的 ID 保存到内存里,当他依然用旧令牌访问时,后端从旧令牌中解析到他的 ID 并与内存中的列表比对,如果存在就令牌失效,需要登录,同时删除列表里的 ID 。
    如果他改了密码,但再也没有登录过刷新令牌,那么也无妨,因为内存中的列表过期也会清理的。
    简单来讲,因为 JWT 对后端服务是无状态的,但可以在后端增加“踢人列表”这一点点不怎么占用资源的状态。
    以上没有考虑分布式的情况,因为我没有分布式的经验。分布式的“登录与验证服务”应该也是单机的服务吧?
    Breacher
        15
    Breacher  
       196 天前 via iPhone
    一直都是只把 JWT 当作 token 用,然后使用数据库跟踪它的状态:已退出、已 revoke 、重置密码后让旧 token 失效。我只是需要 JWT 的一些特性,比如能够携带一些键值对、能够验证签名(签名验证不通过直接返回未登录,避免将压力给到存储层)。
    streamrx
        16
    streamrx  
       196 天前 via iPhone
    jwt 就是无状态
    NX2023
        17
    NX2023  
       196 天前
    JWT 是没法撤销的,如果不依赖缓存,只能使用长短 JWT
    在线踢人是不行的,只能说把短 JWT 设置的短一些,比如 1min 或者 30s

    https://nickxu.me/post/jwt-refresh-token
    fordoo
        18
    fordoo  
       196 天前
    提供一个思路,jwt payload 中保存一个用户的关键信息的签名,每次验证 jwt 的时候,同时去验证 db 里面用户的这个签名(可以加缓存减少 db 压力),需要踢 jwt 时,只需要让用户的关键信息变化就行
    hyperbin
        19
    hyperbin  
       196 天前 via Android
    在用户表维护个 tokenStartTime ,鉴权时判断 jwt 的 iat 是否大于 tokenStartTime ,只要更新 tokenStartTime 到当前时间就可以拉黑以前签发的所有 token
    NX2023
        20
    NX2023  
       196 天前
    @sblid 老哥,是这样的
    XCFOX
        21
    XCFOX  
       196 天前
    @fordoo #18

    jwt 的出现就是为了无状态、不访问 db 。既然业务需求不能无状态,不如直接把 jwt 的签名、验证这一套省略了。用最简单的最直观的 session 模式。
    chendy
        22
    chendy  
       196 天前
    直接不用 jwt ,jwt 本身就适合在服务间传递,减少用户中心这类服务的压力
    浏览器,客户端认证用普通的 token ( cookie 里的 sessionid 也算 token )
    PVXLL
        23
    PVXLL  
       196 天前 via iPhone   ❤️ 1
    打电话给客户端使用者让他自己销毁
    zsdroid
        24
    zsdroid  
       196 天前
    @ns09005264 负载均衡了解下
    aladdinding
        25
    aladdinding  
       196 天前
    加一个黑名单的中间价
    mdn
        26
    mdn  
       196 天前
    @fordoo 这样用户的其他端都会被踢掉,所有 token 失效,而不是单个
    hongfs
        27
    hongfs  
       196 天前
    十月份才过去几天,第几个 JWT 帖子了。。。
    manasheep
        28
    manasheep  
       196 天前
    token 时限设短,只有高危操作去验证用户账户状态,别的默认提供服务就可以了
    hez2010
        29
    hez2010  
       196 天前
    其实最好的方法是不用 jwt
    lidashuang
        30
    lidashuang  
       196 天前
    黑名单, 数据库存储黑名单
    fire2y
        31
    fire2y  
       196 天前
    换个思路 把权限给禁掉就好了
    cslive
        32
    cslive  
       196 天前
    数据库总用的吧,数据库中拉黑
    leegoo
        33
    leegoo  
       196 天前
    因为 jwt 就是一个 token ,token 反解析出来可以获取到用户信息

    数据结构类似于 : key:token ,value:info

    我提供的思路是

    在获取到 token 后,再使用另外一个 map 存储,这个 map 的 key 是 用户账号(保证用户的唯一性即可),value 对应这个 token
    这样就能够保证 ,知道哪些用户登录了,如果要踢人, 只需要根据 新定义的那个 map 找到 对应的 token (可能有多个), 从 map 或者 redis 清理掉即可
    chenduke
        34
    chenduke  
       196 天前
    1.缩小 token 的过期时间,10 分钟,5 分钟。3 分钟, 看具体的场景的需要。
    2.token 中包含生成的时间, 刷新 token 的时候与数据库中的最新刷新时间做比较,如果小于则返回需要重新登录。
    3. 上面二条并不能保证及时性, 有条件加个消息推送的机制,这样就很及时了。
    version
        35
    version  
       196 天前
    @hongfs 生活压力大..最近太多人转行程序员了..只能找一些 10 年未维护的老旧项目接手(面试的人也不懂技术)...产品就会把遗留问题丢给新手..
    fengpan567
        36
    fengpan567  
       196 天前
    把用户禁了
    fregie
        37
    fregie  
       196 天前
    这个需求跟 jwt 存在的意义互斥
    swulling
        38
    swulling  
       196 天前 via iPhone
    一个令人费解的设计就是明明服务请求都落中心数据库,别人建议用 redis 做个 session ,却说 jwt 适合分布式,没有单点。很奇怪。
    sunmlight
        39
    sunmlight  
       196 天前
    判断 用户+签发时间, 早于“踢”的失效?
    Tiny
        40
    Tiny  
       196 天前
    把 signing key 删了,token 失效
    fanchenio
        41
    fanchenio  
       196 天前   ❤️ 4
    你是否在搜索 session ?
    zhiyu1998
        42
    zhiyu1998  
       196 天前
    satoken
    pannanxu
        43
    pannanxu  
       196 天前
    可以实现一个伪需求:使用 socket 推送,前端收到消息后执行踢出逻辑。这样需求可以实现,但如果手动保留 token 还是可以登录。
    summerLast
        44
    summerLast  
       196 天前
    后台部署一个用户请求 401 (代价是所有用户的请求的 token 都做了验证)
    前台 401 清除 token
    fuchish112
        45
    fuchish112  
       196 天前
    不要用 jwt
    bill110100
        46
    bill110100  
       196 天前
    @ns09005264 不管是记录白名单还是黑名单,都需要一个记录的地方。对于分布式系统,还是需要每次使用前去记录的地方查询对比,和 session 方案没本质区别。
    IvanLi127
        47
    IvanLi127  
       196 天前
    等过期就行了,access token 最多也就活几分钟。不想等就别作死用 jwt 。或者 jwt payload 里加个 version ,给所有人签发下一 version 的 token ,服务端直接把不是最新 version 的 token 拒绝掉。
    wunonglin
        48
    wunonglin  
       196 天前   ❤️ 1
    典型的 JWT 滥用例子
    Dlin
        49
    Dlin  
       196 天前
    简单,先这样,再这样,然后那样
    GTim
        50
    GTim  
       196 天前
    楼上都没把数据说明白。JWT 是可以先获取到用户数据,然后从数据库里抽出用户数据再验证的,所以,最简单的方案,就是生成的时候加一个用户的 salt 进去,如果要踢出用户,只要改变这个用户的 salt 即可
    matrix1010
        51
    matrix1010  
       196 天前
    假设踢人是低频操作。 有数据库,签发 token 可控的情况下感觉可以这样: 把用户分为 n 组, 每组存个 version 到数据库里,签发 jwt 的时候把用户组的 version 也带上。踢用户时用户组对应的 version+1 。服务器每分钟同步整个用户组/version 表到内存(或者用 mq 实时性更高),解析 jwt 时对比内存里的 version 和 token 里的 version ,不匹配就走数据库查询用户有没有被踢。比如 1000 万用户分 1000 组,最坏情况就是这一组的 10000 个用户同时请求
    xuanbg
        52
    xuanbg  
       196 天前
    JWT 做不到有状态。所以,正确的做法是放弃 JWT ,自己实现一个有状态的 token ,非常简单。
    iwdmb
        53
    iwdmb  
       196 天前
    配合数据库
    gitrebase
        54
    gitrebase  
       196 天前
    op 这个需求有点矛盾,主要在与“在线踢人”是一个 stateful 的操作,而 JWT 最大的卖点就是 stateless ;可以考虑放弃 jwt 使用 session ;如果真要做的话就只能用一些存储中间件吧,想不到别的比较好的方案了
    byaiu
        55
    byaiu  
       195 天前
    建议看这个帖子

    https://v2ex.com/t/979326
    kwanzaa
        56
    kwanzaa  
       195 天前
    灰名单,查一下又不会死。
    ionfev
        57
    ionfev  
       195 天前
    JWT 是个字符串,是服务端使用密钥单向哈希计算出来的。按理说前端用后端给的 Token 字符串请求,服务端只验证,不保存状态,适合多个后端的分布式。但是呢,后端从来不信任前端(虽然说 Token 是后端生成的,所有的接口后端都要验证判断),所有一般还是后端使用 Redis 保存 Token 的有效期,所以对于踢人功能来说,删除后端 Redis 里的 Token 就行。
    expy
        58
    expy  
       195 天前   ❤️ 4
    服务端加上状态管理,然后就成了自己发明的半吊子 session 。
    justfindu
        59
    justfindu  
       195 天前
    每个用户本地文件系统存一个私钥, 踢人就删私钥, 无法解码就失效. 下次登录创建新私钥保存. 私钥名可以使用 userId_hash(token), 删除时候查找 userId_* , 你看是不是可行.
    jonsmith
        60
    jonsmith  
       195 天前
    Jwt 有效期尽量短一点,比如 30 分钟、1 小时,使用 refresh_token 刷新 Jwt token 时,再处理踢人逻辑。
    本质上,Jwt 授权签发后不能直接取消了,只能等过期重新签发。
    8355
        61
    8355  
       195 天前
    你们的 jwt 不校验的吗????
    震惊了。。。
    bk201
        62
    bk201  
       195 天前
    定时换密钥,但是会把人全踢了。
    nobject
        63
    nobject  
       195 天前
    个人觉得加个黑名单就简单,要踢人,或者后台删除一个用户,用户修改重置密码等,都可以把这个用户加入到黑名单中。依靠 jwt 本身的功能,只能有效期设置短点吧
    neptuno
        64
    neptuno  
       195 天前
    加个 jwt 黑名单
    Torpedo
        65
    Torpedo  
       195 天前
    核心就是有没有查库呗。把你的 jwt 校验增加查库的这一步应该就可以了
    tairan2006
        66
    tairan2006  
       195 天前
    我工作这么多年就没用过 jwt…
    pengxiaoyu
        67
    pengxiaoyu  
       195 天前
    我的理解是 jwt 解析->userid+roleid 等信息,那这个用户是否是黑名单用户,是由用户服务告诉我的。拦截器里查询用户服务告诉我是否要把他踢掉。而用户服务是否去查表还是查 Redis ,和网关无关,网关只做了从 jwt 解析这一步。
    mxT52CRuqR6o5
        68
    mxT52CRuqR6o5  
       195 天前   ❤️ 2
    恭喜你,用一种很别扭的方式重新实现了 session
    coala
        69
    coala  
       195 天前
    退而求其次,

    当前时间之前的 这个用户的签发 jwt 全部拉黑, gateway 加个逻辑判断就好了吧 。

    直接把这个用户所有的 token 的全干掉。
    BeautifulSoap
        70
    BeautifulSoap  
       195 天前 via Android   ❤️ 1
    jwt 无状态,本质和互联网初期时,网站在 cookie 里塞用户 id 服务器靠 cookie 里记录的用户 id 来确认你是哪个用户没区别。只不过 jwt 更现代而且往往有效期非常短
    想要在服务器端实现 jwt 无效化,最后搞到最后你会发现这就是 session
    SuperXRay
        71
    SuperXRay  
       195 天前
    不摄入食物的话怎么吃饱(不依赖注射营养物质)
    lmq2582609
        72
    lmq2582609  
       195 天前
    jwt 就是个字符串,不依赖 redis ,那只能用程序的内存来代替 redis 了,需要持久化的话得自己实现。
    shea
        73
    shea  
       195 天前
    可以做个拉黑功能, 在验证 jwt 前面加个中间件验证如果在 redis 里面存在的 token 就直接返回 401 就可以了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1135 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 280ms · UTC 22:59 · PVG 06:59 · LAX 15:59 · JFK 18:59
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.