Apollo ConfigServer没有对不存在的Appid的请求做前置过滤

[youngzil]

你的特性请求和某个问题有关吗？请描述

在公司内部，偶然发现有很多无效的请求，请求上附带的appid是一个在服务端不存在的，无效的appid，导致后续还会一直存在很多404、304的请求

清晰简洁地描述一下你希望的解决方案

是否可以在Apollo ConfigServer前置一个 BloomFilter ，过滤此类的请求，返回特定含义的response status，提醒客户端问题
目前没有过滤，是有什么特殊的考虑吗？

清晰简洁地描述一下这个特性的备选方案

其它背景

在这里添加和这个特性请求有关的背景说明、截图

[dosubot]

🤖

你好 @youngzil, 我是 Dosu。我是一个能帮助你解决bug、回答问题，并成为贡献者的机器人。我在这里帮助你，同时等待人类维护者的回复。我很高兴能为你提供帮助。

在技术上，确实可以在Apollo ConfigServer中实现一个BloomFilter来过滤出带有无效appid的请求，但是有几个考虑因素可能阻止这种实现：

1. 假阳性：Bloom过滤器有一定的假阳性概率。这意味着即使appid是有效的，Bloom过滤器也可能错误地将其识别为无效。这可能导致有效的请求被拒绝。

2. 内存使用：Bloom过滤器需要一定量的内存来存储元素集。如果appid的数量非常大，Bloom过滤器可能需要大量的内存。

3. 不可变性：Bloom过滤器是不可变的。这意味着一旦将元素添加到过滤器中，就无法将其删除。如果有效appid的集合经常变化，这可能是一个问题。

4. 复杂性：当前使用正则表达式验证appid的实现是简单直接的。实现Bloom过滤器将增加代码的复杂性。

考虑到提供的上下文，当前的实现使用正则表达式验证appid，这是一种简单有效的方法。如果appid的数量不是很大并且不经常变化，这种方法可能比Bloom过滤器更适合。相关的代码可以在这个链接找到：apollo-common/src/main/java/com/ctrip/framework/apollo/common/utils/InputValidator.java

至于Apollo ConfigServer如何处理带有无效appid的请求，我在仓库中没有找到答案，但答案可能在其他地方可用，或者我可能错过了。如果你有更多的信息或者上下文，我可能能够提供更具体的答案。

Sources

• apollo-common/src/main/java/com/ctrip/framework/apollo/common/utils/InputValidator.java

---

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[nobodyiam]

能展开讲讲你对 BloomFilter 的设计考虑吗？

[youngzil]

能展开讲讲你对 BloomFilter 的设计考虑吗？

提出这个疑问的原因是

1. 启动的时候，如果客户端传入的appid是一个不存在的appid，/notifications/v2请求返回304，此时对于业务来说只能算是 Not Modified status，而不是异常，客户端也是如此处理
2. 后续就是常规的 /notifications/v2 + 5分钟的全量同步，这个就会一直存在304和404的请求，服务端也需要部分处理，对于服务端来说也是一种资源浪费
3. BloomFilter 直接加载全量appid（后续可以定时同步增量或全量），直接过滤此种请求，异常告到客户端，后续不会再继续监听和5分钟全量同步之类的请求

[nobodyiam]

这个在设计上的考虑是比如某个应用上线前忘了发布配置，那么虽然启动时拿不到配置（fallback 默认配置），不过后续只要在 apollo 上创建并发布了配置，应用不需要重启即可获取到最新的配置

[youngzil]

这个在设计上的考虑是比如某个应用上线前忘了发布配置，那么虽然启动时拿不到配置（fallback 默认配置），不过后续只要在 apollo 上创建并发布了配置，应用不需要重启即可获取到最新的配置

这个理解是合理的，我提的这个是针对的不存在appid，永远不会成功拉取配置

[nobodyiam]

是的，不过不存在的 appid 其实也比较难判断确实是写错了（永远都不存在），还是在 apollo 上遗漏配置了（后续会出现）。
另外，还有一种场景是对于公共的 namespace，哪怕是在 apollo 中不存在的 appid 也应该能拉取到配置的。

[youngzil]

1、不过不存在的 appid 其实也比较难判断确实是写错了（永远都不存在），还是在 apollo 上遗漏配置了（后续会出现）。

哪怕只是在服务端遗漏配置的appid，服务在启动时候就Fail-fast 应该也是可以接受的

2、还有一种场景是对于公共的 namespace，哪怕是在 apollo 中不存在的 appid 也应该能拉取到配置的。

公共ns，除非是那种完全公开的，否则对于不存在的appid就可以拉取公共ns，也不是很好维护和跟踪，要求客户端一定有合法的appid，好像也可以说的过去

题外话：目前公司在推客户端开启APOLLO_ACCESSKEY_SECRET鉴权，对于这种不存在的appid + 公共ns，反而是一个不受控的因素

[nobodyiam]

可以在 ClientAuthenticationFilter 中增加 appid 检查逻辑，不过这个检查对存量系统会有影响，默认应该是关闭的。

[youngzil]

可以在 ClientAuthenticationFilter 中增加 appid 检查逻辑，不过这个检查对存量系统会有影响，默认应该是关闭的。

对的，存量的是会有这个问题，可以选择是否开启，或者在存量修复后开启（不好意思，这2天没关注，没有及时回复）

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had activity in the last 7 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.

[youngzil]

1、不过不存在的 appid 其实也比较难判断确实是写错了（永远都不存在），还是在 apollo 上遗漏配置了（后续会出现）。

哪怕只是在服务端遗漏配置的appid，服务在启动时候就Fail-fast 应该也是可以接受的

2、还有一种场景是对于公共的 namespace，哪怕是在 apollo 中不存在的 appid 也应该能拉取到配置的。

公共ns，除非是那种完全公开的，否则对于不存在的appid就可以拉取公共ns，也不是很好维护和跟踪，要求客户端一定有合法的appid，好像也可以说的过去

题外话：目前公司在推客户端开启APOLLO_ACCESSKEY_SECRET鉴权，对于这种不存在的appid + 公共ns，反而是一个不受控的因素

@nobodyiam 帮忙评估下此功能是否是需要的，对于Appid做一些前置校验，默认关闭（兼容之前的逻辑），可以通过开关打开，
一旦开启后，对于不存在的appid，是无法拿到公共的Namespace配置

[nobodyiam]

对于不存在的appid，是无法拿到公共的Namespace配置

对 apollo 而言其实比较难判断 appid 是否『不存在』，它只能判断在 apollo 中是否存在，没法判断实际是否存在，比如在公司的 cmdb 中。

[youngzil]

目前的需求是补足Apollo鉴权的功能，能在Apollo内部完成闭环，否则对于公共NS的鉴权是一个缺失，否则会产生对于一个Apollo中不存在的appid 可以拉取任意公共namespace的配置，Apollo中存在的Appid反而需要鉴权的一个尴尬场景

对于不在Apollo中的Appid确需要拉取Apollo的公共NS的场景，比如cmdb等场景，我理解应该是个性化需求，毕竟各个公司基础数据的管理和对外交互都不一样，可以通过设计上允许使用者自定义实现对Appid的判断逻辑比较合理

[nobodyiam]

否则会产生对于一个Apollo中不存在的appid 可以拉取任意公共namespace的配置，Apollo中存在的Appid反而需要鉴权的一个尴尬场景

其实初始增加 appid 鉴权的场景主要是为了解决私有配置的获取权限问题，公共 namespace 目前在页面上也是没有权限控制的，所以对这个场景增加鉴权我觉得意义不大