Add CORS support to allow the new IATI Dashboard (SPA) to call the API

[simon-20]

Summary

Add Cross-Origin Resource Sharing (CORS) support to Register Your Data so that
the new IATI Dashboard frontend (a browser-based SPA) can make authenticated calls to this API.

Background / Motivation

The new IATI Dashboard frontend is going to be a single-page application. It will authenticate users via SSO (Authorization Code flow with PKCE) and call Register Your Data with a Bearer token. Because the SPA runs in the browser on a different origin than the API, the browser's Same-Origin Policy will block the calls unless the API explicitly permits that origin via CORS.

Requirements

1. Configure CORS on the FastAPI app using the built-in CORSMiddleware
   (fastapi.middleware.cors.CORSMiddleware).
2. The set of allowed origins should be config-driven, not hardcoded:
   • sourced from application configuration (e.g. an environment variable/or a list in a file), with a sensible default - check if FastAPI has a best practice on this;
   • extendable without a code change when new origins need access
3. Response headers must permit:
   • the Authorization header (the SPA sends Authorization: Bearer <token> on every request);
   • the HTTP methods used by the SPA (at minimum GET, POST, OPTIONS).
4. Preflight OPTIONS requests must be answered successfully without requiring authentication, so that browser preflights do not receive a 401.
5. Do not use Access-Control-Allow-Origin: *; just fix to IATI Dashboard.
6. allow_credentials should be False unless the API moves to cookie-based auth (current SPA integration uses Bearer tokens).

Acceptance Criteria

• CORS middleware is in place, reading allowed origins from configuration.
• With the production origin configured, IATI Dashboard can make authenticated (Bearer-token) requests to the API from the browser.
• Preflight (OPTIONS) requests return a 2xx without credentials and include the expected Access-Control-Allow-* headers.
• Requests from origins not in the allowlist remain blocked by the browser (i.e. the Access-Control-Allow-Origin header is not emitted for them).
• Existing server-to-server clients are unaffected.

Out of Scope

• Authentication/token validation changes — the SPA will use the same SSO tokens the API already accepts.

[arobson-ods]

Hi @simon-20 - Can I check list of HTTP verbs? If POST shouldn't it have PATCH, PUT, DELETE too? If readonly then just GET.

[simon-20]

Hi @simon-20 - Can I check list of HTTP verbs? If POST shouldn't it have PATCH, PUT, DELETE too? If readonly then just GET.

Yes, this was a mistake in my specification: all of the verbs used by the API should be covered.