Miljøvariabler

API-konfigurasjon

Disse variablene settes i api/local.settings.json for lokal utvikling eller i Azure Function App → Configuration for produksjon.

Variabel	Påkrevd	Beskrivelse	Standard
COSMOS_ENDPOINT	✅	Cosmos DB endepunkt-URL	https://localhost:8081 (emulator)
COSMOS_KEY	✅	Cosmos DB primærnøkkel	Emulatornøkkel
COSMOS_DATABASE	✅	Databasenavn	choirtickets
JWT_SECRET	✅	Hemmelighet for signering av sesjonstokener	—
FRONTEND_URL	✅	Frontend-URL for magic link-tilbakekall	http://localhost:5173
RESEND_API_KEY	❌	Resend API-nøkkel for e-postutsending	—
FROM_EMAIL	❌	Avsender-e-postadresse	onboarding@resend.dev
E2E_TEST_MODE	❌	Aktiver test-modus-endepunkter (farlig)	false
NODE_ENV	❌	Miljø: development eller production	development
REFRESH_TOKEN_TTL_DAYS	❌	Positivt heltall for levetid på oppdateringstokener, i dager	90
COSMOS_REQUEST_TIMEOUT_MS	❌	Numerisk tidsgrense for Cosmos-forespørsler i millisekunder for nøkkelbaserte klienter	Cosmos SDK-standard
SHARED_EVENTS_ENABLED	❌	Eksakt true eller false for oppretting og endring av delte arrangementer	false
SHARED_EVENTS_ORGANIZATION_ALLOWLIST	❌	Kommaseparerte organisasjons-ID-er som kan endre delte arrangementer	Tom, ingen organisasjonsbegrensning
GITHUB_FEEDBACK_TOKEN	❌	Token med skrivetilgang til saker for valgfri oppretting av GitHub-saker fra beta-tilbakemeldinger	Ingen
DELEGATED_MEMBER_CATALOG_ENABLED	❌	Utrullingsbryter som viser en partnerorganisasjons delegerte konserter i partnerens egen medlemskatalog (Hjem, Bestill billetter)	false
DELEGATED_MEMBER_ORDERING_ENABLED	❌	Utrullingsbryter som lar en partnerorganisasjons medlemmer opprette nye selvbetjente bestillinger for en delegert konsert	false

Frontend-konfigurasjon

Disse variablene styrer frontend-applikasjonens atferd. Sett dem i en .env-fil i mappen frontend/:

Variabel	Påkrevd	Beskrivelse	Standard
VITE_API_URL	❌	Base-URL for API-kall	/api (proxy)
VITE_BETA_FEEDBACK	❌	Sett til true for å vise tilbakemeldingsknappen og menypunktet	false
VITE_DELEGATED_MEMBER_CATALOG_ENABLED	❌	Sett til den eksakte strengen 'true' for å vise delegerte konserter i en partnerorganisasjons egne Hjem- og Bestill billetter-skjermer. Enhver annen verdi, inkludert manglende verdi, holder dem skjult.	false

Test-modus og utvikling

E2E_TEST_MODE aktiverer farlige test-bare endepunkter (som /api/management/cleanup) for E2E-testing. Det krever tre forhold for å være aktivt:

1. E2E_TEST_MODE=true
2. NODE_ENV er IKKE production
3. FRONTEND_URL inneholder localhost

DANGER

Aktiver IKKE dette i produksjon. Test-modus-endepunkter kan slette alle data.

NODE_ENV styrer build- og kjøringsmiljøet:

• development — aktiverer debug-logging og utfyllende feil
• production — optimert build, skjuler debug-info

I produksjon må dette settes til production for å forhindre at test-endepunkter kjøres, uavhengig av E2E_TEST_MODE.

Konfigurasjon av delte arrangementer

SHARED_EVENTS_ENABLED godtar bare strengene true og false med små bokstaver. Hvis variabelen ikke er satt, er oppretting og endring av delte arrangementer deaktivert. Ugyldige verdier avvises som konfigurasjonsfeil. Lese- og vedlikeholdsstier har egen sikker atferd, slik at eksisterende data og gjenoppretting ikke slettes når endringer deaktiveres.

SHARED_EVENTS_ORGANIZATION_ALLOWLIST er valgfri. Skill organisasjons-ID-er med komma. API-et fjerner mellomrom rundt hver verdi, gjør den om til små bokstaver, godtar opptil 128 tegn og tillater små bokstaver, tall, ., _, : og -. Tom verdi betyr ingen ekstra organisasjonsbegrensning. Feilformaterte eller dupliserte normaliserte verdier er konfigurasjonsfeil. Superadmin kan omgå tillatelseslisten der handleren uttrykkelig tillater det, men kan ikke omgå den globale av-bryteren.

