Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Create the staging test login in the policyengine-dev Auth0 tenant and switch staging to it

未关闭
  • 哪里不对？
#4,000 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 3 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
18/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
活跃
技术栈
github-actions, python
领域
authentication, backend-api-design, ci-cd

调研方向

Start with .github/workflows/push.yml and .github/scripts/deploy_cloud_run_candidate.sh to trace how staging environment values reach the deployment and integration test. The issue also requires configuring Auth0 tenants and GitHub environment variables and secrets, then running tests/integration/test_live_v2_policies.py after a staging deploy. Done means the staging test passes and a decoded test token has the specified issuer and audience.

由索引模型根据 Issue 内容生成。

描述

Context

Staging and preview sign-in are moving off the production Auth0 tenant (auth.policyengine.org, policyengine.uk.auth0.com) to a separate test tenant, policyengine-dev.uk.auth0.com. Real users stay in production, and test sign-ins can only reach staging.

The test tenant already has:

  • the API entry "PolicyEngine API" with identifier https://staging-api.policyengine.org/ (RS256, refresh tokens allowed, same token lifetimes as production);
  • the single-page app "PolicyEngine v3 previews" (client ID yjcEexib2Xt50okAg5fuYuDdNGrOerg6), which allows http://localhost:3001 and https://policyengine-calculator-next-*-policy-engine.vercel.app, with Google and GitHub sign-in.

The staging integration tests in tests/integration/test_live_v2_policies.py sign in as a dedicated test user through Auth0's password-realm grant. push.yml runs them after every staging deploy, before the production deploy. That test login currently exists only in the production tenant. Until it exists in the test tenant, staging can't accept the test tenant's tokens: the tests would get rejected tokens, fail, and stop the production deploy.

1. Create the test login in policyengine-dev

Copy production's setup:

  • Database connection policyengine-staging-ci: keep this exact name so STAGING_AUTH0_TEST_REALM stays the same. Password authentication only, disable_signup: true, brute-force protection on, passwordPolicy: good. Enable it only for the CI application below.
  • Application "PolicyEngine API staging CI":
    • app_type: regular_web, token_endpoint_auth_method: client_secret_post;
    • grant types: password and http://auth0.com/oauth/grant-type/password-realm only;
    • description: "Staging only: Public API live-test password grant for its test user (policyengine-staging-ci). Never use outside CI."
  • User [email protected] in that connection, with a new random password and email_verified: true.

Don't print the client secret or password. Keep them somewhere private until step 2.

2. Switch staging to the test tenant

Change all of these together, in this repository's staging GitHub environment only. The production environment has its own copies of the PUBLIC_API_AUTH_* variables, and they must not change.

Kind Name Current value New value
Variable PUBLIC_API_AUTH_ISSUER https://auth.policyengine.org/ https://policyengine-dev.uk.auth0.com/
Variable PUBLIC_API_AUTH_AUDIENCE https://api.policyengine.org/ https://staging-api.policyengine.org/
Variable STAGING_AUTH0_TEST_DOMAIN auth.policyengine.org policyengine-dev.uk.auth0.com
Variable STAGING_AUTH0_TEST_AUDIENCE https://api.policyengine.org/ https://staging-api.policyengine.org/
Variable STAGING_AUTH0_TEST_REALM policyengine-staging-ci unchanged
Secret STAGING_AUTH0_TEST_CLIENT_ID production CI app the new CI app's client ID
Secret STAGING_AUTH0_TEST_CLIENT_SECRET production CI app the new CI app's client secret
Secret STAGING_AUTH0_TEST_USERNAME [email protected] unchanged
Secret STAGING_AUTH0_TEST_PASSWORD production test user the new test user's password

How these values reach the running code:

  • PUBLIC_API_AUTH_* are read in the staging deploy job's env: block in push.yml from vars.*. They're passed to .github/scripts/deploy_cloud_run_candidate.sh, which sets them on the Cloud Run service with gcloud run deploy --set-env-vars. They only take effect on the next staging deploy; changing the GitHub values alone doesn't change the running service.
  • STAGING_AUTH0_TEST_* are read in the env of the "Run staging integration tests" step in push.yml, from vars.* and secrets.* in the staging environment.

The app's preview builds must switch to the test tenant at the same time. Otherwise previews keep sending production tokens, and staging will reject them once it expects the test tenant's.

3. Check

  • Run a staging deploy and confirm test_live_v2_policies.py passes.
  • Decode one test token and confirm iss is https://policyengine-dev.uk.auth0.com/ and aud includes https://staging-api.policyengine.org/.

Notes

  • The Public API identifies accounts by token issuer and subject together. After the switch, the test user is a new staging account, and staging data saved under the production-tenant test user is no longer linked to it. The tests delete the test user's PolicyEngine account at the start and end of each run, so they don't depend on old data.
  • Because of that deletion, staging must not get AUTH0_MANAGEMENT_* settings for the test tenant. With them, the Public API would also delete the test user from Auth0.

4. Afterwards

  • In the production tenant, delete the application "PolicyEngine API staging CI", the policyengine-staging-ci database connection and its test user. Nothing uses them after the switch.
主要语言
Python
星标
18
派生
33
平均合并
2 天 15 小时
30 天内合并 PR
35

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

PolicyEngine/policyengine-api 的其他 Issue

查看 PolicyEngine/policyengine-api 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。