Discourse 中的只读模式

[Discourse]

本指南介绍了 Discourse 中可用的各种只读模式，如何启用和禁用它们，以及您可能希望使用每种模式的场景。

所需用户级别：管理员

在 Discourse 上管理一个充满活力的在线社区，偶尔需要管理员暂时限制用户活动。这些情况可能包括执行服务器维护、促进备份或迁移服务器。在此期间，至关重要的是限制论坛活动，同时不完全关闭用户访问。

Discourse 提供了多种只读模式，管理员可以启用这些模式以暂时冻结网站内的各种类型的交互。

本指南将探讨这些模式，特别关注如何启用和禁用它们，包括处理某些模式相互重叠的情况。

理解只读模式

Discourse 支持两种不同级别的只读模式，以满足各种管理需求。它们分别是：

1. 完全只读模式

• 限制论坛中的所有写入操作，防止任何用户创建或修改内容，例如发帖、评论或点赞。
• 允许论坛基本上“冻结”在当前的状态，使用户仍然可以阅读和浏览现有内容，而不会影响数据库。
• 禁止更改任何管理员站点设置或站点自定义，以保存数据库的当前状态。
• 禁用普通用户的新论坛登录。管理员仍可使用管理员电子邮件登录流程（/u/admin-login）登录。
• API 调用可以读取（GET），但不能写入（POST/PUT/DELETE）。
• 排队的出站 Webhook 将被传递，但由于触发它们的动作将被阻止，因此不会触发新的 Webhook。
• 入站 Webhook（邮件退信）将被阻止并返回 503 响应。邮件提供商将根据其自身的退避计划重试。

2. 仅工作人员可写模式

• 限制普通用户在论坛中的写入操作，例如发帖、评论或点赞。非工作人员用户仅限于只读操作，但仍可登录其账户。
• 允许管理员和版主的活动正常进行。管理员可以更改站点设置，工作人员用户可以执行写入操作，如发帖、点赞或修改个人资料。
• API 调用可以读取（GET）。仅工作人员 API 密钥可以写入（POST/PUT/DELETE）。
• 排队的出站 Webhook 将被传递。工作人员的操作可以触发新的出站 Webhook，这些操作也会成功，但非工作人员用户的操作不会触发 Webhook。
• 入站 Webhook（邮件退信）将被阻止并返回 503 响应。邮件提供商将根据其自身的退避计划重试。

这些模式确保了在关键管理期间管理论坛可操作性的灵活性。

如何启用/禁用只读模式

管理员应仔细管理不同只读模式之间的过渡。在启用任何只读模式之前，请确保已禁用之前启用的任何模式。

完全只读模式

通过 Rails 控制台

如果您可以访问 Discourse 安装，请在通过 ./launcher enter app 进入 Docker 容器后，使用 Discourse 的 Rails 命令行界面执行以下命令，然后通过 rails c 进入 Rails 控制台：

Discourse.enable_readonly_mode(Discourse::USER_READONLY_MODE_KEY)

通过管理面板

如果您可以通过 Web 界面进行管理员访问，可以导航到 Admin > Backups > Enable Read-Only Mode 来启用只读模式。

要禁用只读模式，请执行以下 Rails 命令：

Discourse.disable_readonly_mode(Discourse::USER_READONLY_MODE_KEY)

或者，使用管理面板，导航到 Admin > Backups > Disable Read-Only Mode。

仅工作人员可写模式

仅工作人员可写模式只能通过 Discourse Rails 控制台启用/禁用。如果您的网站由 Discourse 托管，并且您希望启用或禁用此模式，请联系 team@discourse.org。

要启用仅工作人员可写模式，请使用以下 Rails 控制台命令：

Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY)

要禁用：

Discourse.disable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY)

最佳实践

• 及时沟通：提前通知社区计划的只读时段，以设定适当的期望。
• 测试：在关键操作期间实施这些模式之前，请在低流量时段进行测试，以了解其影响。
• 文档记录：详细记录每次启用或禁用模式的时间和原因，以协助未来的运营规划。

常见问题解答

• 启用/禁用只读模式需要多长时间？

  • 更改是立即生效的。但是，用户体验可能会因过渡期间的操作而略有不同。

• 救命！由于只读模式，我被锁定了我的网站——我怎样才能再次访问我的网站？

  • 请参阅：使用只读模式或无效的 SSO 配置将自己锁定后，以管理员身份重新登录

• 我注意到 discourse/lib/discourse.rb 中列出了其他 READ-ONLY 模式，这些模式的作用是什么？

  • READONLY_MODE_KEY 主要用于备份和恢复过程，并由应用程序本身触发。此模式也可以通过 Discourse 命令行界面使用 discourse enable_readonly 和 discourse disable_readonly 启用或禁用。但是，此密钥在容器重启后不会保留。
  • USER_READONLY_MODE_KEY 用于管理员在管理界面中点击只读按钮时。此密钥的特殊之处在于，我们不会将其设置为过期密钥，因为用户启用的只读模式需要在容器重启后仍然有效。其他密钥设置了 TTL（READONLY_MODE_KEY 为 60 秒，PG_READONLY_MODE_KEY 为 300 秒），并且我们有一个线程每 30 秒延长一次过期时间，以确保应用程序永远不会卡在只读模式中。
  • PG_READONLY_MODE_KEY 和 PG_FORCE_READONLY_MODE_KEY 用于 PG 故障转移。前者设置为过期密钥，而后者为非过期密钥。

