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
PRE_HANDOUT_SALES_ENABLED	❌	Eksakt true tillater nye salg før utlevering og innføring av ny utleveringsmodell innenfor valgt modus	false
PRE_HANDOUT_SALES_MODE	❌	Eksakt allowlist eller all-organizations. Aktivering for alle krever uttrykkelig all-organizations og at aktiveringsbryteren er på. Ugyldige verdier avviser aktivering.	allowlist
PRE_HANDOUT_SALES_ORGANIZATION_ALLOWLIST	❌	Kommaseparerte kanoniske organisasjons-ID-er. I listemodus må både eier og selger være oppført; manglende eller tom liste avviser aktivering. Ugyldige eller dupliserte oppføringer i en ikke-tom liste avviser aktivering i begge moduser.	Tom, ingen organisasjoner tillatt i listemodus
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
SALES_CORRECTIONS_EXTERNAL_WRITE	❌	Aktiverer enhetlige eksterne/Ticketmaster-korrigeringer for organisasjonsadministratorer i et uttrykkelig konfigurert miljø	false
PLATFORM_SUPER_ADMIN_CORRECTION_IMPERSONATION	❌	Den eksakte verdien true tillater den eksisterende administratorøkten med revisjonsspor. Gir ikke direkte skrivetilgang for superadministratorer.	false
PLATFORM_SUPER_ADMIN_EXTERNAL_CORRECTIONS_WRITE	❌	Den eksakte verdien true, sammen med SALES_CORRECTIONS_EXTERNAL_WRITE=true, tillater direkte Ticketmaster-korrigeringer som den innloggede superadministratoren.	false

Organisasjonsavgrenset forhåndsvisning av salg før utlevering

For avgrenset forhåndsvisning konfigurerer du bare API-miljøet for den nummererte pull requesten, ikke standardmiljøet for produksjon. Godkjent organisasjon for manuell testing er Nordlys Koret, docs-nordlys-koret:

PRE_HANDOUT_SALES_ENABLED=true
PRE_HANDOUT_SALES_MODE=allowlist
PRE_HANDOUT_SALES_ORGANIZATION_ALLOWLIST=docs-nordlys-koret

Serveren leser disse innstillingene ved hver avgjørelse. ID-er følger de eksisterende normaliseringsreglene: fjern omkringliggende mellomrom, bruk små bokstaver og avvis ugyldige eller dupliserte oppføringer. En tom liste tillater aldri alle organisasjoner i listemodus. Eier og selgende organisasjon hentes fra bestillingen på serveren, ikke fra klientens organisasjonsvalg eller forespørselskropp. Denne ene oppføringen aktiverer ikke delegerte salg mellom organisasjoner. Eksisterende autorisasjon og kapasitetskontroller gjelder fortsatt.

Bygg forhåndsvisningens frontend med VITE_MEMBER_SALES_REPORTING_ENABLED=true. Klientinnstillingen omgår ikke serverkontrollene. Hvis organisasjonen fjernes fra listen eller aktivering slås av, forblir eksisterende utleveringsdata, utlevering av allerede solgte billetter og avstemmingskontroller tilgjengelige. Vanlig eldre utlevering bruker fortsatt sin eksisterende rute uten ny datamodell.

Kompatibilitet i delt database: brukeren har uttrykkelig valgt den eksisterende delte databasen, ikke en separat database. Bare brukeren utfører manuelle endringer i docs-nordlys-koret; agenter endrer ikke disse dataene. Organisasjonskontrollen begrenser nye data, men gjør ikke at eldre produksjonskode forstår nye testbestillinger. Ikke bruk eldre endringsruter i produksjon på bestillinger som har tatt i bruk den nye modellen. Deaktivering fjerner eller nedgraderer ikke lagrede data.

Aktivering av salg før utlevering for alle organisasjoner

Denne modusen krever at API-et som støtter PRE_HANDOUT_SALES_MODE, er rullet ut. API-et i v1.12.0 støtter bare organisasjoner i tillatelseslisten. Ikke bruk jokertegn, lag en liste over alle organisasjoner eller sett den nye modusen før støtten er rullet ut. Etter gjennomgang, utgivelse og bekreftet utrulling i produksjon aktiverer du bare standardmiljøet for produksjon med:

PRE_HANDOUT_SALES_ENABLED=true
PRE_HANDOUT_SALES_MODE=all-organizations

Flett inn innstillingene, slik at alle andre innstillinger beholdes. Ikke endre forhåndsvisningens allowlist-modus eller listen med Nordlys Koret. I global modus er listen valgfri og begrenser ikke hvilke organisasjoner som kan bruke funksjonen. En ikke-tom liste må likevel være gyldig og ikke ha dupliserte ID-er etter normalisering. Både eierens og selgerens ID fra serveren må være gyldige. Ugyldig modus, jokertegn i listen og feilformaterte innstillinger avviser nye salg før utlevering og innføring av den nye utleveringsmodellen.

Dette styrer utrulling, ikke autorisasjon. Kontroller av medlemskap, rolle, bestillingseier, gjeldende delegeringstillatelser, kapasitet og avstemming er uendret. Nye organisasjoner kan bruke funksjonen uten en ny innstillingsendring. Bekreft bare disse utrullingsinnstillingene med en filtrert leseoperasjon. Ikke opprett reelle kundesalg for å teste aktivering.

