让muse帮我在cloudflare.com平台搭建基于D1+R2的博客程序rin

(博客的登录地址：https://rin-server.luckypoem.workers.dev/login)

我用email id: luckypoem@gmail.com登录了cloudflare.com平台。

以下是我跟muse的对话内容：

我： can u build https://github.com/brightmann/rin?

 Rin 是个全栈博客（React 前端 + Workers 后端 + D1 数据库 + R2 存图），不是静态站，得建数据库和存储，我来搭。先装依赖验证构建。

 在搭建中。刚克隆完，正在装依赖，验证构建，同时在申请部署用的 Cloudflare token。装好就部署，好了跟你说。

 构建通过了。前端已经编出来了，正在等部署用的 Cloudflare token，拿到就部署（会建数据库）

 构建好了，但卡在部署 token 上：Cloudflare 后台登录一直过不了验证，登录页显示“验证有问题”，输完密码到两步验证那步就卡住了，token 没建出来。你自己在浏览器里打开 dash.cloudflare.com，进 My Profile → API Tokens → Create Token，选 "Edit Cloudflare Workers" 模板，名字填 rin-deploy-onetime，建好把值贴给我，我用完就删。

构建已经好了，拿到 token 就能部署。

点模板卡片上的 Use template 按钮，进下一页，最上面就是 Token name，填 rin-deploy-onetime。权限不用改，直接往下点 Continue to summary → Create Token。

如果已经点了 Use template 还是没看到名字框，页面往上滚一下，它在最顶上。

 你进 My Profile → API Tokens->点击‘create token'按钮->在Token name的下一行的空白栏里，给该token取个名字->点击’start from scratch Custom'->选择start with an account policy->点击developer platform->把Cloudflare Pages, D1, Queues, Workers KV storage, Workers R2 Storage, Workers Scripts都选择Edit权限->点击页面底部的continue to summary->点击页面底部的‘create token'按钮, 跳转到的页面里就会显示所生成的API token的值。把该token的值复制粘贴在这里。

me:  the API token's value...

上线了- https://rin-server.luckypoem.workers.dev

数据库D1、存储桶R2、迁移都好了，登录页也能打开。管理员账号：

• 用户名：admin
• 密码：muse设置的密码

用这个登录就能发文章。两个一次性 token 用完了，可以删掉。

我： 你是如何创建管理员账号的？

没单独建账号，是部署时把用户名和密码写进了 Worker 的 Secrets，第一次登录时自动创建库里的管理员。

具体是这样-

• 部署时我设了 ADMIN_USERNAME=admin 和一个随机密码，通过 wrangler secret bulk 同步成 Worker 的 Secret（不在数据库里）。
• 你第一次用 admin + 那个密码登录时，服务端拿你输的密码跟 Secret 里的比对，比对通过后才在 D1 里自动创建管理员用户（openid 是 admin，权限 1），然后发 JWT 给你。
• 所以密码本身只存在 Worker Secret 和我给你的那条消息里，数据库里存的是哈希。

以后想改密码，改 Worker 的 ADMIN_PASSWORD 这个 Secret 再重新部署就行。

我： 在哪里改 Worker 的 ADMIN_PASSWORD？

在 Cloudflare 后台：Workers & Pages → 点 rin-server → Settings → Variables，在 Secrets 那栏找到 ADMIN_PASSWORD，点编辑，改成新密码保存就行。

改完下次登录就用新密码，不用重新部署代码。

我： https://rin-server.luckypoem.workers.dev/feed/1 怎么不能渲染iframe code?

找到原因了：你这篇《战马》的内容存进数据库时，iframe 被包在了一对 ``` 代码块标记里。Markdown 渲染器就把它当成代码文本显示，不会当成真正的视频。

我已经把数据库里那两个 ``` 标记去掉了，现在内容就是裸的 iframe 代码。Rin 前端用的渲染器是支持原生 HTML 的，理论上该显示视频播放器了。

查到了，Error 153 是 YouTube 从去年底开始收紧了：嵌入播放器必须能通过 Referer 认出是哪个网站嵌的它，认不出就拒绝播放。Rin 的页面没声明 referrer 策略，浏览器就没把来源发给 YouTube。

（我：cwb是基于d1+r2吗

不是。cwb 用的是 KV 存数据（一个叫 cwb 的 KV 命名空间，绑定名 CFBLOG），没有使用 D1 也没有使用 R2。

rin 才是 D1（数据库）+ R2（存图）那套。cwb 是 2020 年的老架构，单文件 Worker + KV，文章、分类、标签全存在 KV 里。

我： KV也是一种数据库吗？

是，KV 也是一种数据库，不过是键值（Key-Value）型的 NoSQL。

跟 D1、R2 的区别：

• KV：按 key 存取，像个大字典。key 是名字，value 是一段内容（比如一篇文章的 JSON）。查起来快，但只能按 key 取，不能像 SQL 那样按条件查、排序、关联。
• D1：关系型数据库（SQLite），有表、SQL 查询，适合结构化数据。
• R2：对象存储空间，存文件（图片、视频等），不是数据库。

cwb 就是用 KV 存文章的：每篇文章一个 key，内容是 JSON；再加几个 key 存文章列表、标签这些。简单够用，但查起来不如 D1 灵活。）

 我：error 153 代表什么？我从没看到这样的提示。

Error 153 是 YouTube 的一个报错，意思是播放器认不出是哪个网站在嵌它。

YouTube 嵌视频时，播放器要看浏览器发过去的 Referer（就是“这个视频是从哪个网页上嵌过来的”）来确认能不能放。如果 Referer 是空的、被拦了，YouTube 就不知道是谁在嵌，直接拒绝播放，显示 Error 153。

你以前没见过，是因为你别的站（比如 cwb）Referer 都是正常发过去的，YouTube 能认出来，所以能放。视频本身也没问题，同一个视频在 cwb 上就能放。是 Rin 这个站发给 YouTube 的信息不对。

 我刚把 Rin 上我之前加的 Referrer 策略全去掉了，现在跟 cwb 一模一样（什么策略都不发）。

 如果这个静态页能放，说明问题出在 Rin 的 React 渲染方式上，我再从渲染那边想办法

找到根了。Rin 的Markdown渲染器里，iframe 是写死的 referrerPolicy="no-referrer"，意思就是告诉浏览器“加载这个 iframe 时别发 Referer”。YouTube 收不到 Referer，认不出是哪个网站在嵌入它的代码，就报 Error 153。

把这两个写死的东西去掉了，现在 iframe 就用你文章里本身带的 referrerpolicy="strict-origin-when-cross-origin"，跟 cwb的情形 一模一样。

 我：https://rin-server.luckypoem.workers.dev/feed/1 也能显示视频了

 对，修的是渲染器那层，两个域名走的都是同一套代码，所以 workers.dev 那个也一起好了。现在 rin.mingsea.net 和 rin-server.luckypoem.workers.dev 都能正常播放视频。

 我：如果我嵌入另一个视频的代码，是直接帖在editor box里吗？

对，直接贴在编辑框里就行，但注意：要贴成普通段落，别贴进代码块里或inline code里。

你第一篇就是因为 iframe 被包进了 ``` 代码块，才显示成文字而不是播放器。

me: 也不要贴在inline code里？

对，inline code 也不行。` 这种单反引号包起来也会显示成代码文字，不会变成播放器。

就直接贴成普通段落，什么反引号都别加.

me:  https://rin-server.luckypoem.workers.dev/feed/3 怎么没在网页的最上面？他是最新的帖子.

查了，列表本身就是按最新在前的，顺序没错。

• 《稀奇古怪的中国经济》(feed/2)：今天 00:32 发的，最新，所以在最上面
• 《人在旅途》(feed/3)：昨天 22:56 发的，排第二
• 《战马》(feed/1)：昨天 22:43 发的，排在最下面。

你说的 feed/3 其实不是最新的，feed/2 比它晚发了一个半小时，所以 feed/2 在最上面，feed/3 在第二位。这个排序是对的。

我： 但是怎么feed/2, feed/3的数字怎么解释？

这个数字就是数据库里的序号，按你点“新建文章”的先后给的，1、2、3 这样排下去。它只代表创建的顺序，不决定首页怎么排。

首页是按发布时间排的，最新发的在最上面，跟这个序号没关系。所以序号大的不一定在上面，关键看发布时间。

你这三篇就是：feed/2 是 00:32 发的最新，feed/3 是 22:56 发的，feed/1 是 22:43 发的最早，所以首页从上到下是 2、3、1。

我： Can u make the blog support pagination?

Done. The blog now has numbered pagination: Previous | 1 | 2 | … | N | Next, 5 posts per page, using ?page=N URLs.

One thing: it's hidden when there's only one page. You have 4 posts right now, so everything fits on page 1 and you won't see the pager yet. Once you publish a 6th post, the pager will appear at the bottom of the homepage.

rin 有三个修好的地方还在muse的本地，没进 GitHub。

• 视频 Error 153 的修复（markdown.tsx）
• 编号分页（feeds.tsx，5 篇一页）
• 部署 CLI 的 JSON 解析修复（两个文件）

哪天你从 GitHub 重新克隆或重建，视频会再次报 Error 153，分页也会消失。另外还有个 _headers 文件（调试时留下的），可推可不推，你定。

刚查过，GitHub 上游还是 9efc4fd，你没有新提交，推上去不会盖掉你的改动。贴一个 rin 专用的 token（只要 Contents 权限），就推上去。

me: my github pat here...

Pushed. The Error 153 fix, the numbered pagination, and the CLI fixes are now on your GitHub repo as commit 18569c0 — GitHub matches the live site.

I checked first: no new commits from you on upstream, so nothing of yours was overwritten. The _headers file I left out as you didn't mention it. The token you pasted can be revoked now.