Konfigurasjon for delegert medlemsbestilling

Disse to bryterne styrer utrullingen av delegert salg for vanlige arrangementer til medlemmer av partnerorganisasjoner (v1.2.0). Begge er eksponerings- og tilgjengelighetsbrytere, aldri autorisasjon: alle levende delegerings-, medlemskaps- og rollesjekker kjører nøyaktig som før uansett innstilling. Begge er av som standard, og begge leses på nytt for hvert kall, slik at en tilbakerulling trer i kraft uten omstart.

• DELEGATED_MEMBER_CATALOG_ENABLED (server) og VITE_DELEGATED_MEMBER_CATALOG_ENABLED (frontend, byggetid) avgjør om en delegert konsert i det hele tatt vises i en partnerorganisasjons egen medlemskatalog. Gyldige sanne verdier på serveren er 1, true, yes, on (uavhengig av store/små bokstaver); frontend-bryteren godtar bare den eksakte strengen 'true'. Dette er kun eksponering — det stenger ikke bestillingsendepunktet.
• DELEGATED_MEMBER_ORDERING_ENABLED (server) er den egentlige tilgjengelighetsbryteren. Den styrer bare oppretting av nye selvbetjente delegerte medlemsbestillinger. Mens den er av, returnerer API-et en stabil 503 med feilkoden DELEGATED_MEMBER_ORDERING_UNAVAILABLE for et nytt bestillingsforsøk, og medlemmets billettvalg blir liggende i handlekurven slik at de kan prøve igjen senere. Bestillinger som allerede finnes i systemet, påvirkes ikke: kansellering, godkjenning, levering, rapporter solgt og rapporter returnert fortsetter å fungere, slik at en nødstopp aldri lar billetter bli hengende midt i livssyklusen.

Rekkefølgen ved utrulling betyr noe. Aktiver DELEGATED_MEMBER_ORDERING_ENABLED før DELEGATED_MEMBER_CATALOG_ENABLED / VITE_DELEGATED_MEMBER_CATALOG_ENABLED. Å slå på katalogen først ville vist medlemmer en delegert konsert der bestillinger blir avvist. Å aktivere katalogbryteren gir ikke i seg selv noen ny rettighet; den gjør bare en allerede autorisert konsert synlig.

Slå på bryterne i et forhåndsvisningsmiljø for pull request i Azure Static Web Apps

Applikasjonsinnstillinger i Azure Static Web Apps gjelder per miljø, så et nytt forhåndsvisningsmiljø kan få disse bryterne konfigurert uavhengig av ethvert annet miljø, med den samme rekkefølgen (tilgjengelighet først, deretter katalog) som er dokumentert over. az staticwebapp appsettings set treffer ett miljø med --environment-name, og den fletter inn i miljøets eksisterende innstillinger i stedet for å erstatte dem, slik at arvede databaseinnstillinger blir stående. Forhåndsvisningsmiljøet må finnes først, så kjør kommandoene etter at utrullingen for pull requesten er ferdig.

# 1. tilgjengelighet først
az staticwebapp appsettings set -n <SWA_NAVN> -g <RESSURSGRUPPE> \
  --environment-name <PR_NUMMER> \
  --setting-names DELEGATED_MEMBER_ORDERING_ENABLED=true

# 2. eksponering etterpå
az staticwebapp appsettings set -n <SWA_NAVN> -g <RESSURSGRUPPE> \
  --environment-name <PR_NUMMER> \
  --setting-names DELEGATED_MEMBER_CATALOG_ENABLED=true

# verifiser, uten å skrive ut noen annen innstillingsverdi
az staticwebapp appsettings list -n <SWA_NAVN> -g <RESSURSGRUPPE> \
  --environment-name <PR_NUMMER> \
  --query "properties.{ordering:DELEGATED_MEMBER_ORDERING_ENABLED,catalog:DELEGATED_MEMBER_CATALOG_ENABLED}"

Kjør aldri az staticwebapp appsettings list uten --query-filteret i en delt terminal eller en CI-logg: den skriver ut alle innstillingsverdier, inkludert databasenøkler. set sladder sin egen utskrift.

En endring av innstillingene starter miljøets administrerte funksjoner på nytt. Gi det inntil omtrent to minutter og kjør verifiseringen på nytt før du konkluderer med at noe feilet. Ny utrulling er ikke nødvendig, fordi begge bryterne leses fra process.env ved hvert kall.

