John Niang

/kind feature

> 你好，请问有任何办法通过改源码的方式使用子路径吗？ 目前暂时未测试过。如果有社区用户对这个问题感兴趣，欢迎提交 PR。

可以的。不过可以考虑自定义 actuator endpoint 来实现。

> 感觉有点不妥当，`actuator`接口一般都用来做内部系统间通讯了，有可能出现鉴权体系跟本系统管理后台不同的情况，比如当在`kubernetes`环境下拿来给 `k8s` 用了，这时候没有鉴权，如果管理后台也用了这个 `actuator` 接口，那就成了一个开放接口，暴露系统信息在安全层面不太妥当。有没有更好的方案可以搞定？可否考虑新开一个系统管理员级别的接口出来如 `/api/system/probe` 这种呢？ 我们可以试着扩展 actuator endpoint 来实现获取系统信息的逻辑。该接口期望匿名用户也能够访问到。

目前开发环境已经暴露 info 端口，请看下面的结果： ```bash curl -s http://172.19.144.1:8090/actuator/info | jq . ``` ```json { "build": { "artifact": "halo", "name": "halo", "time": "2023-01-16T03:48:34.919Z", "version": "2.2.0-SNAPSHOT", "group": "run.halo.app" } } ``` 以上信息需要允许匿名用户查看么？

> 感觉有点不妥当，`actuator`接口一般都用来做内部系统间通讯了，有可能出现鉴权体系跟本系统管理后台不同的情况，比如当在`kubernetes`环境下拿来给 `k8s` 用了，这时候没有鉴权，如果管理后台也用了这个 `actuator` 接口，那就成了一个开放接口，暴露系统信息在安全层面不太妥当。有没有更好的方案可以搞定？可否考虑新开一个系统管理员级别的接口出来如 `/api/system/probe` 这种呢？ @minliacom 直接暴露 /actuator/info 确实存在安全性问题。我计划的实现方案如下： - 扩展 Actuator Endpoint：`/actuator/globalconfig`，返回结果仅包含一些关于 Halo 的系统级别配置，例如是否允许注册，是否允许评论。 - 允许 `/actuator/health` 匿名访问。主要是为了方便 Kubernetes Probe 配置。 - 其他 Actuator Endpoints 仅允许管理员访问。

/assign

评论时本来是可以填写名称和邮箱，后面增加了匿名评论后，该功能可能被隐藏了。此前已经有相关的讨论了：。

IMO，可以直接移除该选项。主题详情页面是有启用主题的功能的，这里若是再包含”启用“选项，显得有些多余。

/kind feature