尧图网站建设 
Gumroad 本地开发环境用户与认证Users Authentication完全指南【免费下载链接】gumroadSee what sticks项目地址: https://gitcode.com/GitHub_Trending/gumr/gumroad本文围绕 Gumroad 开源仓库的 docs/users.md 展开系统讲解开发环境预置的种子用户体系、团队角色Team Roles权限模型、内部管理员Internal Admin判定逻辑以及非生产环境的双因素认证2FA调试技巧。读完本文你将掌握如何用sellergumroad.com等预置账号快速登录本地开发环境、如何借助不同团队角色测试店铺权限边界以及000000万能验证码背后的源码原理。一、种子用户总览一条命令准备好整套测试账号在 Gumroad 仓库中运行bin/rails db:prepare即可完成数据库的创建、schema 迁移与数据填充seeding。该命令会通过 db/seeds.rb 加载公共种子并按当前RAILS_ENV匹配加载环境专属种子目录目录名以下划线分隔环境名见 seeds.rb最终播种出以下 5 个用户Email密码Team RoleInternal Adminsellergumroad.compasswordOwner✔selleradmingumroad.compasswordAdmin✘sellermarketinggumroad.compasswordMarketing✘sellersupportgumroad.compasswordSupport✘selleraccountantgumroad.compasswordAccountant✘所有账号密码统一为password种子脚本特意跳过校验写入这个易被爆破但开发环境专用的密码见 01_users.rb。这套账号体系同时服务于开发development与预发布staging环境属于db/seeds/020_development_staging/目录。提示bin/rails db:prepare是幂等入口。种子脚本本身也做了幂等处理——例如 01_users.rb 先User.find_by(email:)查重已存在则跳过创建。二、Primary Usersellergumroad.com的特殊身份sellergumroad.com是整个开发环境的主用户Primary User它同时具备以下四类特殊能力内部管理员Internal Admin可以访问/admin管理入口Payout 特权拥有提现Payout相关操作权限Risk 特权拥有风控Risk相关操作权限服务类产品创建资格账户年龄超过User::MIN_AGE_FOR_SERVICE_PRODUCTS可创建服务类产品Service Products。内部管理员判定is_team_member?在 01_users.rb 中主用户被显式设置为seller.is_team_member true。而/admin的访问控制正是基于该布尔字段实现的管理员控制器 app/controllers/admin/base_controller.rb 中的require_admin!钩子会校验current_user.is_team_member?非团队成员的请求会被重定向或返回 404见 base_controller.rb。值得注意的是该控制器注释说明原管理后台 Web UI 已移除目前保留的是两个仍被其他页面引用的团队成员入口用户模拟登录impersonate与 Stripe 后台跳转见 base_controller.rb。此外is_team_member?还广泛用于代码库各处的能力判定例如商品列表的越权跳过逻辑links_controller.rb、用户模拟权限impersonate.rb、以及废弃购物车工作流与群发邮件资格的提前放行user.rb、user.rb。服务类产品资格MIN_AGE_FOR_SERVICE_PRODUCTS文档指出主用户有资格创建服务类产品其硬性前提是账户注册时间足够久。该阈值定义于 app/models/user.rbMIN_AGE_FOR_SERVICE_PRODUCTS 30.days对应的资格判定逻辑user.rb为Time.current - created_at MIN_AGE_FOR_SERVICE_PRODUCTS种子脚本为了让主用户天然满足该条件直接把其created_at回拨为2 个月前01_users.rb同时预置了一笔状态为completed、金额 1000 美分的 PayPal 历史打款记录01_users.rb为后续测试提现、结算等流程做好准备。在测试环境中这一资格同样通过回拨created_at的方式构造例如 users.rb 工厂 使用User::MIN_AGE_FOR_SERVICE_PRODUCTS.ago - 1.day生成刚好超过 30 天的卖家。Payout 与 Risk 特权文档将 Payout 与 Risk 特权列为主用户的专属能力。从源码结构看这两类能力与用户模型中的提现调度和风控状态机两大子系统强相关User上挂着has_many :scheduled_payoutsuser.rb并以 JSON 属性持久化payout_threshold_cents、payout_frequency、payouts_paused_by等提现配置user.rb同时维护一个以user_risk_state为核心的有限状态机初始态为not_revieweduser.rb并提供compliant、not_suspended等作用域user.rb。主用户在种子脚本中设置了user_risk_state compliant这是其具备风险相关操作基础的前提。三、Team Users用团队角色测试店铺权限其余 4 个用户selleradmin、sellermarketing、sellersupport、selleraccountant用于在主用户店铺上测试特定团队角色。它们不是内部管理员也不具备任何特殊权限——文档特别强调selleradmingumroad.com是店铺管理员store admin而非内部管理员internal admin。这两个admin概念极易混淆务必区分。角色模型TeamMembership::ROLES团队角色由 app/models/team_membership.rb 建模合法角色全集定义在 team_membership.rbROLES %w(owner accountant admin marketing support).freeze代码通过元编程为每个角色动态生成role_name?谓词方法与role_name作用域team_membership.rb。种子脚本正是遍历TeamMembership::ROLES.excluding(TeamMembership::ROLE_OWNER)01_users.rb为除 owner 外的每个角色创建一个sellerrolegumroad.com用户并建立其与主用户店铺之间的user_memberships关系01_users.rb。角色的约束校验TeamMembership上还有几条关键校验理解它们有助于读懂种子脚本的写法owner 角色只能分配给店铺的自然所有者user seller且自然所有者的成员关系角色必须是 ownerteam_membership.rb非 owner 成员必须先有 owner 成员存在否则校验失败owner_membership_must_existteam_membership.rb。因此种子脚本中先创建主用户sellergumroad.com其 Owner 成员关系通过create_owner_membership_if_needed!建立见 01_users.rb再为其他角色挂靠成员关系顺序正好满足上述约束。四、双因素认证2FA非生产环境的万能验证码所有非生产环境development / staging / test都接受000000作为双因素认证验证码。这意味着你在本地开发时即使账号开启了 2FA也无需查看邮件即可用000000直接登录。该行为的核心实现在 app/models/concerns/two_factor_authentication.rbDEFAULT_AUTH_TOKEN 000000 TOKEN_VALIDITY 10.minutes TWO_FACTOR_AUTH_EXPIRY 2.months验证入口方法token_authenticated?的逻辑是two_factor_authentication.rbdef token_authenticated?(authentication_token) return true if authenticate_otp(authentication_token, drift: TOKEN_VALIDITY).present? # Allow 000000 as valid authentication token in all non-production environments !Rails.env.production? authentication_token DEFAULT_AUTH_TOKEN end可以看到两个要点优先走标准 OTP 校验authenticate_otp允许 10 分钟TOKEN_VALIDITY的漂移容差兜底万能码只要不是production环境000000永远通过验证而一旦切到生产环境该分支短路返回false000000立即失效——这正是文档强调非生产环境的原因也是仓库在安全上的一道防线。该模块还包含 2FA 的周边设施每个用户对应一个不可猜测的 cookie 键基于external_id加密后取 SHA-256 前 13 位用于同一浏览器记住多账号的 2FA 状态two_factor_authentication.rb、TOTPtotp_credential与 Passkeywebauthn_credentials能力探测two_factor_authentication.rb以及通过TwoFactorAuthenticationMailer异步投递验证码邮件的send_authentication_token!two_factor_authentication.rb。五、实战速查从初始化到登录将以上内容串成一条完整的本地开发上手链路准备数据库运行bin/rails db:prepare自动播种上文 5 个用户登录主用户使用sellergumroad.com/password登录2FA 输入000000官方 README 也确认了这组凭证与万能验证码体验内部管理员能力主用户可访问/admin入口受 Admin::BaseController#require_admin! 的is_team_member?校验保护并可使用用户模拟登录功能测试团队协作分别用selleradmin、sellermarketing、sellersupport、selleraccountant登录验证不同团队角色在同一店铺上的权限差异这些账号无内部管理后台访问权、无特殊权限测试服务类产品主用户账户已年满30 天且带有历史打款记录可直接创建服务类产品测试代码中则常用created_at: User::MIN_AGE_FOR_SERVICE_PRODUCTS.ago - 1.day构造此类卖家参考 users.rb 工厂 与 bundle_contents_controller_spec.rb。若需在 WindowsWSL环境下搭建整套开发环境可参考 docs/development/windows.md更多环境与测试相关文档见 docs/OVERVIEW.md 与 docs/testing.md。六、常见误区小结两个 admin 不是一回事selleradmingumroad.com只是店铺管理员角色TeamMembership::ROLE_ADMIN不能访问/admin000000不是生产环境万能钥匙其有效性由!Rails.env.production?硬性约束切勿在生产环境尝试主用户的特权来自种子数据而非魔法内部管理员来自is_team_member true服务类产品资格来自被回拨的created_at与预置打款记录团队角色则来自TeamMembership成员关系——理解这些底层字段才能在写测试时正确构造所需用户。【免费下载链接】gumroadSee what sticks项目地址: https://gitcode.com/GitHub_Trending/gumr/gumroad创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Gumroad 本地开发环境用户与认证（Users Authentication）完全指南
Gumroad 本地开发环境用户与认证Users Authentication完全指南【免费下载链接】gumroadSee what sticks项目地址: https://gitcode.com/GitHub_Trending/gumr/gumroad本文围绕 Gumroad 开源仓库的 docs/users.md 展开系统讲解开发环境预置的种子用户体系、团队角色Team Roles权限模型、内部管理员Internal Admin判定逻辑以及非生产环境的双因素认证2FA调试技巧。读完本文你将掌握如何用sellergumroad.com等预置账号快速登录本地开发环境、如何借助不同团队角色测试店铺权限边界以及000000万能验证码背后的源码原理。一、种子用户总览一条命令准备好整套测试账号在 Gumroad 仓库中运行bin/rails db:prepare即可完成数据库的创建、schema 迁移与数据填充seeding。该命令会通过 db/seeds.rb 加载公共种子并按当前RAILS_ENV匹配加载环境专属种子目录目录名以下划线分隔环境名见 seeds.rb最终播种出以下 5 个用户Email密码Team RoleInternal Adminsellergumroad.compasswordOwner✔selleradmingumroad.compasswordAdmin✘sellermarketinggumroad.compasswordMarketing✘sellersupportgumroad.compasswordSupport✘selleraccountantgumroad.compasswordAccountant✘所有账号密码统一为password种子脚本特意跳过校验写入这个易被爆破但开发环境专用的密码见 01_users.rb。这套账号体系同时服务于开发development与预发布staging环境属于db/seeds/020_development_staging/目录。提示bin/rails db:prepare是幂等入口。种子脚本本身也做了幂等处理——例如 01_users.rb 先User.find_by(email:)查重已存在则跳过创建。二、Primary Usersellergumroad.com的特殊身份sellergumroad.com是整个开发环境的主用户Primary User它同时具备以下四类特殊能力内部管理员Internal Admin可以访问/admin管理入口Payout 特权拥有提现Payout相关操作权限Risk 特权拥有风控Risk相关操作权限服务类产品创建资格账户年龄超过User::MIN_AGE_FOR_SERVICE_PRODUCTS可创建服务类产品Service Products。内部管理员判定is_team_member?在 01_users.rb 中主用户被显式设置为seller.is_team_member true。而/admin的访问控制正是基于该布尔字段实现的管理员控制器 app/controllers/admin/base_controller.rb 中的require_admin!钩子会校验current_user.is_team_member?非团队成员的请求会被重定向或返回 404见 base_controller.rb。值得注意的是该控制器注释说明原管理后台 Web UI 已移除目前保留的是两个仍被其他页面引用的团队成员入口用户模拟登录impersonate与 Stripe 后台跳转见 base_controller.rb。此外is_team_member?还广泛用于代码库各处的能力判定例如商品列表的越权跳过逻辑links_controller.rb、用户模拟权限impersonate.rb、以及废弃购物车工作流与群发邮件资格的提前放行user.rb、user.rb。服务类产品资格MIN_AGE_FOR_SERVICE_PRODUCTS文档指出主用户有资格创建服务类产品其硬性前提是账户注册时间足够久。该阈值定义于 app/models/user.rbMIN_AGE_FOR_SERVICE_PRODUCTS 30.days对应的资格判定逻辑user.rb为Time.current - created_at MIN_AGE_FOR_SERVICE_PRODUCTS种子脚本为了让主用户天然满足该条件直接把其created_at回拨为2 个月前01_users.rb同时预置了一笔状态为completed、金额 1000 美分的 PayPal 历史打款记录01_users.rb为后续测试提现、结算等流程做好准备。在测试环境中这一资格同样通过回拨created_at的方式构造例如 users.rb 工厂 使用User::MIN_AGE_FOR_SERVICE_PRODUCTS.ago - 1.day生成刚好超过 30 天的卖家。Payout 与 Risk 特权文档将 Payout 与 Risk 特权列为主用户的专属能力。从源码结构看这两类能力与用户模型中的提现调度和风控状态机两大子系统强相关User上挂着has_many :scheduled_payoutsuser.rb并以 JSON 属性持久化payout_threshold_cents、payout_frequency、payouts_paused_by等提现配置user.rb同时维护一个以user_risk_state为核心的有限状态机初始态为not_revieweduser.rb并提供compliant、not_suspended等作用域user.rb。主用户在种子脚本中设置了user_risk_state compliant这是其具备风险相关操作基础的前提。三、Team Users用团队角色测试店铺权限其余 4 个用户selleradmin、sellermarketing、sellersupport、selleraccountant用于在主用户店铺上测试特定团队角色。它们不是内部管理员也不具备任何特殊权限——文档特别强调selleradmingumroad.com是店铺管理员store admin而非内部管理员internal admin。这两个admin概念极易混淆务必区分。角色模型TeamMembership::ROLES团队角色由 app/models/team_membership.rb 建模合法角色全集定义在 team_membership.rbROLES %w(owner accountant admin marketing support).freeze代码通过元编程为每个角色动态生成role_name?谓词方法与role_name作用域team_membership.rb。种子脚本正是遍历TeamMembership::ROLES.excluding(TeamMembership::ROLE_OWNER)01_users.rb为除 owner 外的每个角色创建一个sellerrolegumroad.com用户并建立其与主用户店铺之间的user_memberships关系01_users.rb。角色的约束校验TeamMembership上还有几条关键校验理解它们有助于读懂种子脚本的写法owner 角色只能分配给店铺的自然所有者user seller且自然所有者的成员关系角色必须是 ownerteam_membership.rb非 owner 成员必须先有 owner 成员存在否则校验失败owner_membership_must_existteam_membership.rb。因此种子脚本中先创建主用户sellergumroad.com其 Owner 成员关系通过create_owner_membership_if_needed!建立见 01_users.rb再为其他角色挂靠成员关系顺序正好满足上述约束。四、双因素认证2FA非生产环境的万能验证码所有非生产环境development / staging / test都接受000000作为双因素认证验证码。这意味着你在本地开发时即使账号开启了 2FA也无需查看邮件即可用000000直接登录。该行为的核心实现在 app/models/concerns/two_factor_authentication.rbDEFAULT_AUTH_TOKEN 000000 TOKEN_VALIDITY 10.minutes TWO_FACTOR_AUTH_EXPIRY 2.months验证入口方法token_authenticated?的逻辑是two_factor_authentication.rbdef token_authenticated?(authentication_token) return true if authenticate_otp(authentication_token, drift: TOKEN_VALIDITY).present? # Allow 000000 as valid authentication token in all non-production environments !Rails.env.production? authentication_token DEFAULT_AUTH_TOKEN end可以看到两个要点优先走标准 OTP 校验authenticate_otp允许 10 分钟TOKEN_VALIDITY的漂移容差兜底万能码只要不是production环境000000永远通过验证而一旦切到生产环境该分支短路返回false000000立即失效——这正是文档强调非生产环境的原因也是仓库在安全上的一道防线。该模块还包含 2FA 的周边设施每个用户对应一个不可猜测的 cookie 键基于external_id加密后取 SHA-256 前 13 位用于同一浏览器记住多账号的 2FA 状态two_factor_authentication.rb、TOTPtotp_credential与 Passkeywebauthn_credentials能力探测two_factor_authentication.rb以及通过TwoFactorAuthenticationMailer异步投递验证码邮件的send_authentication_token!two_factor_authentication.rb。五、实战速查从初始化到登录将以上内容串成一条完整的本地开发上手链路准备数据库运行bin/rails db:prepare自动播种上文 5 个用户登录主用户使用sellergumroad.com/password登录2FA 输入000000官方 README 也确认了这组凭证与万能验证码体验内部管理员能力主用户可访问/admin入口受 Admin::BaseController#require_admin! 的is_team_member?校验保护并可使用用户模拟登录功能测试团队协作分别用selleradmin、sellermarketing、sellersupport、selleraccountant登录验证不同团队角色在同一店铺上的权限差异这些账号无内部管理后台访问权、无特殊权限测试服务类产品主用户账户已年满30 天且带有历史打款记录可直接创建服务类产品测试代码中则常用created_at: User::MIN_AGE_FOR_SERVICE_PRODUCTS.ago - 1.day构造此类卖家参考 users.rb 工厂 与 bundle_contents_controller_spec.rb。若需在 WindowsWSL环境下搭建整套开发环境可参考 docs/development/windows.md更多环境与测试相关文档见 docs/OVERVIEW.md 与 docs/testing.md。六、常见误区小结两个 admin 不是一回事selleradmingumroad.com只是店铺管理员角色TeamMembership::ROLE_ADMIN不能访问/admin000000不是生产环境万能钥匙其有效性由!Rails.env.production?硬性约束切勿在生产环境尝试主用户的特权来自种子数据而非魔法内部管理员来自is_team_member true服务类产品资格来自被回拨的created_at与预置打款记录团队角色则来自TeamMembership成员关系——理解这些底层字段才能在写测试时正确构造所需用户。【免费下载链接】gumroadSee what sticks项目地址: https://gitcode.com/GitHub_Trending/gumr/gumroad创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考