Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#4,000 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
18/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
github-actions, python
Área
authentication, backend-api-design, ci-cd

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Python
Estrellas
18
Forks
33
Merge medio
2 d 18 h
PR fusionados (30 d)
36

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de PolicyEngine/policyengine-api

Todos los issues de PolicyEngine/policyengine-api

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.