用于通过私信发布匿名帖子或提供匿名反馈的插件

自定义 插件
1
:information_source: 摘要 提供两个独立的匿名发帖表单
:hammer_and_wrench: 仓库链接 GitHub - elRicharde/discourse-anonymous-feedback: Anonymous Feedback Formular in Discourse · GitHub
:open_book: 安装指南 如何在 Discourse 中安装插件

本 Discourse 插件提供两个独立的匿名发帖表单：“匿名反馈”和“白板”。两个表单均受“门码”（简单密码）保护，允许没有账户的用户向预配置的用户组发送私信，即使您的论坛通常要求登录，这两个表单也不需要。

从技术上讲，帖子通过网页提交，无需登录，甚至可以在隐私浏览标签页中使用。由于不记录 IP 地址，因此无法追溯发送者。本插件旨在为沟通提供一个安全且保密的渠道。

为什么要使用此插件？

在许多社区中，敏感话题或想法需要一个既能保证匿名性又能减少社会压力的反馈渠道。本插件解决了几个关键挑战：

  • 促进无拘无束的反馈：它为用户（甚至包括外部共享门码的非用户）提供了一个安全空间，让他们能够分享诚实、未经过滤的意见、担忧或创新想法，而无需担心受到评判或报复。这可能会带来原本可能被保留的更坦率、更有价值的输入。

  • 保密性与信任：通过技术手段（如基于 HMAC 的速率限制且不记录 IP 地址）确保匿名性，本插件建立了信任并鼓励更广泛的参与，特别是在处理敏感话题时。

  • 弥合沟通鸿沟：它为那些犹豫是否公开发帖或不拥有 Discourse 账户的个人创建了便捷的沟通桥梁，从而扩大了社区参与的覆盖面。

  • 结构化输入：通过将反馈定向到特定的私人组，确保敏感信息由适当的团队成员审阅，从而在公众视野之外进行聚焦讨论和行动。

  • 对非用户简单便捷：门码机制允许外部人员或临时访客提供输入，而无需进行完整的账户注册。

最终，本插件通过为关键讨论和建议创建一个更具包容性和安全性的环境，增强了社区互动。

工作原理（技术概述）

本插件的开发重点是匿名性和安全性。

  1. 访问：用户导航至 /anonymous-feedback 或 /white-board。

  2. 解锁：用户必须输入正确的门码。服务器会验证此代码。

    • 为防止暴力攻击，服务器使用基于用户 IP 地址 HMAC 哈希和轮换密钥的速率限制系统。IP 地址本身永远不会被存储。

    • 如果代码正确，服务器会在用户的会话中设置一个临时、一次性的标志。

  3. 提交：用户编写并发送消息。

  4. 创建私信：服务器检查会话标志。如果有效，它将创建一条新私信发送给配置的目标组，并以配置的机器人用户（或系统用户）身份发布。随后立即删除会话标志，因此用户发送任何后续消息时都必须再次输入门码。

示例用例 / 工作流程

本插件设计灵活。以下是您可以实施的两种常见工作流程：

用例 1：“白板”—— moderated 公共公告板

此用例旨在提高敏感话题或社区中观察到的不当行为（例如在活动期间或一般互动中）的可见性。例如，使性别歧视等问题可见。

目标：在不暴露举报者身份的情况下，使重要问题对社区可见。重点在于信息本身，而非发送者，甚至可能不涉及相关个人。即使不点名，仅对不当行为情境进行简单描述，也能提高可见性并提升意识。

