本指南解释了 Discourse 默认存储哪些个人身份信息 (PII)、存储位置、谁可以访问这些信息，以及如何通过使用 DiscourseConnect 来最小化 PII 的收集。
所需用户级别：管理员
Discourse 存储某些个人身份信息 (PII) 以支持核心功能，如内容审核、账户管理和用户身份验证。了解收集了哪些数据以及数据如何存储，有助于您就隐私和合规性做出明智的决策。
摘要
Discourse 存储多种类型的 PII，包括 IP 地址、电子邮件地址和社会登录凭证。这些信息主要用于内容审核、重复账户检测和用户身份验证。站点管理员可以通过实施 DiscourseConnect (SSO) 来最小化 PII 的存储，这允许您控制传递给 Discourse 的信息。
Discourse 存储哪些 PII？
IP 地址
Discourse 为每个用户存储以下 IP 地址，以协助您的审核团队检测重复账户：
- 注册 IP 地址 - 创建账户时使用的 IP 地址
- 最后使用的 IP 地址 - 用户访问站点时最近使用的 IP 地址
例如，如果您在上午 11:00 通过移动设备访问站点，然后在中午 12:00 通过平板电脑访问，则只有平板电脑的 IP 地址会被存储为“最后使用的”IP 地址。
谁可以访问 IP 地址
- 管理员 - 完全访问所有 IP 信息
- 版主 - 默认可以查看 IP 地址（可以通过
moderators_view_ips站点设置禁用） - 系统 - 在内部使用 IP 地址进行垃圾邮件检测和重复账户识别
电子邮件地址
电子邮件地址以纯文本形式存储在数据库中，任何拥有数据库访问权限的人都可以查看。这包括：
谁可以访问电子邮件地址
- 管理员 - 完全访问所有电子邮件地址
- 版主 - 默认无法查看电子邮件地址（可以通过
moderators_view_emails站点设置启用） - 数据库管理员 - 任何拥有直接数据库访问权限的人
全名（真实姓名）
Discourse 可以收集并存储用户的全名（也称为“真实姓名”），这与用户名是分开的。全名以纯文本形式与其他用户信息一起存储在数据库中。
如何收集全名
全名可以通过以下几种方式提供：
- 注册期间 - 用户可能在注册过程中输入全名（取决于配置）
- 通过 SSO/DiscourseConnect - 外部身份验证提供商可以在创建或更新用户时传递全名（
name字段），如果配置了覆盖，还可以覆盖本地名称。 - 通过个人资料编辑 - 用户可以从其个人资料偏好设置中添加或更新全名
- 来自社交登录 - 当用户通过社交提供商进行身份验证时，其显示名称通常被用作全名
谁可以访问全名
全名以纯文本形式存储在数据库 users 表的 name 列中，可以被以下人员访问：
- 管理员 - 完全访问所有全名
- 版主 - 默认可以查看全名（由与电子邮件访问相同的权限控制）
- 数据库管理员 - 任何拥有直接数据库访问权限的人。
- 公开用户 - 根据
enable_names和相关显示设置，可能会看到全名
配置选项
管理员可以使用以下站点设置控制全名的收集和显示方式：
-
full_name_requirement- 控制注册期间是否显示全名字段以及该字段是否为必填项 -
auth_overrides_name- 启用后，来自外部身份验证提供商（包括 SSO/DiscourseConnect 和社交登录）的名称不能被用户更改- 有助于在您的系统中保持身份的一致性
-
use_name_for_username_suggestions- 启用后，Discourse 将在注册期间使用全名来建议用户名 -
enable_names- 主开关，在用户的个人资料、用户卡片和电子邮件中显示用户的全名。禁用后将在所有地方隐藏全名- 默认：启用
以下显示设置仅在启用 enable_names 时生效：
display_name_on_posts- 在用户的帖子中显示其全名，同时显示其 @用户名prioritize_username_in_ux- 控制用户名或全名在界面中哪个更突出- 默认：启用（用户名优先）
display_name_on_email_from- 如果启用，则在电子邮件通知的“发件人”字段中使用全名。
Discourse 具有智能去重功能，如果用户的全名和用户名非常相似（忽略空格、下划线和大小写），则只会显示其中一个以避免冗余。您可以使用 Remove Name Suppression on Posts 主题组件禁用此行为，这将强制在帖子中始终同时显示全名和用户名。
联邦社交登录信息
当用户通过社交登录提供商（Google、Facebook、GitHub 等）进行身份验证时，Discourse 会存储各种信息：
- 电子邮件
- 提供商账户 ID
- 姓名
- 头像
- [此列表可能会根据提供商或随时间变化]
存储的具体数据取决于提供商及其共享的信息。
示例：Google OAuth2
当用户使用 Google 登录时，Discourse 会在数据库中保留以下信息：
provider_name: "google_oauth2",
provider_uid: "11791234567812345",
info: {
"name" => "Bilbo Baggins",
"email" => "bilbo.baggins@gmail.com",
"image" => "https://lh3.googleusercontent.com/a/ACg8ocJD5vR-JuZZ16mGf51uYH0KyKGoKXF36U3inbh4Bzne0CpuTlH23g=s96-c",
"last_name" => "Baggins",
"first_name" => "Bilbo",
"email_verified" => true,
"unverified_email" => "bilbo.baggins@gmail.com"
}
示例：Facebook OAuth
Facebook 登录的示例（已脱敏）显示：
provider_name: "facebook",
provider_uid: "123456789",
info: {
"name" => "Bilbo Baggins",
"email" => "bbaggins@shire.net",
"image" => "https://graph.facebook.com/v5.0/123456789/picture?access_token=swordfish&width=480&height=480",
"last_name" => "Baggins",
"first_name" => "Bilbo"
}
存储的具体字段可能会根据提供商或随着身份验证协议的演变而随时间变化。
谁可以访问社交登录信息
- 管理员 - 通过管理面板和数据库完全访问关联的账户信息
- 版主 - 根据站点配置可能拥有有限的访问权限
- 个别用户 - 可以从其用户偏好设置中查看和管理其关联的账户
使用 DiscourseConnect 最小化 PII 存储
为了避免在 Discourse 中存储某些个人身份信息，您可以使用 DiscourseConnect 完全处理用户的登录过程。
DiscourseConnect 如何减少 PII 暴露
使用 DiscourseConnect，您可以完全控制传回 Discourse 的用户信息。由于您管理实施过程，您可以创建专注于隐私的传统标识符替代方案。
示例方法：与其向 Discourse 提供用户的真实电子邮件地址，不如创建一个唯一但不包含 PII 的电子邮件地址。
例如，如果用户的内部唯一 ID 是 U123456，您可以传递如下电子邮件地址：
user-U123456@example.com
额外的隐私优势
使用 DiscourseConnect 还可以向 Discourse 隐藏与联邦社交登录的任何关联。从 Discourse 的角度来看，用户使用的登录类型（社交、移动等）无关紧要，因为这是在您这边处理的。Discourse 只知道登录提供商告诉它的信息。
多因素认证 (MFA) 和外部身份验证
能否在外部身份验证之上强制执行 MFA？
目前不支持以预期方式组合使用此功能。
Discourse 具有 enforce_second_factor_on_external_auth 站点设置，该设置可防止启用 MFA 的用户使用外部身份验证方法（如社交登录）。启用后，如果用户启用了双因素认证，这将阻止他们使用外部身份验证方法登录。
此设置实际上使用户必须在以下两者之间做出选择：
- 使用外部身份验证（社交登录），但在 Discourse 上不使用 2FA
- 使用用户名/密码登录，并在 Discourse 上使用 2FA
对于使用 SSO 的最安全设置，请在您的身份提供商中实施 MFA，而不是在 Discourse 内部实施。