VITE_DELEGATED_MEMBER_CATALOG_ENABLED krever ingen manuell handling for et forhåndsvisningsmiljø for pull request. Som en del av v1.2.0-produksjonsutrullingen bygger utrullingsarbeidsflyten nå denne bryteren som true både for pull request-bygg og for push til main. Et nytt forhåndsvisnings- eller annet ikke-produksjonsmiljø viser fortsatt ingenting før DELEGATED_MEMBER_CATALOG_ENABLED også er satt i det samme miljøet, så rekkefølgen (tilgjengelighet først, deretter katalog) dokumentert over gjelder fortsatt for ethvert miljø der disse bryterne er avslått som standard. Når pull requesten lukkes, slettes forhåndsvisningsmiljøet og innstillingene med det.

Kompatibilitet med eksisterende data. Ingen migrering kreves for å aktivere disse bryterne. Delegeringer opprettet før denne utrullingen lagrer ikke den nyere godkjenningsrettigheten eksplisitt; en aktiv delegering behandles som om den har den, slik at eksisterende partnerdelegeringer fungerer umiddelbart når bryterne slås på.

Tokenlevetid og databasetidsgrenser

REFRESH_TOKEN_TTL_DAYS godtar et positivt heltall dager. Manglende verdi, desimaltall, ikke-numeriske verdier og verdier under 1 bruker standarden på 90 dager.

COSMOS_REQUEST_TIMEOUT_MS konverteres til et tall og sendes til Cosmos SDK bare når COSMOS_KEY velger en nøkkelbasert klient, for eksempel den lokale emulatoren. Hvis variabelen mangler eller ikke gir et brukbart tall ulik null, endrer ikke applikasjonen SDK-tidsgrensen. Klienter med administrert identitet bruker ikke denne applikasjonsinnstillingen.

E-post (innloggingslenker)

E-poster med innloggingslenker sendes via Resend. Leverandøren tilbyr for tiden et gratisnivå for transaksjons-e-post ved lavt volum. Se Resend-priser for gjeldende måneds- og dagsgrenser før du planlegger produksjonsvolum.

Variabel	Beskrivelse
RESEND_API_KEY	Din Resend API-nøkkel
FROM_EMAIL	Avsenderadresse, helst en verifisert produksjonsavsender. Koden bruker onboarding@resend.dev som reserveverdi
FRONTEND_URL	Frontend-URL for magic link-tilbakekall

Utvikling uten Resend

• Hvis RESEND_API_KEY ikke er satt, hoppes e-postleveringen over. Utviklingsloggen inneholder bare et maskert sammendrag av mottaker, emne og avsender. Den inneholder ikke innloggingslenken, verifiseringskoden eller e-postinnholdet.
• Det vanlige API-svaret er fortsatt generisk og viser ingen innloggingslenke.
• API-et returnerer devLink og devCode bare i beskyttet E2E-testmodus. Modusen krever E2E_TEST_MODE=true, en lokal FRONTEND_URL med localhost og en NODE_ENV som ikke er produksjon. Den hopper over e-postlevering og skal ikke brukes som produksjonsoppførsel.

Bytte e-postleverandør

E-postlogikken er isolert i api/src/shared/email.ts. For å bytte leverandør, erstatt Resend SDK med SendGrid, Azure Communication Services, osv.

Konfigurasjon av tilbakemeldinger

• Sett VITE_BETA_FEEDBACK=true når frontend bygges for å vise tilbakemeldingsknappen og menypunktet. Alle andre verdier, inkludert manglende verdi, lar grensesnittet være deaktivert.
• GITHUB_FEEDBACK_TOKEN er valgfri. Når variabelen er satt, forsøker API-et å opprette en GitHub-sak etter at tilbakemeldingen er lagret i Cosmos DB. Lagring av tilbakemeldingen er fortsatt hovedoperasjonen hvis oppretting av GitHub-saken mislykkes.

Databaseoppsett

Kjør oppsettskriptet for å opprette alle containere med riktige TTL-innstillinger:

cd api
npx ts-node scripts/setup-database.ts

Dette oppretter:

• rateLimits-container med TTL aktivert for automatisk opprydding
• authTokens-container med TTL for opprydding av utløpte tokener
• Alle andre applikasjonscontainere

Eksempel local.settings.json

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "",
    "FUNCTIONS_WORKER_RUNTIME": "node",
    "COSMOS_ENDPOINT": "https://localhost:8081",
    "COSMOS_KEY": "<din-emulator-nøkkel>",
    "COSMOS_DATABASE": "choirtickets",
    "JWT_SECRET": "dev-secret-change-in-production",
    "FRONTEND_URL": "http://localhost:5173"
  }
}

Produksjon

I produksjon setter du JWT_SECRET til en sterk tilfeldig verdi og konfigurerer RESEND_API_KEY og FROM_EMAIL for e-postlevering.

---

Neste: Azure-utrulling · Se også: Lokal utvikling