工作流程：

  1. 提交：用户通过 /white-board 表单提交帖子。成员 (MG)、学徒 (ANW) 和协调员 (FM) 均可访问此表单。只有“Anonymous”用户可以创建帖子。

  2. 私人审阅：帖子作为私信发送到配置的目标组（例如， Moderation 团队或“信任与安全”委员会）。它将标识为“白板”条目。

  3. 审核：团队根据预定义标准（例如，无人身攻击、无侮辱、遵守社区指南）审查提交内容。

  4. 发布（如获批准）：邀请管理员查看该消息，将其转换为专用公共“白板”类别中的公开主题。该主题使用特定的通用账户（例如，通过 bot_username 设置配置的“WhiteBoardBot”或“Anonymous”用户）发布。该用户的登录凭据可以与审阅组共享。发布由“Anonymous”用户完成。

  5. 讨论控制：“白板”类别的权限设置为对成员/学徒/协调员可见但不可评论。常规论坛版主不应 Moderation 此特定区域；这完全是指定目标组的职责。关于白板是否应包含子类别（例如“匿名已关闭”或专门针对目标组帖子的类别）仍存在疑问。

  6. 处理拒绝：由于无法联系匿名发送者，最佳实践是在“白板”类别中置顶一个主题，说明发布标准以及提交内容可能被拒绝的原因。证明不予发布的规则应始终在论坛的一个位置公开。

用例 2：匿名反馈——直接、私密的渠道

此用例旨在为特定团队提供一条直接、保密的沟通渠道，用于任何形式的反馈（例如投票反馈或其他匿名建议）。

目标：为成员和非成员提供一种安全的方式，直接向领导层或相关委员会提供关于社区事务、投票或其他话题的反馈。

工作流程：

  1. 提交：用户通过 /anonymous-feedback 表单提交反馈。主题行有助于对消息进行分类。此帖子将以“匿名消息 - dd.mm.yyyy, hh:mm:ss”为前缀发送到目标组的集体收件箱。

  2. 私人投递：消息作为私信发送到目标组。通过主题前缀可将其识别为“匿名反馈”。随后，目标组决定如何处理该消息。

  3. 内部处理：团队随后可以私下讨论反馈，必要时邀请其他相关方参与，或决定行动方案。此反馈可能用于投票反馈或其他匿名建议。

  4. 处理不当反馈的最佳实践：如果提交内容不当，团队可以直接删除它。您可以考虑发布一条通用的公开通知（例如在“新闻”类别中），说明“收到的 [日期] 反馈因违反我们尊重交流的社区标准而未予处理。”这可以在不泄露任何细节的情况下告知发送者，并鼓励其以更建设性的方式重新提交。如果是针对白板的帖子（无特殊标记，或如有需要可添加后缀）：版主被邀请查看消息，但无人回复该消息。版主将消息转换为“白板”类别中的主题 → 对成员/学徒/协调员可见且不可评论。

功能

  • 两个独立端点：提供 /anonymous-feedback 和 /white-board，每个端点均有其独立的配置。

  • 门码保护：每个表单均受其专属秘密门码保护，以防止垃圾邮件。门码对所有人相同，页面也可在隐私模式或父母电脑上使用。

  • 可配置目标组：来自每个表单的消息作为私信发送到特定的、可配置的用户组。

  • 一次性会话：成功发送消息后，用户会被重定向回门码屏幕。他们必须再次输入代码才能发送另一条消息，从而防止简单的多帖垃圾邮件。发送后，您会回到门码页面，无法轻松进行多帖操作。

  • 保持匿名性的速率限制：在不记录 IP 地址的情况下，防止暴力攻击和垃圾邮件。

  • 机器人防护：包含一个隐藏的蜜罐字段以捕获简单机器人。

  • 自定义发送者用户：您可以为每个表单定义一个机器人用户，使私信看起来是由该用户发送的（例如“FeedbackBot”）。该用户必须存在。如果为空，则默认使用系统用户。

  • 简洁现代的界面：表单基于可重用的 Ember.js 组件，提供一致且简洁的用户体验。

安装

请遵循 Discourse 插件的标准安装指南：安装插件。

  1. 将插件的仓库 URL 添加到您的 app.yml 文件中：

    hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/elRicharde/discourse-anonymous-feedback

  2. 重新构建容器：cd /var/discourse && ./launcher rebuild app

配置

安装后，您可以在 Discourse 管理设置中配置插件。搜索“匿名反馈”。所有设置均针对“匿名反馈”和“白板”表单独立配置。

