- 主题:多个标签页共享token的问题?
多个标签页需要共用token（通过sessionStorage 共享），以保持有效的授权
token是15分钟一更新， 比如A，B两个标签，A，B都有个可能更新token，
比如A更新token，在更新token期间，B使用旧token，结果导致错误
所以怎么处理，能让其中一个标签更新token期间，其他标签页如果使用token则等待，比如有什么锁，但是由于两个标签处于不同的**进程**，不能用先线程锁
请问有什么建议?
谢谢
--
FROM 211.103.207.*
我猜你的A B两个标签里的内容都会高频发出API请求，才会产生这种困惑。
换个角度考虑问题会很简单：假设token的有效期是15分钟，可以让A标签页在14分30秒的时候去请求更新token，那么在更新token的过程中，依然在有效期内，B标签依然可以使用；一旦更新完毕，B标签同时从session storage里就拿到的是最新的token。整个过程中几乎是不存在锁定期的。
而如果更新token这个动作本身时间就很久，还是从优化更新token着手吧。
【 在 cheaper2005 的大作中提到: 】
: 多个标签页需要共用token（通过sessionStorage 共享），以保持有效的授权
: token是15分钟一更新， 比如A，B两个标签，A，B都有个可能更新token，
: 比如A更新token，在更新token期间，B使用旧token，结果导致错误
: ....................
- 来自「最水木 for iPhone Xs Max」
※ 修改:·syssky 于 Jul 13 22:17:08 2020 修改本文·[FROM: 120.244.231.*]
※ 来源:·最水木 客户端·[FROM: 120.244.231.*]
修改:syssky FROM 120.244.231.*
FROM 120.244.231.*
为什么你会有这种要更新token的需求？一般来说都是刷新延长token的有效期，没有必要更换token本身，因为一旦需要更换token本身就会涉及到多个页面甚至同一个页面内多个并发请求的同步的问题
怕token泄密的话，请用https，不加密被监听，或者通过其他方式泄漏token的话，15分钟更新一次更本保证不了token的安全性
如果一定要修改token的话，建议每个页面一个独立的token，但是这样依然会出现同一个页面内不同的并发请求出问题的可能性，比如这个页面里一个请求正在更新token，同时另外一个数据请求就有可能出错，或者必须延迟等第一个请求结束再进行
【 在 cheaper2005 (cheaper and more powerful) 的大作中提到: 】
: 多个标签页需要共用token（通过sessionStorage 共享），以保持有效的授权
: token是15分钟一更新， 比如A，B两个标签，A，B都有个可能更新token，
: 比如A更新token，在更新token期间，B使用旧token，结果导致错误
: ...................
--
FROM 202.109.128.*
https已经在用了
才外还有单点登录的要求，一个终端只呢有一个有效token
token采用自校验的方式，处于安全，需要有有效期的设计。
我们在测试已经发现，存在并发时更新token导致某些标签页故障的bug
【 在 adamhj (淘气阿丹) 的大作中提到: 】
: 为什么你会有这种要更新token的需求？一般来说都是刷新延长token的有效期，没有必要更换token本身，因为一旦需要更换token本身就会涉及到多个页面甚至同一个页面内多个并发请求的同步的问题
: 怕token泄密的话，请用https，不加密被监听，或者通过其他方式泄漏token的话，15分钟更新一次更本保证不了token的安全性
: 如果一定要修改token的话，建议每个页面一个独立的token，但是这样依然会出现同一个页面内不同的并发请求出问题的可能性，比如这个页面里一个请求正在更新token，同时另外一个数据请求就有可能出错，或者必须延迟等第一个请求结束再进行
: ...................
--
FROM 211.103.207.*
你这个方案可行，在后台实现一段时间多的token共存，我们设置为3分钟，减少了大部分的bug在线，但是还是不能绝对避免
【 在 syssky (syssky) 的大作中提到: 】
: 我猜你的A B两个标签里的内容都会高频发出API请求，才会产生这种困惑。
: 换个角度考虑问题会很简单：假设token的有效期是15分钟，可以让A标签页在14分30秒的时候去请求更新token，那么在更新token的过程中，依然在有效期内，B标签依然可以使用；一旦更新完毕，B标签同时从session storage里就拿到的是最新的token。整个过程中几乎是不存在锁定
: 而如果更新token这个动作本身时间就很久，还是从优化更新token着手吧。
: ...................
--
FROM 211.103.207.*
【 在 cheaper2005 (cheaper and more powerful) 的大作中提到: 】
: https已经在用了
: 才外还有单点登录的要求，一个终端只呢有一个有效token
: token采用自校验的方式，处于安全，需要有有效期的设计。
所以说为什么你们会觉得需要这个有效期的设计，对安全有什么帮助？
是为了防止token泄漏？还是为了防止token被猜解？还是因为别的什么理由？
--
FROM 202.109.128.*
参考大厂类似的场景都有有效期的限制，特别是这种自校验的token，几乎都设置了有效期
【 在 adamhj (淘气阿丹) 的大作中提到: 】
: 所以说为什么你们会觉得需要这个有效期的设计，对安全有什么帮助？
: 是为了防止token泄漏？还是为了防止token被猜解？还是因为别的什么理由？
--
FROM 211.103.207.*
短成15分钟做啥呢？
长一点有啥不好？
【 在 cheaper2005 的大作中提到: 】
: 参考大厂类似的场景都有有效期的限制，特别是这种自校验的token，几乎都设置了有效期
:
--
FROM 120.85.149.*
长点照样有过期更新token的问题
【 在 alanju (alanju) 的大作中提到: 】
: 短成15分钟做啥呢？
: 长一点有啥不好？
--
FROM 211.103.207.*
token过期了
让用户自己刷新呗
你看京东也是要用户重新登录的
之前给个系统加手机端
是搞了手机端token和内部token
内部token后台帮忙刷新
手机端token有效期长，过期了让用户自己重新登录
【 在 cheaper2005 的大作中提到: 】
: 长点照样有过期更新token的问题
:
--
FROM 58.249.14.*