Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#4,000 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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日 18時間
マージ済み PR（30日）
36

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

PolicyEngine/policyengine-api のほかの issue

PolicyEngine/policyengine-api の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。