Closed larry4xie closed 1 month ago
需求是合理的,不过实现方式可以讨论下,例如除了打印日志外,是否需要有其它方式感知预校验失败了
需求是合理的,不过实现方式可以讨论下,例如除了打印日志外,是否需要有其它方式感知预校验失败了
Tracer#logEvent
进行感知,虽然我们现在没有开启这个功能,不过如果后续 apollo 提供 Prometheus 实现的时候可以用上apollo.access-key.auth.precheck-enabled
)、一个是触发条件(上面已经表达)我这边目前想到的另外两个可以讨论的实现细节:一个是开关的命名(例如 apollo.access-key.auth.precheck-enabled)、一个是触发条件(上面已经表达)
我觉得不用增加开关,在密钥上增加一个状态即可,例如:观察模式,每个密钥都可以单独配置是否启用观察模式,默认值都是未启用观察模式。 当密钥校验失败时,判断是否是观察模式,如果是则打印日志并放行,如果不是,则拦截请求。
我觉得不用增加开关,在密钥上增加一个状态即可,例如:观察模式,每个密钥都可以单独配置是否启用观察模式,默认值都是未启用观察模式。 当密钥校验失败时,判断是否是观察模式,如果是则打印日志并放行,如果不是,则拦截请求。
这种方式之前也简单想过,增加一个观察模式状态,在一些场景下会产生一定的歧义
启用
和 观察
两个状态,这个时候如果没有匹配启用的密钥就会走拒绝访问,从而走不到观察模式启用
和 观察
状态,不过这样复杂度会稍微提升这两种方式我都可以接受, @nobodyiam 要不你来做个决策呗(或者有其他思路)
这确实是个问题,不过我在想实际场景中是否会存在既有启用(拦截模式)
又有观察模式
的场景?
之前设计多秘钥主要是针对秘钥轮转的场景,一般情况下只会存在一个有效的秘钥。
考虑到第二个方案对用户配置的约束比较多,目前更倾向于第一个方案吧。
具体实现上,可以在 UI 上做一些扩展,例如目前是启用和禁用,可以把启用再进一步细化为
表字段中目前是 IsEnabled
,可以新增一个字段例如 Mode
并设置默认值 0,那么
不过我在想实际场景中是否会存在既有启用(拦截模式)又有观察模式的场景?
实际场景中,我理解是不存在“既有启用(拦截模式)又有观察模式的”,观察模式只适用于正式启用之前的观察阶段
最后再确认一下最终实现方案:
Mode
字段配合现有 IsEnabled
字段,密钥一共会有三种状态
IsEnabled = 0
+ Mode=0
IsEnabled = 1
+ Mode=0
IsEnabled = 1
+ Mode=1
Logger
和 Tracer#logEvent
两类日志@nobodyiam 如果没有问题,我就最近找时间实现一下?
禁用:IsEnabled = 0 + Mode=0
禁用应该不用看 Mode 字段的值,其它我觉得 OK
你的特性请求和某个问题有关吗?请描述
清晰简洁地描述一下你希望的解决方案
兼容性
)开关开启
+有密钥配置
+所有密钥均未开启
appId
,clientIp
,authorization
等信息BTW:如果认为这是一个合理的诉求,这边可以提一个 PR 进行实现