Decap CMS接入Gitee简单方案

Sun, 05 Apr 2026 20:04:00 +0800

decap cms不支持gitee的api

gitee也不支持oauth pkce拓展，在不动代码的情况下是不可能直接使用的。

第一步，decap cms编译

gitee地址 decap-cms

github地址 decap-cms

该项目实现了gitee的发布文章API, gitee的oauth2流程。

代码由ai编写，人工测试，目前已测试登录发布文章相关功能。

使用npm run build 完成编译。

在 packages/decap-cms/dist中可以找到编译后的decap-cms.js

第二步，decap cms配置

Decap CMS 配置

  backend:
  name: gitee
  repo: <USER>/<REPO>
  branch: master
  base_url: https://<YOUR_PROXY_HOST>/gitee-proxy/
  api_root: https://gitee.com/api/v5
  auth_type: pkce
  app_id: <YOUR_APP_ID>

index.html引用新生成的decap-cms.js

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta name="robots" content="noindex" />
    <title>Blog Manage</title>
  </head>
  <body>
    <script src="decap-cms.js"></script>
  </body>
</html>

第三步，OAuth2的处理

OAuth应用的创建官方已经有详尽文档 gitee oauth 文档

权限至少要选择： user_info projects pull_requests

目前gitee不支持pkce, 仅支持授权码模式， decap-cms走pkce流程不通。

但pkce本质是授权码模式的拓展，oauth前几步包含了授权码模式的所有参数，只不过换token时需要client secret.

因此这里做了一个简单的代理，核心逻辑就是调用 oauth/token这一步时，将client secret一并送到gitee。

首先修改secret=“YOUR_CLIENT_SECRET”,填写自己的client secret.

使用 `/PATH/TO/GOBIN/go run tool/main.go` 运行代理服务

最后，创建一个入口nginx反向代理

decap cms的配置中，base_url 指向该nginx代理服务

 location /gitee-proxy/ {
    proxy_pass http://127.0.0.1:5000/;
    proxy_set_header Host gitee.com;

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

完成这些后，即可运行

运行后，点击 login with gitee，即可跳转进gitee登录，登陆后回调到你的decap cms地址即可完成授权。

授权后，会进入后台页面，你可以编写文章、上传图片资源等。

再次强调，decap cms的config中base_url是你的nginx代理地址, oauth会通过base_url进行。

未尽事宜

目前流程中，/gitee-proxy/oauth/token接口无论何种请求，都会带上client secret, 可能存在安全隐患。

任何人都可以通过前端拿到你的client key, 调用/gitee-proxy/oauth/token自动添加了client secret，等于说对任何人来讲，只需要一个授权码就可以拿到你的access token。

不过换授权码这一步需要gitee登录，整个流程还有这一层保护。

Use at your own risk

hugo整合CMS时区设置方案

Wed, 01 Apr 2026 23:25:00 +0800

问题

在hugo与Decap CMS / Sveltia CMS整合过程中，经常post无法生成的问题。

一般情况下，这个是由于时区引起的。 Decap CMS 中，对于时间格式，有一个picker_utc 参数，表示是否使用UTC时间

如果不设定，则使用本地时间，生成的时间内没有时区标识。

如果设定为true, 则生成的时间里面带一个Z, 比如2026-04-01T17:44:00Z，表示此时间为UTC时区

理论上这里设计没有什么问题，但是对于hugo来讲，无论带Z与否，经过实测，都会按照UTC解析。这样一来，北京时间2026-04-01 17:44:00 就变成了UTC时间2026-04-01 17:44:00，这在此时是一个未来的时间，默认情况下，无法生成未来的post。

解决方案：在Decap/Sveltia CMS中的时间串中增加明确的时区标识，举例：

`1`	`- { label: "日期", name: "date", widget: "datetime", format: "YYYY-MM-DDTHH:mm:ss.SSS+08:00"}`

picker_utc默认false, 取的是本地时间（北京时间），我们通过format强制增加了东八区标识，这样hugo不会再误认为是UTC。经测试，该格式可以由hugo正常识别。

手工维护markdown文档也可以使用类似方法。

（当然，也可以开启picker_utc，整个blog全部使用UTC，理论上也没有问题，post可以正常发布。就是时间显示成UTC对于我们并不友好，还是推荐使用format）

码农成长随笔