兼容typecho1.2.x，新增几个接口 #29
Conversation
新增接口：用户列表、发表文章、新增分类/标签 新增apiToken校验
Action.php
Outdated
| @@ -194,6 +201,10 @@ private function checkState($route) | |||
| if (!$state) { | |||
| $this->throwError('This API has been disabled.', 403); | |||
| } | |||
| $token = $this->request->getHeader('token'); | |||
| if ($token != $this->config->apiToken) { | |||
README.md
Outdated
| @@ -8,6 +8,11 @@ | |||
| 这是一个将 Typecho 博客 RESTful 化的插件。启用此插件，你可以通过请求 API 向站点请求或写入信息（获取文章内容、获取评论、添加评论等）。 | |||
|
|
|||
| ------ | |||
| 2025-04-18 | |||
There was a problem hiding this comment.
不要把 CHNAGELOG 放在 README 中，可单开一个 CHANGELOG.md，参考 https://github.com/standard/standard/blob/master/CHANGELOG.md
| @@ -551,19 +563,20 @@ public function commentAction() | |||
| $this->lockMethod('post'); | |||
| $this->checkState('comment'); | |||
|
|
|||
| $comments = new Comments($this->request, $this->response); | |||
There was a problem hiding this comment.
对发表评论接口的改动比较多，需要确认：
- 是否做了鉴权
- 是否引入 breaking change，在 typecho 1.1 以前版本是否可用
| /** | ||
| * 发表文章 | ||
| */ | ||
| public function postArticleAction() |
|
新增/修改接口，辛苦补充和修改相应单元测试 |
|
另外当前版本与 PHP 7.4 不兼容的点可以展开描述一下吗，从 diff 中没有看出兼容 7.4 的代码 |
|
@kirainmoe |
没有兼容php7.4的部分，标题我改一下 |
能否不引入 breaking change，不破坏 1.2 以前的可用性（如通过判断版本号的方式）？如果必须引入 breaking change，需要在 CHANGELOG 和 README 说明。
评论接口原先是会使用当前登录用户的 session 模拟请求的，当前改为直接写库，是否有伪造身份的可能。 另外我理解 apiToken 是一个全局的设置，会应用到所有的接口？如果发布文章类似的高敏接口也使用 apiToken 来鉴权，会导致权限管控不精细。 |
|
rebase 一下 master，跑一下 GitHub Actions 的单测 CI 吧，travis 年久失修已经不可用了。 |
发表评论/发表文章/新增分类接口增加校验csrfToken、 文章详情不返回csrfToken、 单元测试修改
必须引入 breaking change，已在 CHANGELOG 和 README 说明。 |
发表评论/发表文章/新增分类接口已增加校验csrfToken、文章详情不返回token，csrfToken使用单独接口获取 |
单元测试目前跑不通，看着是服务器启动问题、目前手头没有linux环境，等我回家跑跑看 |
|
@kirainmoe 单元测试已更改，可以看看还有那里要修改的 |
|
review 了一下追加的 commit，感觉你改动的思路有一些问题。apiToken 不应该强制要求用户设置，获取信息的 GET 接口并不需要强制设置依赖 api token，你的改动里强制了用户所有接口都需要设置 api token 否则抛错，已经脱离了具体的使用场景了。你可以考虑一下这些接口的使用场景：GET 类的接口例如获取文章列表、tag 等，是用于主题等获取站点信息暴露的，这类场景不需要 token 鉴权。#24 的问题可以通过修改 web server 层面如 nginx 给特定的路由添加鉴权或限流来解决，不一定需要插件来解决。 而写数据的接口鉴权和验证 CSRF Token 是两码事，CSRF 主要是为了防范跨站请求，而这里的问题主要是接口的鉴权粒度上。
这两个场景的鉴权粒度是不同的，不应该单纯通过一个 apiToken 来控制。 |
|
建议：
|
好的，了解了，我原先预想的插件功能就是提供接口，让第三方可以自由操作数据，我稍后修改一下 |
发布文章、新增标签/分类接口修改 增加可选校验高敏接口设置
发布评论恢复原来逻辑 |
修复接口：获取标签、发表评论（传参有修改）#26
新增接口：用户列表、发表文章、新增分类/标签#21
新增apiToken校验#24