Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#4,000 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 3 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
18/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
github-actions, python
Domaine
authentication, backend-api-design, ci-cd

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Python
Étoiles
18
Forks
33
Merge moyen
2 j 15 h
PR mergées (30 j)
35

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de PolicyEngine/policyengine-api

Toutes les issues de PolicyEngine/policyengine-api

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.