Comments (15)
看了一下,发现在逻辑上确实存在点问题(在存在加密插件情况下):
1、v1版本的发布配置接口,接收前端的 encryptedDataKey
,但是在存储时却是明文
2、v2版本的发布配置接口,不接受前端传 encryptedDataKey
,配置使用的密钥完全在 server
上闭环,存储的时候是存密文
3、sdk的发布配置接口,接收端上传递的 encryptedDataKey
,同v2版本接口存储也是密文 (区别在于网络传输也是密文,v2是明文)
问题貌似主要在v1版本接口,看下v1版本接口要不要和v2版本接口对齐,都不接受前端传递的 encryptedDataKey
,而是去插件里获取,这样的话,就统一了,问 @KomachiSion
from nacos.
看了一下,发现在逻辑上确实存在点问题(在存在加密插件情况下): 1、v1版本的发布配置接口,接收前端的
encryptedDataKey
,但是在存储时却是明文 2、v2版本的发布配置接口,不接受前端传encryptedDataKey
,配置使用的密钥完全在server
上闭环,存储的时候是存密文 3、sdk的发布配置接口,接收端上传递的encryptedDataKey
,同v2版本接口存储也是密文 (区别在于网络传输也是密文,v2是明文)问题貌似主要在v1版本接口,看下v1版本接口要不要和v2版本接口对齐,都不接受前端传递的
encryptedDataKey
,而是去插件里获取,这样的话,就统一了,问 @KomachiSion
Yeah, and I would also like to make some additions about the current strategies for these three situations:
- For the v1 api, for data without an
encryptedDataKey
field, useEncryptionHandler.encryptHandler(dataId, content)
to complete the encryption process on the data, and obtain the encrypted content and correspondingencryptedDataKey
. For data with anencryptedDataKey
field, directly use thecontent
andencryptedDataKey
input parameters. - For the v2 api, it uses
EncryptionHandler.encryptHandler(dataId, content)
to complete the encryption process on the data anyway, and obtains the encrypted content and the correspondingencryptedDataKey
. - sdk (via grpc), no encryption processing is performed, and the input parameters
content
andencryptedDataKey
(optional) are used directly
It is possible that the strategies are different due to different versions and services, but currently, there is a problem with the cooperation between console-ui and v1 API, which is this issue.
是的,我想再具体一下你说的这三个情况目前的策略:
- v1的api,对于没有
encryptedDataKey
字段的数据,对数据使用EncryptionHandler.encryptHandler(dataId, content)
完成加密处理,得到加密了的content和对应的encryptedDataKey
。对于有encryptedDataKey
字段的数据,直接使用入参的content
和encryptedDataKey
。 - v2的api,无论如何都对数据使用
EncryptionHandler.encryptHandler(dataId, content)
完成加密处理,得到加密了的content和对应的encryptedDataKey
。 - sdk(grpc),不进行处理,直接使用入参的
content
和encryptedDataKey
(可选的)。
有可能因为版本以及面向的服务不同,策略有所不同,但目前看,console-ui和v1 API的配合上,是有问题的。
from nacos.
这里v1 v2版本的后端处理接口不一致,是一个问题。
从后端接口的角度应该这样处理,发布接口接收content和encryptedDataKey。
如果encryptedDataKey 不为空,表示接口已经对明文进行过加密,则直接存储content(此时认为参数中的content已是密文)和encryptedDataKey
如果encryptedDataKey为空,则通过加解密插件对content(此时认为参数中的content为明文,根据插件中自定义规则判断是都需要加密)进行加密获得 加密后的content和encryptedDataKey
from nacos.
这里v1 v2版本的后端处理接口不一致,是一个问题。 从后端接口的角度应该这样处理,发布接口接收content和encryptedDataKey。 如果encryptedDataKey 不为空,表示接口已经对明文进行过加密,则直接存储content(此时认为参数中的content已是密文)和encryptedDataKey 如果encryptedDataKey为空,则通过加解密插件对content(此时认为参数中的content为明文,根据插件中自定义规则判断是都需要加密)进行加密获得 加密后的content和encryptedDataKey
Thanks for your answer.According to your reply, can I understand it this way:
- V2 API is not the latest. It should be consistent with v1 (if there has
encryptedDataKey
field, directly use the content and encryptedDataKey, no longer callEncryptionHandler.encryptHandler(dataId, content)
) - console-ui should not offer the
encryptedDataKey
field during config updates
感谢,按照这个说法,是否可以这么理解:
- v2的接口不是最新的,其逻辑应该与v1的保持一致(如果存在
encryptedDataKey
,不再调用EncryptionHandler.encryptHandler(dataId, content)
执行加密逻辑) - console-ui在进行配置更新时,不应该传输
encryptedDataKey
字段
from nacos.
这里v1 v2版本的后端处理接口不一致,是一个问题。 从后端接口的角度应该这样处理,发布接口接收content和encryptedDataKey。 如果encryptedDataKey 不为空,表示接口已经对明文进行过加密,则直接存储content(此时认为参数中的content已是密文)和encryptedDataKey 如果encryptedDataKey为空,则通过加解密插件对content(此时认为参数中的content为明文,根据插件中自定义规则判断是都需要加密)进行加密获得 加密后的content和encryptedDataKey
Thanks for your answer.According to your reply, can I understand it this way:
- V2 API is not the latest. It should be consistent with v1 (if there has
encryptedDataKey
field, directly use the content and encryptedDataKey, no longer callEncryptionHandler.encryptHandler(dataId, content)
)- console-ui should not offer the
encryptedDataKey
field during config updates感谢,按照这个说法,是否可以这么理解:
- v2的接口不是最新的,其逻辑应该与v1的保持一致(如果存在
encryptedDataKey
,不再调用EncryptionHandler.encryptHandler(dataId, content)
执行加密逻辑)- console-ui在进行配置更新时,不应该传输
encryptedDataKey
字段
是应该这样处理,每个接口当前上层调用的入口不一致,所以逻辑没有统一,是需要统一下,我翻了下开源的console-ui的配置更新前端代码,好像没有看到前端会传encryptedDataKey 这个字段,你是修改了前端的代码么
from nacos.
这里v1 v2版本的后端处理接口不一致,是一个问题。 从后端接口的角度应该这样处理,发布接口接收content和encryptedDataKey。 如果encryptedDataKey 不为空,表示接口已经对明文进行过加密,则直接存储content(此时认为参数中的content已是密文)和encryptedDataKey 如果encryptedDataKey为空,则通过加解密插件对content(此时认为参数中的content为明文,根据插件中自定义规则判断是都需要加密)进行加密获得 加密后的content和encryptedDataKey
Thanks for your answer.According to your reply, can I understand it this way:
- V2 API is not the latest. It should be consistent with v1 (if there has
encryptedDataKey
field, directly use the content and encryptedDataKey, no longer callEncryptionHandler.encryptHandler(dataId, content)
)- console-ui should not offer the
encryptedDataKey
field during config updates感谢,按照这个说法,是否可以这么理解:
- v2的接口不是最新的,其逻辑应该与v1的保持一致(如果存在
encryptedDataKey
,不再调用EncryptionHandler.encryptHandler(dataId, content)
执行加密逻辑)- console-ui在进行配置更新时,不应该传输
encryptedDataKey
字段是应该这样处理,每个接口当前上层调用的入口不一致,所以逻辑没有统一,是需要统一下,我翻了下开源的console-ui的配置更新前端代码,好像没有看到前端会传encryptedDataKey 这个字段,你是修改了前端的代码么
No, I just used the official Docker image
没有哦,我用的官方的Docker镜像
from nacos.
这里v1 v2版本的后端处理接口不一致,是一个问题。 从后端接口的角度应该这样处理,发布接口接收content和encryptedDataKey。 如果encryptedDataKey 不为空,表示接口已经对明文进行过加密,则直接存储content(此时认为参数中的content已是密文)和encryptedDataKey 如果encryptedDataKey为空,则通过加解密插件对content(此时认为参数中的content为明文,根据插件中自定义规则判断是都需要加密)进行加密获得 加密后的content和encryptedDataKey
Thanks for your answer.According to your reply, can I understand it this way:
- V2 API is not the latest. It should be consistent with v1 (if there has
encryptedDataKey
field, directly use the content and encryptedDataKey, no longer callEncryptionHandler.encryptHandler(dataId, content)
)- console-ui should not offer the
encryptedDataKey
field during config updates感谢,按照这个说法,是否可以这么理解:
- v2的接口不是最新的,其逻辑应该与v1的保持一致(如果存在
encryptedDataKey
,不再调用EncryptionHandler.encryptHandler(dataId, content)
执行加密逻辑)- console-ui在进行配置更新时,不应该传输
encryptedDataKey
字段是应该这样处理,每个接口当前上层调用的入口不一致,所以逻辑没有统一,是需要统一下,我翻了下开源的console-ui的配置更新前端代码,好像没有看到前端会传encryptedDataKey 这个字段,你是修改了前端的代码么
May be because the API(show=all) for getting the configuration returns encryptedDataKey
field, so it is also sent back by console-ui when updating.
I tested it and found that even if I did not turn on encryption, console-ui would also provide the encryptedDataKey
field (an empty string)
可能是因为获取配置的接口(show=all)返回了encryptedDataKey
字段,所以更新的时候一并传回去了。
我测试了一下,即便我没有开启加密,console-ui也会提供encryptedDataKey
字段(为空字符串)
from nacos.
这里v1 v2版本的后端处理接口不一致,是一个问题。 从后端接口的角度应该这样处理,发布接口接收content和encryptedDataKey。 如果encryptedDataKey 不为空,表示接口已经对明文进行过加密,则直接存储content(此时认为参数中的content已是密文)和encryptedDataKey 如果encryptedDataKey为空,则通过加解密插件对content(此时认为参数中的content为明文,根据插件中自定义规则判断是都需要加密)进行加密获得 加密后的content和encryptedDataKey
Thanks for your answer.According to your reply, can I understand it this way:
- V2 API is not the latest. It should be consistent with v1 (if there has
encryptedDataKey
field, directly use the content and encryptedDataKey, no longer callEncryptionHandler.encryptHandler(dataId, content)
)- console-ui should not offer the
encryptedDataKey
field during config updates感谢,按照这个说法,是否可以这么理解:
- v2的接口不是最新的,其逻辑应该与v1的保持一致(如果存在
encryptedDataKey
,不再调用EncryptionHandler.encryptHandler(dataId, content)
执行加密逻辑)- console-ui在进行配置更新时,不应该传输
encryptedDataKey
字段是应该这样处理,每个接口当前上层调用的入口不一致,所以逻辑没有统一,是需要统一下,我翻了下开源的console-ui的配置更新前端代码,好像没有看到前端会传encryptedDataKey 这个字段,你是修改了前端的代码么
May be because the API(show=all) for getting the configuration returns
encryptedDataKey
field, so it is also sent back by console-ui when updating.I tested it and found that even if I did not turn on encryption, console-ui would also provide the
encryptedDataKey
field (an empty string)可能是因为获取配置的接口(show=all)返回了
encryptedDataKey
字段,所以更新的时候一并传回去了。 我测试了一下,即便我没有开启加密,console-ui也会提供encryptedDataKey
字段(为空字符串)
那这里是自动把前面的接口里的数据都原封不动地传入配置发布接口里了,那前端做下处理,把这个key给过滤掉就好了
from nacos.
这里v1 v2版本的后端处理接口不一致,是一个问题。 从后端接口的角度应该这样处理,发布接口接收content和encryptedDataKey。 如果encryptedDataKey 不为空,表示接口已经对明文进行过加密,则直接存储content(此时认为参数中的content已是密文)和encryptedDataKey 如果encryptedDataKey为空,则通过加解密插件对content(此时认为参数中的content为明文,根据插件中自定义规则判断是都需要加密)进行加密获得 加密后的content和encryptedDataKey
这里有个问题,目前控制台传递的 content
是明文的,只有 sdk
传递的会是密文。而且针对前端,是不知道配置内容和密钥是用什么加解密的,没办法加密 content
from nacos.
这里v1 v2版本的后端处理接口不一致,是一个问题。 从后端接口的角度应该这样处理,发布接口接收content和encryptedDataKey。 如果encryptedDataKey 不为空,表示接口已经对明文进行过加密,则直接存储content(此时认为参数中的content已是密文)和encryptedDataKey 如果encryptedDataKey为空,则通过加解密插件对content(此时认为参数中的content为明文,根据插件中自定义规则判断是都需要加密)进行加密获得 加密后的content和encryptedDataKey
Thanks for your answer.According to your reply, can I understand it this way:
- V2 API is not the latest. It should be consistent with v1 (if there has
encryptedDataKey
field, directly use the content and encryptedDataKey, no longer callEncryptionHandler.encryptHandler(dataId, content)
)- console-ui should not offer the
encryptedDataKey
field during config updates感谢,按照这个说法,是否可以这么理解:
- v2的接口不是最新的,其逻辑应该与v1的保持一致(如果存在
encryptedDataKey
,不再调用EncryptionHandler.encryptHandler(dataId, content)
执行加密逻辑)- console-ui在进行配置更新时,不应该传输
encryptedDataKey
字段是应该这样处理,每个接口当前上层调用的入口不一致,所以逻辑没有统一,是需要统一下,我翻了下开源的console-ui的配置更新前端代码,好像没有看到前端会传encryptedDataKey 这个字段,你是修改了前端的代码么
May be because the API(show=all) for getting the configuration returns
encryptedDataKey
field, so it is also sent back by console-ui when updating.
I tested it and found that even if I did not turn on encryption, console-ui would also provide theencryptedDataKey
field (an empty string)
可能是因为获取配置的接口(show=all)返回了encryptedDataKey
字段,所以更新的时候一并传回去了。 我测试了一下,即便我没有开启加密,console-ui也会提供encryptedDataKey
字段(为空字符串)那这里是自动把前面的接口里的数据都原封不动地传入配置发布接口里了,那前端做下处理,把这个key给过滤掉就好了
Can I create a pull request to fix it ?
from nacos.
这里v1 v2版本的后端处理接口不一致,是一个问题。 从后端接口的角度应该这样处理,发布接口接收content和encryptedDataKey。 如果encryptedDataKey 不为空,表示接口已经对明文进行过加密,则直接存储content(此时认为参数中的content已是密文)和encryptedDataKey 如果encryptedDataKey为空,则通过加解密插件对content(此时认为参数中的content为明文,根据插件中自定义规则判断是都需要加密)进行加密获得 加密后的content和encryptedDataKey
这里有个问题,目前控制台传递的
content
是明文的,只有sdk
传递的会是密文。而且针对前端,是不知道配置内容和密钥是用什么加解密的,没办法加密content
In his opinion,what I understand is that console-ui do not need to send the content
which is encrypted,and the encryptedDataKey
need to be empty all the time.
我理解他的意见是 console-ui 传递的encryptedDataKey
需要为空,content
为明文,不需要考虑加解密的事情。
from nacos.
理解了。那你能提个pr?做两个事情:
- 按 @shiyiyue1102 说的处理方式,把v2接口和v1接口同步一下
从后端接口的角度应该这样处理,发布接口接收content和encryptedDataKey。
如果encryptedDataKey 不为空,表示接口已经对明文进行过加密,则直接存储content(此时认为参数中的content已是密文)和encryptedDataKey
如果encryptedDataKey为空,则通过加解密插件对content(此时认为参数中的content为明文,根据插件中自定义规则判断是都需要加密)进行加密获得 加密后的content和encryptedDataKey
- console-ui上把
encryptedDataKey
过滤掉 - 单测
from nacos.
理解了。那你能提个pr?做两个事情:
- 按 @shiyiyue1102 说的处理方式,把v2接口和v1接口同步一下
从后端接口的角度应该这样处理,发布接口接收content和encryptedDataKey。 如果encryptedDataKey 不为空,表示接口已经对明文进行过加密,则直接存储content(此时认为参数中的content已是密文)和encryptedDataKey 如果encryptedDataKey为空,则通过加解密插件对content(此时认为参数中的content为明文,根据插件中自定义规则判断是都需要加密)进行加密获得 加密后的content和encryptedDataKey
- console-ui上把
encryptedDataKey
过滤掉- 单测
OK,I will resolve it. :-)
from nacos.
@xyohn any more PR? Or this issue has been fixed in #12061?
from nacos.
yeah,it has been fixed. I will close this issue, thanks.
from nacos.
Related Issues (20)
- [Feature] Refactor Nacos-Ctl and support more capabilities HOT 2
- Nacos unable to publish flow control rules to Sentinel Dashboard HOT 3
- 关闭 /actuator接口失败问题 HOT 6
- 通过restful接口更新持久化switchdomain失败 HOT 7
- 2.2.0.1控制台服务详情页,点上线,服务依然无法上线 HOT 3
- Log output sensitive information
- nacos2.X修改数据源后导致的服务端配置缓存刷新缓慢问题 HOT 1
- nacos2.4.1在jdk21下启动失败(Description nacos2.4.1 failed to start in jdk21) HOT 7
- 2.4.1在jdk11下无法启动并报错 HOT 3
- jdk21模块化项目集成nacos.client报错 HOT 8
- nacos-client-2.4.0 AND nacos-client-2.4.1 not find DefaultParamChecker HOT 1
- SQLException: ERROR: LIMIT #,# syntax is not supported Hint during add configuration data from WebUI HOT 7
- 使用运维API修改SwitchDomain部分开关无效. HOT 3
- Why did this method comment the code internally, resulting in an error HOT 1
- write lock failed without retry HOT 4
- 2.4.1版本standalone模式启动No leader for raft group naming_persistent_service HOT 2
- k8s集群中部署nacos集群三节点,当k8s集群的某个node节点宕机后,nacos集群服务可用恢复很慢 HOT 4
- 启动startup.sh脚本,日志报错 HOT 3
- You must have a database connection to connect to Nacos HOT 1
- Parameter check is invalid in 2.4.0 and 2.4.1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nacos.