Sett PRE_HANDOUT_SALES_ENABLED=false for å stoppe nye salg før utlevering og innføring av den nye modellen. Bestillinger som allerede bruker modellen, forblir synlige og kan fortsatt håndteres med utlevering av solgte billetter og avstemming. allowlist-modus gjeninnfører begrensningen for både eier og selger og krever en gyldig, ikke-tom liste. Ingen av disse endringene fjerner lagrede utleveringsdata.

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
VITE_SALES_CORRECTIONS_EXTERNAL_WRITE_ENABLED	❌	Sett til den eksakte strengen 'true' for å vise den enhetlige korrigeringsflyten for eksterne/Ticketmaster-salg. API-autorisasjon og serverens kjøretidsbryter gjelder fortsatt.	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å.

Utrulling av korrigeringer for eksterne salg

Visning av korrigeringsflyten i produksjon for #504 ble godkjent 2026-09-17. Utrullingsarbeidsflyten bygger VITE_SALES_CORRECTIONS_EXTERNAL_WRITE_ENABLED som true både for forhåndsvisninger av pull requests og for push til main. Lokale og egendefinerte bygg er fortsatt deaktivert som standard med mindre verdien er den eksakte strengen true. For å skjule flyten igjen setter du frontend-byggeflagget til false, bygger på nytt og ruller ut på nytt. Dette deaktiverer ikke API-et eller endrer kjøretidsbryteren.

SWA-utrullingshandlingen kan ikke lagre en variabel fra byggesteget som en administrert API-applikasjonsinnstilling. SALES_CORRECTIONS_EXTERNAL_WRITE er fortsatt en separat API-bryter per miljø. Når den er av, er enhetlig korrigeringsskriving utilgjengelig uansett hva frontend viser. Denne frontend-utrullingen endrer ikke API-kjøretidsinnstillinger i produksjon. API-autorisasjon og organisasjonsisolasjon gjelder fortsatt. For et separat godkjent, nummerert forhåndsvisningsmiljø kan en autentisert Azure-operatør konfigurere og verifisere bare dette miljøets API-bryter:

az staticwebapp appsettings set -n <SWA_NAVN> -g <RESSURSGRUPPE> \
  --environment-name <PR_NUMMER> \
  --setting-names SALES_CORRECTIONS_EXTERNAL_WRITE=true

# verifiser bare denne ikke-hemmelige bryteren; skriv aldri ut alle innstillinger
az staticwebapp appsettings list -n <SWA_NAVN> -g <RESSURSGRUPPE> \
  --environment-name <PR_NUMMER> \
  --query "properties.{externalWrite:SALES_CORRECTIONS_EXTERNAL_WRITE}"

Kommandoene over gjelder bare forhåndsvisning: ikke utelat --environment-name eller bruk dem mot produksjon. API-innstillinger i produksjon administreres separat. Direkte korrigeringer fra plattform-superadministratorer er deaktivert som standard. Ticketmaster-priser og -gebyrer forblir uforanderlige.

Direkte Ticketmaster-korrigeringer som superadministrator

PLATFORM_SUPER_ADMIN_EXTERNAL_CORRECTIONS_WRITE krever den eksakte verdien true, og SALES_CORRECTIONS_EXTERNAL_WRITE må også være true. PLATFORM_SUPER_ADMIN_CORRECTION_IMPERSONATION beholder sin eksisterende betydning for administratorøkter og aktiverer aldri direkte tilgang alene.

Etter uavhengig kontroll og verifisert utrulling av grensesnittet må en operatør uttrykkelig godkjenne aktivering i riktig miljø. Denne endringen aktiverer ingen produksjonsinnstillinger. Andre skrivefunksjoner og brytere for allokeringsreparasjon skal ikke endres.

Superadministratoren bruker samme Korriger salg-dialog som en organisasjonsadministrator, uten administratorvelger eller opprettelse av en impersoneringsøkt. Revisjonssporet registrerer den faktiske innloggede superadministratoren som aktør med en uttrykkelig plattformrolle.

GET /api/management/sales/correction-capabilities?organizationId=... er skrivebeskyttet og returnerer standard svarformat med canCorrectExternalSales og reason (available, feature-disabled eller not-authorized). Forespørselen endrer ikke billetter, korrigeringer eller økter. Ugyldig autentisering, organisasjonskontekst og tjenestefeil returneres som feil, ikke som en skjult avvisning av tilgang.

API-et kontrollerer gjeldende legitimasjon, databaserolle, organisasjon og begge skrivebrytere ved lagring, gjentakelse og gjenoppretting. Eventuelt eksisterende øktbevis må være gyldig, men velger aldri en annen aktør i den direkte flyten. Vis som bruker forblir skrivebeskyttet, og foreldet øktbevis avvises. Pris- og gebyrverdier, partisjonsisolasjon, ETags og idempotent regnskapsføring bevares. Deaktivering av skriving fjerner ikke autorisert lesetilgang til historikken.

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