后端认证鉴权【免费下载链接】parse-serverParse Server for Node.js / Express项目地址https://gitcode.com/gh_mirrors/pa/parse-server点击查看免费下载本篇技术指南聚焦 Parse Server 8当前仓库即 Parse Server 源码中两项需要重点规划的上游变更邮件验证流程的 Token 化改造移除 PII 字段username的使用以及启动时为_User集合自动创建新索引的数据库变更。读完本文你将掌握 8.0 迁移中需要修改的端点、自定义页面表单格式、相关配置项emailVerifyTokenReuseIfValid、emailVerifyTokenValidityDuration、createIndexUserEmailVerifyToken等以及大用户量下的索引创建风险应对方案。概述8.0 迁移涉及的两大主题Parse Server 8 的迁移指南只强调了两处需要更长篇幅说明的变更其余完整变更列表请查阅 changelogs/CHANGELOG.md以及changelogs/目录下按阶段归档的 CHANGELOG_release.md、CHANGELOG_beta.md、CHANGELOG_alpha.md主题变更性质是否需人工干预Email Verification接口与页面表单的行为变更需要若使用自定义邮件验证 HTML 页面则必须修改表单Database Indexes启动时自动创建索引一般无需但大型用户库需评估首次启动耗时邮件验证从username到验证 Token 的 PII 改造变更动机从技术日志中移除敏感信息Parse Server 8 在邮件验证流程中移除了Parse.User.username字段的使用其目的是避免用户名这类个人身份信息PII出现在技术日志中。改造后验证流程不再依赖用户名而是改用 Parse Server 内部早已存在、且与用户关联的验证 Tokenverification token。这一改动的关键前提是过期但尚未被删除的验证 Token 仍保留在数据库中尽管它已过期因此该 Token 仍可用于识别用户。这正是后续过期 Token 页面与重新发送验证邮件逻辑能成立的基础。从源码看_User集合中的验证 Token 字段为_email_verify_token其读写权限在 src/Controllers/DatabaseController.js 中被定义为仅 master 键可读写客户端不可见。Token 的生成与校验逻辑位于 src/Controllers/UserController.js生成时写入_email_verify_token randomString(25)校验时按{ _email_verify_token: token }查询用户成功后通过{ __op: Delete }移除 Token 字段。过期验证链接页面URL 查询参数由username变为token当用户打开一个携带过期 Token 的验证链接时被重定向到的页面将不再提供username作为 URL 查询参数而是改为提供token查询参数。对应地仓库中位于public/目录的示例页面email_verification_link_expired.html即展示了这一新格式——页面通过隐藏字段将{{token}}回传至重发接口。相关的重定向与页面渲染逻辑见 src/Routers/PagesRouter.js当verifyEmail(token)校验失败时路由将用户导向emailVerificationLinkInvalid页面。重新发送验证邮件端点请求体由username改为token重新发送验证邮件的请求从携带username改为端点POST /resend_verification_email请求体携带token替换原来的username该端点在 README.md 的 REST 路由表中登记为POST resend_verification_email邮件验证类。在源码层面src/Routers/PagesRouter.js 的resendVerificationEmail(req)方法同时向后兼容读取req.body.username与req.body.token且token必须是字符串随后调用 src/Controllers/UserController.js 的resendVerificationEmail(username, req, token)后者通过getUserIfNeeded({ username, _email_verify_token: token })定位用户。注意emailVerifySuccessOnInvalidEmail默认true决定当无法定位用户时是静默返回发送成功页面还是跳转到失败页src/Options/Definitions.js。对应测试见 spec/PagesRouter.spec.js、spec/EmailVerificationToken.spec.js 与 spec/ValidationAndPasswordsReset.spec.js这些用例验证了以token为重发依据的完整流程以及非字符串 Token 会被拒绝。自定义页面必须适配的新表单格式如果你自定义了邮件验证 HTML 页面无论使用的是当前PagesRouter页面目录public/还是已废弃的PublicAPIRouter目录public_html/都必须改造表单请求。参考仓库public/目录下的示例页面含public/de/、public/de-AT/本地化副本过期链接页面的表单应如下设置form methodPOST action{{publicServerUrl}}/apps/{{appId}}/resend_verification_email input nametoken typehidden value{{token}} input namelocale typehidden value{{locale}} button typesubmitResend Link/button /form完整示例见 public/email_verification_link_expired.html其他涉及验证成功、发送成功/失败、链接无效等状态页同样位于该目录。模板占位符由 PagesRouter 渲染时注入appId、token、locale、publicServerUrl等。[!WARNING]自定义清理逻辑会破坏重发流程Parse Server 不会自动删除已过期的验证 Token即使它已过期。如果你实现了自定义的清理逻辑去删除过期 Token那么表单向/resend_verification_email发起的请求将会失败——因为过期 Token 已不存在无法与任何用户关联。此时你必须自行实现一套自定义的重发邮件流程不能依赖该端点。[!IMPORTANT]Token 无历史记录只有最新 Token 会被保留Parse Server 不会保存验证 Token 的历史数据库里只存储最近一次生成的验证 Token。每当生成新 Token旧 Token 即被覆盖替换。若用户点击的是已过期的旧链接且该 Token 已被数据库中更新的 Token 替换Parse Server 便无法将过期 Token 关联到任何用户此时必须为用户提供其他重发邮件的途径。缓解方案设置emailVerifyTokenReuseIfValid: true并适当延长emailVerifyTokenValidityDuration。这样当用户再次请求验证邮件时若当前存储的 Token 仍然有效则直接复用而非生成新 Token从而保证当前存储的 Token 不会被过早替换。相关配置项详解上述缓解方案涉及两个配置项其定义见 src/Options/Definitions.js配置项默认值说明emailVerifyTokenReuseIfValidfalse设为true时若用户再次请求验证邮件但当前已有未过期的 Token则复用该 Token避免用户请求多封邮件、每封都使前一封失效、导致不知道哪条链接有效的常见问题。要求verifyUserEmails: trueemailVerifyTokenValidityDurationundefined永不失效验证 Token 的有效时长秒过期后链接失效需重新发送。例如 2 小时后过期则设为720060×60×2。要求verifyUserEmails: true两个配置项均可通过环境变量注入PARSE_SERVER_EMAIL_VERIFY_TOKEN_REUSE_IF_VALID与PARSE_SERVER_EMAIL_VERIFY_TOKEN_VALIDITY_DURATION类型解析由 src/Options/parsers.js 中的布尔/数字解析器完成。迁移到 8.0 时若你之前用username重发验证邮件的场景依赖旧 Token 失效语义请务必结合这两个参数评估行为差异。数据库索引启动时自动为 Token 字段建索引作为邮件验证与密码重置改进的一部分8.0 中这些操作所使用的查询改为按 Token 而非 username/email 字段执行。为保证查询性能Parse Server 在服务器初始化期间会自动为以下字段创建索引_User._email_verify_token用于邮件验证查询_User._perishable_token用于密码重置查询与username、email字段的既有索引创建方式一致这些索引在 Parse Server 启动时自动创建无需人工干预。从源码结构看索引创建发生在 src/Controllers/DatabaseController.js服务器初始化时调用.ensureIndex(_User, requiredUserFields, [_email_verify_token], _email_verify_token, false)与.ensureIndex(_User, requiredUserFields, [_perishable_token], _perishable_token, false)创建失败时仅记录Unable to create index ...警告而不会导致启动中断与 username/email 索引的处理方式相同参见同文件 src/Controllers/DatabaseController.js。相关数据字段的客户端不可见、master 可读写权限见 src/Controllers/DatabaseController.js。控制索引创建的配置项若需要跳过自动创建例如已在迁移前手动建好可通过以下配置项控制定义见 src/Options/Definitions.js配置项环境变量默认值createIndexUserEmailVerifyTokenPARSE_SERVER_DATABASE_CREATE_INDEX_USER_EMAIL_VERIFY_TOKENtruecreateIndexUserPasswordResetTokenPARSE_SERVER_DATABASE_CREATE_INDEX_USER_PASSWORD_RESET_TOKENtrue[!NOTE] 即使设置为false以手动创建索引也需注意这些原本自动创建的索引未来可能针对 Parse Server 内部使用方式优化而发生变化手动创建的索引需自行跟踪这类演进。大用户量库的升级注意事项[!WARNING] 如果已有大量存量用户升级到 Parse Server 8 后的首次启动可能花费较多时间完成索引创建。服务器日志会明确记录索引创建完成或失败的信息。若担心索引创建期间对数据库性能造成影响可以在升级 Parse Server 之前以受控的独立流程手动预先创建这两个索引。手动创建索引的等价操作示例以 MongoDB shell 为例db._User.createIndex({ _email_verify_token: 1 }, { background: true }); db._User.createIndex({ _perishable_token: 1 }, { background: true });PostgreSQL 后端下等价语句Parse Server 的 Postgres 适配器同样使用这些字段参见 src/Adapters/Storage/Postgres/PostgresStorageAdapter.jsCREATE INDEX CONCURRENTLY IF NOT EXISTS idx_user_email_verify_token ON _User (_email_verify_token); CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_user_perishable_token ON _User (_perishable_token);迁移检查清单升级到 Parse Server 8 前建议按以下顺序逐项核对检查自定义页面若你在public/PagesRouter或public_html/已废弃 PublicAPIRouter中自定义过邮件验证 HTML请对照 public/email_verification_link_expired.html 等示例页面将重发表单改为POST到/resend_verification_email并携带token而非username。检查自定义 Token 清理逻辑若存在删除过期验证 Token 的定时任务或脚本评估其对/resend_verification_email重发流程的破坏性并规划替代重发方案。配置 Token 复用与有效期根据业务需要设置emailVerifyTokenReuseIfValid与emailVerifyTokenValidityDuration缓解旧 Token 已被替换导致无法重发的问题。评估首次启动的索引创建成本大型_User集合建议在升级前手动创建_email_verify_token与_perishable_token索引并可通过createIndexUserEmailVerifyToken: false、createIndexUserPasswordResetToken: false关闭自动创建。回归测试可参考仓库中的 spec/EmailVerificationToken.spec.js、spec/PagesRouter.spec.js 与 spec/ValidationAndPasswordsReset.spec.js 中涉及resend_verification_email与 Token 校验的用例验证升级后的端到端行为。小结Parse Server 8 的邮件验证 Token 化改造在保护用户 PII 的同时将重发验证邮件的契约从username迁移到了token配套引入_email_verify_token与_perishable_token两个自动索引以保证查询性能。本次迁移的核心工作集中在自定义页面的表单适配、Token 生命周期策略复用与有效期配置以及大用户量场景下的索引创建规划三处若均未自定义页面、无清理逻辑且用户量不大则升级过程中几乎无需人工干预。赞分享后端认证鉴权【免费下载链接】parse-serverParse Server for Node.js / Express项目地址https://gitcode.com/gh_mirrors/pa/parse-server点击查看免费下载相关推荐告别单调终端450配色方案让你的命令行界面焕然一新告别单调终端450配色方案让你的命令行界面焕然一新 你是否曾盯着单调的黑白终端界面感到视觉疲劳每天数小时与命令行打交道眼睛却要忍受着枯燥的色彩组合iT开发工具FreeLLM API 数据库迁移全指南从创建迁移到生产自动执行FreeLLM API 数据库迁移全指南从创建迁移到生产自动执行 本篇技术指南以 FreeLLM API 服务端 server/ 的数据库迁移Datab后端API网关LLM 网关大模型AlaSQL数据库迁移工具自动化schema与数据迁移AlaSQL数据库迁移工具自动化schema与数据迁移 你是否还在为手动编写数据库迁移脚本而头疼是否担心迁移过程中数据丢失或格式错误本文将带你探索如何使用嵌入式数据库数据工程上一篇Edward2 vs PyMC3 vs TensorFlow Probability主流概率编程框架横向评测下一篇如何快速上手 Playwright for .NET5分钟搭建你的第一个自动化测试项目创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考