设置 描述
anonymous_feedback_enabled 切换 /anonymous-feedback 页面的开启或关闭。
white_board_enabled 切换 /white-board 页面的开启或关闭。
... door_code 用户必须输入的秘密密码以访问消息表单。
... target_group 接收私信的用户组名称。该组必须存在。
... rate_limit_per_hour 每小时可发送消息数量的全局限制，以防止滥用。设置为 0 以禁用。
... max_message_length 消息文本中允许的最大字符数。
... hmac_rotation_hours 速率限制密钥轮换的频率。较短的持续时间会更快重置暴力锁，但安全性略低。
... bot_username 可选。发送私信的用户名。该用户必须存在。如果为空，则使用系统用户。

开发 / 架构

  • 后端：单个 Ruby on Rails 控制器 AnonymousFeedbackController 处理两个端点的所有请求。它使用 kind 方法检查请求路径（/anonymous-feedback 与 /white-board）以确定使用哪些配置。这避免了代码重复。动态 setting 助手进一步简化了配置读取。

  • 前端：用户界面基于单个可重用的 Ember.js 组件 <AnonymousFeedbackForm />。

    • 该组件包含表单状态（解锁、发送、错误处理）的完整 HTML、CSS 和 JavaScript 逻辑。

    • 路由模板（anonymous-feedback.hbs 和 white-board.hbs）现在极其简单。它们仅实例化该组件并传递正确的参数（例如标题、API URL）。这种 DRY（Don’t Repeat Yourself）方法使前端代码简洁且易于维护。

深入探讨：匿名性与速率限制（HMAC）

本插件的核心功能是在绝对匿名性和防止滥用（垃圾邮件）之间取得平衡。

问题：有限的 IP 地址

IPv4 地址由有限数量的组合构成（约 43 亿个）。

  • 风险：哈希函数（如 SHA256）是不可逆的单向函数。然而，如果我们仅仅存储 SHA256(IP_Address)，攻击者（或管理员）可以在几秒钟内预先计算所有现有 IP 地址的哈希值（即“彩虹表”）。通过将存储的哈希值与其列表进行比较，他们可以直接揭示原始 IP。

解决方案：带轮换密钥的 HMAC

我们使用 HMAC（基于哈希的消息认证码）。这是在哈希之前将消息（IP）与加密密钥相结合。

  • 机制：标识符 = HMAC(IP_Address + Secret_Key)

  • 为何有效：即使攻击者知道所有可能的 IP 地址，他们也不知道 Secret_Key。没有这个密钥，他们就无法预先计算哈希值。由于缺少秘密变量，“彩虹表”攻击变得不可能。

前向保密（密钥轮换）

Secret_Key 会自动轮换（例如，每 4 小时）。

  • 场景：假设服务器被黑客入侵，攻击者窃取了当前的密钥和数据库。

  • 保护：由于密钥定期更改且旧密钥被永久丢弃，攻击者只能计算当前时间窗口（例如过去 4 小时）内的 IP 哈希值。昨天或上周的所有活动都是使用不再存在的密钥哈希的。这确保了前向保密性：即使当前系统遭到破坏，过去的匿名性也无法被打破。

快速与慢速轮换

您可以配置轮换间隔（hmac_rotation_hours）。

  • 快速轮换（例如 1 小时）：

    • 优点：最大匿名性。可以将不同操作链接到同一（未知）行为者的时间窗口非常短。

    • 缺点：速率限制的“记忆丢失”。当密钥轮换时，服务器会“忘记”谁已经发送了消息。在第一小时被阻止的垃圾邮件发送者在第二小时实际上会被解除阻止。

  • 慢速轮换（例如 24 小时）：

    • 优点：更强的防垃圾邮件保护，因为阻止持续时间更长。

    • 缺点：在此 24 小时窗口内，管理员可以看到“用户 X”发送了 5 条消息，即使他们不知道“用户 X”是谁（可关联性）。

建议：4 到 12 小时之间的值可提供坚实的平衡。

3 个赞