Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#4,000 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 3 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
18/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
github-actions, python
Bereich
authentication, backend-api-design, ci-cd

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.
Vorherrschende Sprache
Python
Sterne
18
Forks
33
Ø Merge
2 T. 18 Std.
Gemergte PRs (30 T.)
36

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus PolicyEngine/policyengine-api

Alle Issues in PolicyEngine/policyengine-api

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.