后端前端【免费下载链接】remark42comment engine项目地址https://gitcode.com/gh_mirrors/re/remark42点击查看免费下载Remark42 的官方隐私政策site/content/privacy.md不仅界定了服务方收集、使用与披露个人信息的边界更承诺了用户请求删除数据的完整通道。本文以该隐私政策为骨架逐一对照 remark42 仓库源码剖析每一条隐私承诺背后的真实实现——包括Request my data removal一键删除的 JWT 全链路、登录态的 Cookie 会话机制、邮箱确认流程与第三方登录的数据获取方式。读完本文你将掌握 remark42 隐私机制的工作原理、相关配置参数以及如何验证这些隐私承诺确实落地。隐私政策概览适用范围与基本承诺该隐私政策由 Umputun 运营的 remark42.com 评论服务发布面向所有使用该服务SERVICE的网站访问者。政策的核心承诺可以概括为三点收集的个人信息仅用于提供和改进服务除政策所述情形外不会向任何人共享或披露用户信息用户有权通过显式入口请求删除自己的数据。政策中明确所用术语与服务条款保持一致可通过 https://remark42.com 访问未另行定义者均以条款为准。从实现角度看这套承诺对应的是 remark42 作为自托管评论引擎的架构事实评论数据、用户画像数据存储在你自己的服务端存储中用户与站点之间的身份关系通过 JWTJSON Web Token维持删除操作则在服务端以硬删除方式执行见下文。信息收集与使用登录提供方与个人数据的来源政策指出为提供更好的体验服务可能要求用户提供姓名、邮箱等可识别个人身份的信息也可能从执行登录的第三方服务获取基本信息这些信息被用于联系或识别用户。对照源码remark42 的身份信息获取有两条来源路径一是第三方 OAuth2 登录。在 backend/app/cmd/server.go 中认证配置组AuthGroup定义了多种登录方式google、github、apple、yandex等 OAuth2 提供方通过auth.google.cid/auth.google.csec等参数配置客户端 ID 与密钥telegram通过telegram.token开启 Telegram 登录email邮箱直登见auth.email.enabledev本地开发用的 OAuth2 服务器仅供调试。其中makeAuth部分server.go展示了典型的接入方式authenticator.AddProvider(google, s.Auth.Google.CID, s.Auth.Google.CSEC)——登录成功后提供方返回的姓名、邮箱、头像 URL 等基本信息被写入用户的 JWT claims成为 remark42 用户画像的一部分。二是用户主动提交。用户在个人资料页填写邮箱用于订阅回复通知时该邮箱地址会被存储并关联到用户记录见下文的邮箱确认流程。从源码结构可以推断匿名用户anonymous仅拥有一个匿名 ID不携带上述个人身份字段个人信息的采集严格限定在可识别身份的登录与订阅场景。数据删除请求从按钮到服务端的完整链路政策中如何请求删除数据一节是全文最具操作性的部分用户可在个人资料页点击Request my data removal然后点击确认邮件中的链接完成删除。这一承诺在前后端均实现了完整闭环值得详细拆解。前端入口个人资料页的删除按钮在 frontend/apps/remark42/app/components/profile/profile.tsx 中个人资料页底部渲染了Request my data removal按钮且仅在当前用户非匿名时显示{isCurrent !isUserAnonymous(user as unknown as User) ? ( footer className{styles.footer} Button kindhollow sizesm onClick{handleClickRequestRemoveData} FormattedMessage idprofile.request-to-delete-data defaultMessageRequest my data removal / /Button /footer ) : null}点击后触发handleClickRequestRemoveDataprofile.tsx它先调用requestDeletion()请求删除随即执行signout()登出——也就是说发起请求后用户的当前会话立刻失效等待邮件确认。API 层两类 deleteme 端点前端 API 封装在 frontend/apps/remark42/app/common/api.ts注释明确标注了这属于GDPR Methodsexport const deleteMe (): Promise{ user_id: string; link: string } apiFetcher.post(/deleteme); export const approveDeleteMe (token: string): Promisevoid adminFetcher.get(/deleteme, { token });对应后端的两个路由backend/app/rest/api/rest.go 与 rest.goPOST /api/v1/deleteme?site...发起删除请求需登录拒绝匿名用户GET /api/v1/admin/deleteme?tokenjwt确认并执行删除之所以用 GET是为了让用户可以直接从邮件中的链接点击访问见 admin.go 的注释说明。发起请求生成一次性的删除专用 JWTdeleteMeCtrlbackend/app/rest/api/rest_private.go实现了发起逻辑取当前登录用户信息生成一个有效期 3 个月ExpiresAt: time.Now().AddDate(0, 3, 0)的 JWT关键设计是向 claims 写入Attributes: map[string]any{ delete_me: true, // prevents this token from being used for login },这个delete_me: true标志是安全要害——它确保该 token只能用于删除不能用于登录即使 token 泄漏也无法冒充用户身份。响应体同时携带site、user_id、token与link其中 link 形如{remarkURL}/web/deleteme.html?site_id{site}token{jwt}该链接会通过确认邮件发送给用户对应政策中follow the link sent in the confirmation email的表述。确认执行token 校验与硬删除deleteMeRequestCtrlbackend/app/rest/api/admin.go是删除的最终执行者其处理顺序体现了严谨的安全校验解析 token调用TokenService().Parse(token)失败则拒绝校验delete_me标志若 claims 中不存在该标志直接返回 403防止用泄漏的普通登录 token 触发删除admin.go校验 audienceclaims.Audience 必须恰好为单个站点admin.go校验站点匹配请求中的site参数必须与 token 中的 audience 一致防止 token 被用于其他站点admin.go删除用户详情DeleteUserDetail(audience, userID, engine.AllUserDetails)清除该用户所有明细数据邮箱、Telegram 等硬删除用户DeleteUser(audience, userID, store.HardDelete)删除该用户全部评论与用户记录删除头像若用户曾上传头像claims.User.Picture 非空且配置了头像代理则同步从存储中删除头像文件。这里有个值得注意的防御细节——avatarIDFromPictureadmin.go要求头像 ID 必须形如hash.image且通过path.Base提取防止恶意构造的路径让基于文件系统的存储误删其他文件刷新缓存a.cache.Flush(...)清除与该用户、站点相关的评论缓存。删除完成后返回{user_id: ..., site_id: ...}。重复发起删除是幂等的——头像已不存在时avatar.ErrNotFound不会报错见 admin.go 与测试注释 backend/app/rest/api/admin_test.go。确认页面与测试验证邮件链接指向的deleteme.html由前端实现frontend/apps/remark42/app/deleteme.ts 在页面加载后先校验当前会话是否为管理员getUser().then(...)因为删除端点挂在 admin 路由下然后调用approveDeleteMe(token)执行删除并展示结果若未登录页面会提示Sign in as admin to the comments on site ...。该流程在后端测试中被完整覆盖backend/app/rest/api/rest_private_test.go验证POST /deleteme返回的 link 结构backend/app/rest/api/admin_test.go验证删除后用户头像文件确实被移除assert.NoFileExists(...)backend/app/cmd/server_test.go端到端验证发起请求 → 拿到 token → 通过 X-JWT 头执行删除。日志数据服务端访问日志的内容与边界政策声明访问服务时浏览器发送的信息会被记录为 Log Data可能包含 IP 地址、浏览器版本、访问页面、访问时间与时长等统计信息。这是标准的 Web 服务访问日志行为。在 remark42 中backend/app/cmd/server.go 的启动流程会配置 HTTP 访问日志包括请求路径、状态码、处理耗时等backend/app/rest/api/rest.go 中所有路由均挂在统一的中间件链下由日志中间件统一记录请求信息。可以推断日志数据主要用于服务排障、性能监控与安全审计而非用户画像政策中这些信息被用于提供和改进服务的表述与之吻合。Cookie 与会话JWT 认证机制的配置化控制政策指出站点使用 Cookie 确认用户身份用户可以选择接受或拒绝 Cookie但拒绝后可能无法使用部分服务。在 remark42 中确认用户身份的 Cookie 承载的是JWT 认证 token相关行为全部通过 backend/app/cmd/server.go 的认证参数控制参数默认值作用auth.ttl.cookie200h认证 Cookie 的存活时间TTL即会话最长有效时长auth.same-sitedefaultCookie 的 SameSite 策略可选default/none/lax/strict控制跨站请求是否携带 Cookieauth.send-jwt-headerfalse是否额外通过响应头下发 JWT供前端存入客户端 Cookie以应对第三方 Cookie 被浏览器拦截的场景源码注释同时警告这会增加 XSS 攻击面auth.secure-cookies自动当remark.url以https://开头时自动启用 Secure 标记server.goparseSameSiteserver.go将字符串配置映射为 Go 的http.SameSite枚举。拒绝 Cookie 意味着拒绝会话保持因此可能无法使用部分服务如需要登录的评论、回复订阅等在实现上是成立的。另一个与删除流程相关的细节服务端默认将 JWT 查询参数名从常见的token改为jwtserver.go正是为了给 deleteme 流程的token参数腾出语义空间避免冲突。服务提供商与共享边界谁接触不到你的个人信息政策列明服务可能雇佣第三方公司/个人用于促成服务、代表服务执行、执行服务相关任务、协助分析使用情况并强调这些第三方无法访问你的个人信息。从架构看remark42 的服务边界是自包含的评论与用户数据存储在服务端存储引擎中默认 BoltDB可扩展为远程存储第三方评论服务商无法接触登录信息由第三方 OAuth2 提供方Google、GitHub 等持有各自账号体系remark42 仅接收登录成功后返回的用户基本信息姓名、邮箱、头像 URL且该交换发生在服务端与提供方之间邮件发送通过 SMTP 或邮件服务完成第三方邮件服务商仅处理投递不接触评论数据本身。因此政策中第三方无访问权限的承诺对应的是 remark42 数据存储与业务处理全部在自托管后端完成的事实。安全传输与存储的保障及其边界政策以谨慎措辞承诺服务方会以商业上合理的手段保护个人信息但任何互联网传输或电子存储方式都无法保证 100% 安全。remark42 的安全实践可以从源码中看到多层防线传输层secure-cookies在 HTTPS 部署下自动启用backend/app/rest/api/ssl.go 提供 TLS 配置支持认证层JWT 签名校验TokenService().Parse在删除、订阅等敏感流程中均被调用deleteme token 的delete_me标志、3 个月有效期、站点 audience 匹配构成短效、单用途、单站点的删除令牌设计校验层头像 ID 的avatarIDFromPicture路径净化、site参数与 token audience 的一致性校验防止越权操作输入层请求体大小限制如邮箱订阅使用http.MaxBytesReader防止资源耗尽。与此同时政策对绝对安全的否定性表述是诚实且必要的免责边界——任何系统都存在攻击面部署者应结合 HTTPS、反代、访问控制等外部手段加固。儿童隐私低于 13 岁数据的主动删除政策声明服务不面向 13 岁以下儿童不会故意收集其个人信息一旦发现会立即从服务器删除并请家长/监护人联系服务方处理。这是对各国未成年人数据保护法规如美国 COPPA、欧盟 GDPR 相关条款的合规响应。remark42 作为评论引擎本身不设年龄验证机制——这一承诺的落点在于不故意收集与发现即删除发现未成年人信息后管理员可以通过前文所述的数据删除机制或 backend/app/rest/api/admin.go 中基于store.SoftDelete的管理员删除接口移除相关数据。政策更新与联系方式政策声明可能不时更新更新通过在本页面发布新版政策即时生效建议用户定期回看如有疑问或建议可通过站点提供的联系方式沟通。部署 remark42 的自托管用户需要明确站点服务提供方Umputun / remark42.com的隐私政策约束的是官方演示服务与托管形态自部署实例的数据处置义务由部署者承担。因此理解本文剖析的删除机制、会话机制与数据边界对自托管运维者履行自身隐私合规责任具有直接的工程价值。延伸阅读隐私机制的关键实现文件——后端删除流程、删除确认执行、认证与会话参数、前端删除入口、前端删除确认页。赞分享后端前端【免费下载链接】remark42comment engine项目地址https://gitcode.com/gh_mirrors/re/remark42点击查看免费下载相关推荐BioJava二级结构分析如何用DSSP自动识别蛋白的α螺旋与β折叠BioJava二级结构分析如何用DSSP自动识别蛋白的α螺旋与β折叠 项目简介 BioJava 是一个开源的 Java 生物计算库而它的 biojav开发工具数据分析Floccus隐私政策解读数据收集与使用说明Floccus隐私政策解读数据收集与使用说明 Floccus作为一款书签同步工具其隐私政策直接关系到用户数据安全。本文将从数据收集范围、共享机制和用户控制权前端移动开发数据同步QGroundControl 隐私政策全解读数据收集、相机与位置权限背后的源码实现QGroundControl 隐私政策全解读数据收集、相机与位置权限背后的源码实现 本文以 QGroundControl 官方发布的《Privacy Poli无人机智能硬件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考