本指南解释了 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 的用户信息。由于您管理实现，因此您可以创建注重隐私的传统标识符的替代方案。
示例方法： 您可以创建一个唯一的、不包含 PII 的电子邮件地址，而不是向 Discourse 提供用户的真实电子邮件地址。
例如，如果用户的内部唯一 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 内部实施。