nacos密码修改,导致seata启动失败问题(源码分析)

持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第3天,点击查看活动详情


今天刚起床,实施人员一通夺命电话打来:咋回事呢?表单数据咋保存不了了呢?=_=

好家伙,听到后,一顿蒙蔽,真是头秃呀,大早上夺命call!!!

image.png

心里想了一下,哥们好像也没干啥事呀?什么情况呢!!!

image.png

等等,想起来了,好像昨天对nacos未授权访问的漏洞进行了修复,该不会是这个导致的吧?

然后赶紧回公司,查看了一下服务器,好家伙还真是这个,seata挂掉了。分布式事务不行了,导致表单保存失败了!!!

这个确实是哥们的问题,没有注意到这个问题!!!

不会被扣工资吧???

image.png

行吧,那今天咋们来说一下,nacos开启认证,并修改密码。seata分布式事务,启动失败的问题,进行讨论和研究!!!

一直报403认证失败的问题,进行解决!!!

1.重要说明

该问题出现的版本,seata1.4.2 以下都会有。

2.nacos漏洞修复

之前对nacos未授权访问的漏洞进行了修复,开启了nacos认证访问和对密码进行了修改。

vi nacos/conf/application.properties

#开启认证配置
nacos.core.auth.enabled=true
复制代码

image-20220526115547418.png

修改密码为:nacos123!@

3.seata启动

已经将配置文件的密码,都修改为nacos123!@,但是seata就是死活启动不了!!!

image-20220526120034644.png

image-20220526123106028.png

seata已经整合的nacos作为配置中心和注册中心,如何整合,这里就不再细讲了,可以参考这里

image-20220526123243400.png

然后,网上找了一些答案,是这样说的,密码有特殊字符,被转义了!!!

image-20220526123406145.png

好吧,那咱们就改一下nacos的密码,改成nacos123,把特殊符号去掉,测试一下:

image-20220526123553039.png

image-20220526123640605.png

好家伙,启动成功了,还真是这个问题!!!

image-20220526123748880.png

4.原因分析

看到这里,咱们不禁得想一下,究竟是哪里对密码进行了转义呢?

有好奇心的同学,咱们继续往下看,从源码中分析一下,找到转义的代码。

开干!!!

seata源码构建。可以参考这里:点击查看,这里就不再一 一讲解了!!!

现在,咱们一步步进行debug调试:

  • 直接启动server.java

image-20220526124806092.png

image-20220526125034041.png

启动报错了,NacosConfiguration出错了。那我们进入到NacosConfiguration类去看一下报错的地方。

这个错是NacosConfiguration输出的,我们可以通过输出的日志定位到具体的位置,但是这里没有,所以我们将断点,打到所有的logger上面来。

image-20220526125535650.png

可以看到是NacosConfiguration.getLatestConfig方法打印的错误日志信息。

说明是configService.getConfig方法抛弃异常了,那我们进入configService.getConfig方法查看。

image-20220526134846878.png

以上就是一步步调试,进入的方法图了,最终是NacosRestTemplate的execute方法,执行http请求,与nacos进行交互

那我们在execute方法,打个断点。

image-20220526135427339.png

很明显,已经快要找到原因了,已经看到password,确实是被转义了。

接下来,对方法调用栈一步步往上找,即可。

image-20220526135911713.png

很明显可以看到,就是这里的问题了:SecurityProxy类,login方法,URLEncoder.encode(password, "utf-8")

注意:nacos-client的版本是1.3.3

原因找到了!!!

image-20220526140234635.png

好的,看到这里,基本上,咱们就已经知道password被转义具体的原因了,也能知道是在哪里被转义了。

看到这里,咱们就有点奇怪了,seata版本是1.4.1,为啥用1.3.3版本的nacos-client呢?

难道这里,会有什么猫腻?

带着这个问题,我们看一下1.4.1版本的nacos-clientSecurityProxy类。

image-20220526140550882.png

看到这里,nacos-client的1.4.1版本,已经不再对password进行encode了。

真有你的!!!

image-20220526140951031.png

然后,心里就想着,这个是不是官方的bug呢?seata1.4.1版本源码,为啥用1.3.3版本的nacos-client,进行构建呢?

image-20220526141637750.png

确实是1.3.3版本的nacos-client

还是不死心,那么再看一下1.4.2版本的seata?:pom依赖

image-20220526141842305.png

1.4.2版本的seata,也是1.3.3版本的nacos-client

官方,真真有你的!!!

image-20220526142320615.png

最终解决办法:

1.升级seata版本,至少要大于1.4.2。(不知道1.5.1版本,有无修复这个bug呢,交给有缘人去测试了!)

2.修改nacos密码,不要出现特殊字符。

3.对1.4.1版本的seata源码,修改nacos-client版本为1.4.1,重新构建seata服务。(不知道会有什么坑哈,交给有缘人去测试了!)

最终,我这里,不想折腾了,选择,第二种方式了,快捷!!!

装逼完成!!!

image-20220526142708885.png

好了,nacos密码修改,导致seata启动失败问题(源码分析),就到这里了!!!

今天就先到这里了,溜了溜了溜了!!!^_^

觉得有收获的,帮忙点个赞呗!!!

image.png

猜你喜欢

转载自juejin.im/post/7102413947596177416