Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize the default authentication plugin. #13164

Open
KiteSoar opened this issue Mar 9, 2025 · 1 comment
Open

Optimize the default authentication plugin. #13164

KiteSoar opened this issue Mar 9, 2025 · 1 comment
Labels
kind/discussion Category issues related to discussion

Comments

@KiteSoar
Copy link
Contributor

KiteSoar commented Mar 9, 2025

Is your feature request related to a problem? Please describe.
Now, the authentication plug-in provided by Nacos by default needs to persist some information. The data source is supported by MySQL and Derby by default.
现在Nacos默认提供的鉴权插件需要持久化一些信息,数据源默认支持MySQL和Derby

Image

At present, the data source is also provided in the form of a plugin.
目前数据源也是提供插件的形式

Image

If users do not use Derby and MySQL as data sources, they not only need to implement the logic of the corresponding data source according to the Mapper interface provided by the Datasource package, but may also need to rewrite the persistence method in the authentication plugin according to this data source. This feels very strange. When changing the data source, why do you need to modify the things in the authentication plugin in addition to customizing the data source plugin? In addition, currently some SQL statements of the authentication plugin are directly hardcoded, as shown in the following figure.
如果用户不用Derby和MySQL当数据源的话,用户不仅需要自定义数据源插件,可能还要把鉴权插件里持久化的方法也按照这个数据源重写,这个感觉就很奇怪,换个数据源,除了自定义数据源插件,为什么还要去改鉴权插件的东西,除此之外,目前鉴权插件的一些SQL都是直接写死的,如下图所示

Image

这样一旦不同数据源间有语法冲突,如#ISSUE12964,就只能去改Service层的代码,没有抽象出类似Mapper的接口来供多数据源重写

Describe the solution you'd like

  • The authentication plugin depends on the data source plugin. Put the persistence logic of the authentication plugin into the data source plugin and abstract the corresponding Mapper interface at the same time.
  • If the authentication plugin does not depend on the data source plugin, do not hardcode SQL in the Service of the authentication plugin. Instead, abstract a Mapper interface.
  • 鉴权插件依赖数据源插件,把鉴权插件持久化的逻辑放到数据源插件里去,同时抽象出对应的Mapper接口
  • 或者如果鉴权插件不依赖数据源插件的话,在鉴权插件里不要在Service里把SQL写死,抽象出一个Mapper接口
@KomachiSion
Copy link
Collaborator

之前也有类似的ISSUE已经回答过了:

  1. 默认鉴权实现本身是一个插件实现, 鉴权插件依赖数据源插件,相当于插件依赖插件, 不合理
  2. 如果给默认鉴权实现添加一个类似数据源插件的Mapper,代码重复不说, 还出现了给插件写插件的情况,那为什么不直接写一个插件?

说白了默认鉴权插件的实现就是一种插件实现,如果需要将鉴权功能依托于其他数据库,那么就需要自行编写鉴权插件。

当然还有一种办法,就是彻底重构默认鉴权插件,让其不依赖nacos-persistence, 而是依赖spring-jdbc,那需要的重构量非常大,不亚于直接重写一个鉴权插件。

如果有兴趣解决这个问题, 我觉得你可以试试重写一个依赖spring-jdbc的鉴权插件,放到nacos-group/nacos-plugin仓库下, 如果此插件后续稳定了(能够做到彻底平替默认鉴权插件),那么直接将其替换掉即可。

@KomachiSion KomachiSion added the kind/discussion Category issues related to discussion label Mar 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/discussion Category issues related to discussion
Projects
None yet
Development

No branches or pull requests

2 participants