7
关于token.secret.key漏洞问题的修复，如果直接修改正在运行的nacos集群的token.secret.key的默认值以后，对于正在使用nacos的微服务已经申请的accessToken会有什么影响呢，微服务引入的nacos-client包会自动获取新的accessToken吗？
Q
[alibaba/nacos]token.secret.key漏洞修复问题
A
回答
7
同问，token.secret.key配置项更改了之后需要重启服务端吗？另外如何验证配置是否生效呢，看网上很多帖子是说更改了之后没有生效的。
2
需要重启
5
同问，token.secret.key配置项更改了之后需要重启服务端吗？另外如何验证配置是否生效呢，看网上很多帖子是说更改了之后没有生效的。
拿一个旧版本的token，请求一下就知道是否生效了。
9
对于正在使用nacos的微服务已经申请的accessToken会有什么影响呢，微服务引入的nacos-client包会自动获取新的accessToken吗？
client会异步定时调用login接口获取新accessToken。
4
nacos的微服务已经申请的accessToken会有什么影响呢，微服务引入的nacos-client包会自动获取新的accessToken吗
目前好像客户端会等到旧的token到达过期时间后，才会去获取新的token， 这期间应该会影响，目前好像只能重启客户端程序执行重新登陆。 我研究下有没有办法能处理一下， 后续更新一下文档。
5
对于正在使用nacos的微服务已经申请的accessToken会有什么影响呢，微服务引入的nacos-client包会自动获取新的accessToken吗？
client会异步定时调用login接口获取新accessToken。
所以如果正在运行的Nacos进行更换token并重启以后，nacos-client通过旧的accessToken调用Nacos一定会失败，并且不会立即获取新的accessToken，
nacos的微服务已经申请的accessToken会有什么影响呢，微服务引入的nacos-client包会自动获取新的accessToken吗
目前好像客户端会等到旧的token到达过期时间后，才会去获取新的token， 这期间应该会影响，目前好像只能重启客户端程序执行重新登陆。 我研究下有没有办法能处理一下， 后续更新一下文档。
好的，那这个方案感觉有点不太完美，目前已经有很多微服务正在使用，如果直接修改nacos配置并重启，短时间内几乎会影响所有的微服务，要重启所有微服务的话公司业务层面肯定是不允许的，工作量巨大，影响范围也特别广
3
目前想到的方式： 先修改ttl， 运行一段时间让客户端先快速过期旧token， 然后再修改新token，缩短客户端因token变更导致的请求失败时间。
3
https://nacos.io/zh-cn/blog/announcement-token-secret-key.html
先更新了一个方法，减少了失败的时间。
9
https://nacos.io/zh-cn/blog/announcement-token-secret-key.html
先更新了一个方法，减少了失败的时间。
这个方法确实能够一定程度减少影响微服务的时间窗口，但没有完全避免影响到微服务。不过这也是现有情况下的最优方案了。
0
https://nacos.io/zh-cn/blog/announcement-token-secret-key.html 先更新了一个方法，减少了失败的时间。
这个方法确实能够一定程度减少影响微服务的时间窗口，但没有完全避免影响到微服务。不过这也是现有情况下的最优方案了。
如果需要完全无损的话， 需要承受一段时间的关闭鉴权，要评估一下风险。
设置ttl=5s 重启集群 运行一段时间，等待客户端获取新的ttl时间 设置新token.secret.key , 并且关闭鉴权，重启集群。（这样客户端会获取到新的token，且请求不会被拒绝，但是集群也没有鉴权能力了） 集群平稳后再开启鉴权。这种基本不会有中断， 但是在变更token.secret.key，重启集群期间没有鉴权，要评估好影响，看是否能接受。
9
https://nacos.io/zh-cn/blog/announcement-token-secret-key.html 先更新了一个方法，减少了失败的时间。
这个方法确实能够一定程度减少影响微服务的时间窗口，但没有完全避免影响到微服务。不过这也是现有情况下的最优方案了。
如果需要完全无损的话， 需要承受一段时间的关闭鉴权，要评估一下风险。
设置ttl=5s 重启集群 运行一段时间，等待客户端获取新的ttl时间 设置新token.secret.key , 并且关闭鉴权，重启集群。（这样客户端会获取到新的token，且请求不会被拒绝，但是集群也没有鉴权能力了） 集群平稳后再开启鉴权。这种基本不会有中断， 但是在变更token.secret.key，重启集群期间没有鉴权，要评估好影响，看是否能接受。
好的。
5
https://nacos.io/zh-cn/blog/announcement-token-secret-key.html 先更新了一个方法，减少了失败的时间。
这个方法确实能够一定程度减少影响微服务的时间窗口，但没有完全避免影响到微服务。不过这也是现有情况下的最优方案了。
如果需要完全无损的话， 需要承受一段时间的关闭鉴权，要评估一下风险。
设置ttl=5s 重启集群 运行一段时间，等待客户端获取新的ttl时间 设置新token.secret.key , 并且关闭鉴权，重启集群。（这样客户端会获取到新的token，且请求不会被拒绝，但是集群也没有鉴权能力了） 集群平稳后再开启鉴权。这种基本不会有中断， 但是在变更token.secret.key，重启集群期间没有鉴权，要评估好影响，看是否能接受。
好的。
您好，你们这样上线了吗？有没有问题啊？能做到真正无损吗？短时间的不开鉴权，我们能接受。
3
https://nacos.io/zh-cn/blog/announcement-token-secret-key.html 先更新了一个方法，减少了失败的时间。
这个方法确实能够一定程度减少影响微服务的时间窗口，但没有完全避免影响到微服务。不过这也是现有情况下的最优方案了。
如果需要完全无损的话， 需要承受一段时间的关闭鉴权，要评估一下风险。
设置ttl=5s 重启集群 运行一段时间，等待客户端获取新的ttl时间 设置新token.secret.key , 并且关闭鉴权，重启集群。（这样客户端会获取到新的token，且请求不会被拒绝，但是集群也没有鉴权能力了） 集群平稳后再开启鉴权。这种基本不会有中断， 但是在变更token.secret.key，重启集群期间没有鉴权，要评估好影响，看是否能接受。
您好，这样可以吗，短时间的不开鉴权，我们能接受。我们去年就加上了鉴权，客户端也加上了用户名密码，我看nacos-cleint的代码是只要客户端携带了 username，不管服务端开不开鉴权，都会请求login接口，然后返回token，那这样的话，在服务端逐台重启的过程中，肯定有由原来的secret.key生成的token啊。怎么做到真正无损？麻烦指导一下。