[Ed_S]

@SaraDev

2. 用户只读模式

• 限制普通用户执行写操作，例如发帖、点赞或修改个人资料。
• 允许管理员和版主活动正常进行。

3. 仅限员工写入模式

• 仅允许员工（管理员和版主）向论坛写入。
• 普通用户仅限于读取操作。

我看不出有什么区别！如果确实有区别，这些描述可以相应地调整一下吗？

[SaraDev (Sara Devlaeminck)]

@Ed_S

我看不出有什么区别！如果确实有区别，能否相应地调整这些描述？

我已更新指南以提供更多说明，如果您对任何只读模式仍有疑问，请告知我们。

[pfaffman (Jay Pfaffman)]

但是 discourse enable_readonly
有什么作用？

script/discourse

它使用了 READONLY_MODE_KEY，它将 ttl 设置为 60，因此它会在某个时候关闭。现在我看到

@SaraDev

也可以使用 discourse enable_readonly 和 discourse disable_readonly 命令从 Discourse 命令行界面启用或禁用此模式。但是，此密钥在容器重启后将失效。

这个命令有默认行为的原因是什么？即使被坑了几次，我也花了将近十年才了解到这个命令与 Web 界面的只读模式完全不同。我现在还记得有人曾经试图告诉我关于这些密钥的事情，但我没能理解它们的意义。
在我看来，discourse enable_readonly 更明智的做法是执行 Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY)。真希望我多年前就注意到了！
我能提交一个类似这样的 PR 吗？

  desc "enable_readonly", "启用只读模式，允许管理员写入"
  def staff_writes_only
    load_rails

    Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY)
    puts '站点现在处于只读模式，允许管理员写入。'
  end

[pmusaraj (Penar Musaraj)]

@pfaffman

IMHO，discourse enable_readonly 更明智的做法是执行 Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY)。真希望我早些年就注意到这一点！

我对这个不太熟悉，但我觉得让 enable_readonly_mode 将站点设置为 staff_writes_only_mode 会令人困惑。它们是不同的模式，在执行某些操作时，您会希望不允许员工写入数据库（例如，在恢复期间，他们将被移除）。

也许我们可以在这里做一些其他事情：

1. 澄清只读模式在该任务的描述中设置了 TTL
2. 添加一个调用 keep_readonly_mode 的任务，以便它可以扩展到 60 分钟以上
3. 添加 enable_staff_writes_only 和 disable_staff_writes_only 任务

[pfaffman (Jay Pfaffman)]

@pmusaraj

我对这个不太熟悉，但我认为 enable_readonly_mode 将站点设置为 staff_writes_only_mode 会令人困惑。

我同意，但这比“暂时设置为只读模式”要不那么令人困惑。

@pmusaraj

你希望管理员不能写入数据库（例如，在恢复期间，他们将被移除）。

我很确定恢复脚本本身会设置只读模式，所以它不受此命令的影响。

@pmusaraj

• 澄清只读模式在任务描述中设置了 TTL

我宁愿它在设置时声明它是为 X 分钟设置的。描述并不容易找到。

@pmusaraj

• 添加一个调用 keep_readonly_mode 的任务，以便它可以扩展到超过 60 分钟

也许吧。我不清楚谁会使用它。

@pmusaraj

1. 添加 enable_staff_writes_only 和 disable_staff_writes_only 任务

那太好了！

此外，我们需要清楚我们没有将 rake 任务与 discourse 命令提供的命令混淆。

[pmusaraj (Penar Musaraj)]

@pfaffman

我宁愿它在设置时就声明它已设置为 X 分钟。要找到这个描述并不容易。

说得有道理。您有机会为此提交一个 PR 吗？如果可能的话，enable_staff_writes_only 和 disable_staff_writes_only 命令也一样。谢谢！

[Ethsim2 (Ethan)]

我想知道哪些时钟会在启动只读模式后停止？设置只读模式后会发生主题顶起（topic bumps）吗？

[Ethsim2 (Ethan)]

看起来如果通过 Web UI 设置了只读模式，更新也无法工作

[Lucian_Chung]

看起来 UI 已更新，我在“管理员备份”部分看不到禁用只读模式的选项。如何通过 UI 禁用此功能？

[NateDhaliwal]

这有点奇怪。我看到“启用”和“禁用”按钮，它们工作正常。您能发送一张您看到的截图吗？

[southpaw]

你好 @Lucian_Chung，

请同时说明您的网站是自建托管还是由 Discourse 托管。如果是后者，请指明具体方案。在某些情况下，托管网站无法通过界面禁用只读模式。