nacos
nacos copied to clipboard
alibaba
token.secret.key漏洞修复问题
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:
- Go to '...'
- Click on '....'
- Scroll down to '....'
- 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.
同问，token.secret.key配置项更改了之后需要重启服务端吗？另外如何验证配置是否生效呢，看网上很多帖子是说更改了之后没有生效的。
同问，token.secret.key配置项更改了之后需要重启服务端吗？另外如何验证配置是否生效呢，看网上很多帖子是说更改了之后没有生效的。
拿一个旧版本的token，请求一下就知道是否生效了。
对于正在使用nacos的微服务已经申请的accessToken会有什么影响呢，微服务引入的nacos-client包会自动获取新的accessToken吗？
client会异步定时调用login接口获取新accessToken。
nacos的微服务已经申请的accessToken会有什么影响呢，微服务引入的nacos-client包会自动获取新的accessToken吗
目前好像客户端会等到旧的token到达过期时间后，才会去获取新的token， 这期间应该会影响，目前好像只能重启客户端程序执行重新登陆。 我研究下有没有办法能处理一下， 后续更新一下文档。
对于正在使用nacos的微服务已经申请的accessToken会有什么影响呢，微服务引入的nacos-client包会自动获取新的accessToken吗？
client会异步定时调用login接口获取新accessToken。
所以如果正在运行的Nacos进行更换token并重启以后，nacos-client通过旧的accessToken调用Nacos一定会失败，并且不会立即获取新的accessToken，
nacos的微服务已经申请的accessToken会有什么影响呢，微服务引入的nacos-client包会自动获取新的accessToken吗
目前好像客户端会等到旧的token到达过期时间后，才会去获取新的token， 这期间应该会影响，目前好像只能重启客户端程序执行重新登陆。 我研究下有没有办法能处理一下， 后续更新一下文档。
好的，那这个方案感觉有点不太完美，目前已经有很多微服务正在使用，如果直接修改nacos配置并重启，短时间内几乎会影响所有的微服务，要重启所有微服务的话公司业务层面肯定是不允许的，工作量巨大，影响范围也特别广
目前想到的方式： 先修改ttl， 运行一段时间让客户端先快速过期旧token， 然后再修改新token，缩短客户端因token变更导致的请求失败时间。
https://nacos.io/zh-cn/blog/announcement-token-secret-key.html
先更新了一个方法，减少了失败的时间。
https://nacos.io/zh-cn/blog/announcement-token-secret-key.html
先更新了一个方法，减少了失败的时间。
这个方法确实能够一定程度减少影响微服务的时间窗口，但没有完全避免影响到微服务。不过这也是现有情况下的最优方案了。
https://nacos.io/zh-cn/blog/announcement-token-secret-key.html 先更新了一个方法，减少了失败的时间。
这个方法确实能够一定程度减少影响微服务的时间窗口，但没有完全避免影响到微服务。不过这也是现有情况下的最优方案了。
如果需要完全无损的话， 需要承受一段时间的关闭鉴权，要评估一下风险。
- 设置ttl=5s 重启集群
- 运行一段时间，等待客户端获取新的ttl时间
- 设置新token.secret.key , 并且关闭鉴权，重启集群。（这样客户端会获取到新的token，且请求不会被拒绝，但是集群也没有鉴权能力了）
- 集群平稳后再开启鉴权。
这种基本不会有中断， 但是在变更token.secret.key，重启集群期间没有鉴权，要评估好影响，看是否能接受。
https://nacos.io/zh-cn/blog/announcement-token-secret-key.html 先更新了一个方法，减少了失败的时间。
这个方法确实能够一定程度减少影响微服务的时间窗口，但没有完全避免影响到微服务。不过这也是现有情况下的最优方案了。
如果需要完全无损的话， 需要承受一段时间的关闭鉴权，要评估一下风险。
- 设置ttl=5s 重启集群
- 运行一段时间，等待客户端获取新的ttl时间
- 设置新token.secret.key , 并且关闭鉴权，重启集群。（这样客户端会获取到新的token，且请求不会被拒绝，但是集群也没有鉴权能力了）
- 集群平稳后再开启鉴权。
这种基本不会有中断， 但是在变更token.secret.key，重启集群期间没有鉴权，要评估好影响，看是否能接受。
好的。
https://nacos.io/zh-cn/blog/announcement-token-secret-key.html 先更新了一个方法，减少了失败的时间。
这个方法确实能够一定程度减少影响微服务的时间窗口，但没有完全避免影响到微服务。不过这也是现有情况下的最优方案了。
如果需要完全无损的话， 需要承受一段时间的关闭鉴权，要评估一下风险。
- 设置ttl=5s 重启集群
- 运行一段时间，等待客户端获取新的ttl时间
- 设置新token.secret.key , 并且关闭鉴权，重启集群。（这样客户端会获取到新的token，且请求不会被拒绝，但是集群也没有鉴权能力了）
- 集群平稳后再开启鉴权。
这种基本不会有中断， 但是在变更token.secret.key，重启集群期间没有鉴权，要评估好影响，看是否能接受。
简化为以下步骤可行吗？@KomachiSion
-
逐台关闭鉴权，无需重启集群（鉴权开关是立即生效的）；
-
30分钟后，逐台设置新token.secret.key。然后重启集群(不需要设置ttl)； 之所以等30分钟，而没有和第一步合并，是因为害怕有一些客户端连接到新的secret.key服务，生成新token，用这个新token去请求还没来得及修改secret.key并重启的服务端，这样会导致鉴权失败。
-
6小时后逐台开启鉴权，无需重启集群（鉴权开关是立即生效的）； 之所以等6小时，因为原token默认有效期为5小时，6小时后客户端的token应该都是用新secret.key生成的。
这样按照这个步骤只需要3步，并且耗时大概7小时，当然这期间集群没有鉴权。
我的版本是2.3.1。官方已经不给nacos.core.auth.plugin.nacos.token.secret.key 默认值了。但是利用这个漏洞好像还可以进入登录页面，但是看不到任何配置了。这是官方漏洞修复后的正常效果不，期待回复，万分感谢！
我的版本是2.3.1。官方已经不给nacos.core.auth.plugin.nacos.token.secret.key 默认值了。但是利用这个漏洞好像还可以进入登录页面，但是看不到任何配置了。这是官方漏洞修复后的正常效果不，期待回复，万分感谢！
看不到任何配置，那肯定算修复了。