John Niang

> 用了latest版本访问，无论是mysql和h2版，当数据量级达到1w左右的时候，查询非常慢，单个文章的查询基本在5-6s加载完成。排查中导出数据到mysql，单个查询，速度并不慢【20-100ms】，我跟踪代码进去，单个文章的关联查询多，还会查询上一篇和下一篇的文章。每一个查询递归 加起来，确实非常慢 【10106.wang】 感谢问题的排查。性能优化问题将会是 1.5.x 的重点。

/reopen 这个问题还没有彻底根治，所以我重新打开它。

> 目前不是已经有 IP 限制了吗？？当恶意用户使用代理池、肉鸡进行攻击时，IP 限制应该是无效的。对于 User-Agent 也可以进行伪造。。感觉合适的方式就是接口次数过多以后执行验证码，但这样必定会影响到所有的主题。。 - 目前还无法拉黑 IP 地址或者 CIDR 地址； - 验证码模式倒是可以考虑，不然现在就是在裸奔，但确实会影响到所有评论插件。

@GalvinGao 可以参考一下 Spring Cloud Gateway 的思路来设计过滤器，我们尽可能多地提供过滤器实现，规则由使用者自定义即可。

系统默认配置建议不做任何变更，即使变更了也会被重置。建议系统默认配置 ConfigMap name 设置为 system-default。如果用户需要修改系统配置，则新创建一个名为 system 的 ConfigMap 来存储用户自定义配置。系统最终配置为用户自定义配置 Merge Patch 系统默认配置的结果。

目前可优先考虑采用 https://github.com/java-json-tools/json-patch 作为 JSON Patch 的库，用于合并 ConfigMap 的值，理由如下： 1. 它默认集成了 Jackson JSON 2. 它同时支持 [JSON Patch](https://www.rfc-editor.org/rfc/rfc6902) 和 [JSON Merge Patch](https://www.rfc-editor.org/rfc/rfc7386)

## 关于 Halo API Scope 的讨论 > 这里主要参考 GitLab Access Token Scope 做法：. ### Admin API - api：对所有 API 都有读写权限 - read_api： - attachment_api - read_attachment - backup_api - read_backup...

/assign

> 是否可以根据 crud 来做 scope，比如： > > admin api: > > * PostController > > * read > * write > * delete > * update 这样的 Scope 会不会太细了呢。或者说定义成这样有什么明显的好处么？

For the first implementation, we will only provide access token generation, distinguish between content APIs and admin APIs, and have no read and write scope set.