token.secret.key漏洞修复问题

[David-wu91]

Describe the bug
关于token.secret.key漏洞问题的修复，如果直接修改正在运行的nacos集群的token.secret.key的默认值以后，对于正在使用nacos的微服务已经申请的accessToken会有什么影响呢，微服务引入的nacos-client包会自动获取新的accessToken吗？

Expected behavior
A clear and concise description of what you expected to happen.

Actually behavior
A clear and concise description of what you actually to happen.

How to Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See errors

Desktop (please complete the following information):

• OS: [e.g. Centos]
• Version [e.g. nacos-server 1.3.1, nacos-client 1.3.1]
• Module [e.g. naming/config]
• SDK [e.g. original, spring-cloud-alibaba-nacos, dubbo]

Additional context
Add any other context about the problem here.

[yangfan-witcher]

同问，token.secret.key配置项更改了之后需要重启服务端吗？另外如何验证配置是否生效呢，看网上很多帖子是说更改了之后没有生效的。

[KomachiSion]

需要重启

[KomachiSion]

同问，token.secret.key配置项更改了之后需要重启服务端吗？另外如何验证配置是否生效呢，看网上很多帖子是说更改了之后没有生效的。

拿一个旧版本的token，请求一下就知道是否生效了。

[KomachiSion]

对于正在使用nacos的微服务已经申请的accessToken会有什么影响呢，微服务引入的nacos-client包会自动获取新的accessToken吗？

client会异步定时调用login接口获取新accessToken。

[KomachiSion]

nacos的微服务已经申请的accessToken会有什么影响呢，微服务引入的nacos-client包会自动获取新的accessToken吗

目前好像客户端会等到旧的token到达过期时间后，才会去获取新的token， 这期间应该会影响，目前好像只能重启客户端程序执行重新登陆。 我研究下有没有办法能处理一下， 后续更新一下文档。

[David-wu91]

对于正在使用nacos的微服务已经申请的accessToken会有什么影响呢，微服务引入的nacos-client包会自动获取新的accessToken吗？

client会异步定时调用login接口获取新accessToken。

所以如果正在运行的Nacos进行更换token并重启以后，nacos-client通过旧的accessToken调用Nacos一定会失败，并且不会立即获取新的accessToken，

nacos的微服务已经申请的accessToken会有什么影响呢，微服务引入的nacos-client包会自动获取新的accessToken吗

目前好像客户端会等到旧的token到达过期时间后，才会去获取新的token， 这期间应该会影响，目前好像只能重启客户端程序执行重新登陆。 我研究下有没有办法能处理一下， 后续更新一下文档。

好的，那这个方案感觉有点不太完美，目前已经有很多微服务正在使用，如果直接修改nacos配置并重启，短时间内几乎会影响所有的微服务，要重启所有微服务的话公司业务层面肯定是不允许的，工作量巨大，影响范围也特别广

[KomachiSion]

目前想到的方式： 先修改ttl， 运行一段时间让客户端先快速过期旧token， 然后再修改新token，缩短客户端因token变更导致的请求失败时间。

[KomachiSion]

https://nacos.io/zh-cn/blog/announcement-token-secret-key.html

先更新了一个方法，减少了失败的时间。

[David-wu91]

https://nacos.io/zh-cn/blog/announcement-token-secret-key.html

先更新了一个方法，减少了失败的时间。

这个方法确实能够一定程度减少影响微服务的时间窗口，但没有完全避免影响到微服务。不过这也是现有情况下的最优方案了。

[KomachiSion]

https://nacos.io/zh-cn/blog/announcement-token-secret-key.html
先更新了一个方法，减少了失败的时间。

这个方法确实能够一定程度减少影响微服务的时间窗口，但没有完全避免影响到微服务。不过这也是现有情况下的最优方案了。

如果需要完全无损的话， 需要承受一段时间的关闭鉴权，要评估一下风险。

1. 设置ttl=5s 重启集群
2. 运行一段时间，等待客户端获取新的ttl时间
3. 设置新token.secret.key , 并且关闭鉴权，重启集群。（这样客户端会获取到新的token，且请求不会被拒绝，但是集群也没有鉴权能力了）
4. 集群平稳后再开启鉴权。

这种基本不会有中断， 但是在变更token.secret.key，重启集群期间没有鉴权，要评估好影响，看是否能接受。

[David-wu91]

https://nacos.io/zh-cn/blog/announcement-token-secret-key.html
先更新了一个方法，减少了失败的时间。

这个方法确实能够一定程度减少影响微服务的时间窗口，但没有完全避免影响到微服务。不过这也是现有情况下的最优方案了。

如果需要完全无损的话， 需要承受一段时间的关闭鉴权，要评估一下风险。

1. 设置ttl=5s 重启集群
2. 运行一段时间，等待客户端获取新的ttl时间
3. 设置新token.secret.key , 并且关闭鉴权，重启集群。（这样客户端会获取到新的token，且请求不会被拒绝，但是集群也没有鉴权能力了）
4. 集群平稳后再开启鉴权。

这种基本不会有中断， 但是在变更token.secret.key，重启集群期间没有鉴权，要评估好影响，看是否能接受。

好的。

[jefferson-chern]

https://nacos.io/zh-cn/blog/announcement-token-secret-key.html
先更新了一个方法，减少了失败的时间。

这个方法确实能够一定程度减少影响微服务的时间窗口，但没有完全避免影响到微服务。不过这也是现有情况下的最优方案了。

如果需要完全无损的话， 需要承受一段时间的关闭鉴权，要评估一下风险。

1. 设置ttl=5s 重启集群
2. 运行一段时间，等待客户端获取新的ttl时间
3. 设置新token.secret.key , 并且关闭鉴权，重启集群。（这样客户端会获取到新的token，且请求不会被拒绝，但是集群也没有鉴权能力了）
4. 集群平稳后再开启鉴权。

这种基本不会有中断， 但是在变更token.secret.key，重启集群期间没有鉴权，要评估好影响，看是否能接受。

简化为以下步骤可行吗？@KomachiSion

1. 逐台关闭鉴权，无需重启集群（鉴权开关是立即生效的）；

2. 30分钟后，逐台设置新token.secret.key。然后重启集群(不需要设置ttl)；
   之所以等30分钟，而没有和第一步合并，是因为害怕有一些客户端连接到新的secret.key服务，生成新token，用这个新token去请求还没来得及修改secret.key并重启的服务端，这样会导致鉴权失败。

3. 6小时后逐台开启鉴权，无需重启集群（鉴权开关是立即生效的）；
   之所以等6小时，因为原token默认有效期为5小时，6小时后客户端的token应该都是用新secret.key生成的。

这样按照这个步骤只需要3步，并且耗时大概7小时，当然这期间集群没有鉴权。

[pc-gh]

我的版本是2.3.1。官方已经不给nacos.core.auth.plugin.nacos.token.secret.key 默认值了。但是利用这个漏洞好像还可以进入登录页面，但是看不到任何配置了。这是官方漏洞修复后的正常效果不，期待回复，万分感谢！