fix(firebaseauth): send CORS headers on the emulator endpoints and always vary on Origin

[ianpardal]

Summary

The two follow-ups from the review on #153, both in FirebaseAuthCorsRouteFilter. One PR rather than two, since they land in the same 20-line file and its test — one commit each so they still read separately.

1. /emulator/v1 now sends CORS headers. FirebaseAuthEmulatorController (DELETE /emulator/v1/projects/{project}/accounts) is browser-callable from the Emulator UI, but the prefix was missing from PATH_PREFIXES, so its preflight came back with no Access-Control-* headers at all. firebase-tools' Auth Emulator installs cors({ origin: true }) with app.use(...) ahead of every route registration (server.ts#L137), so /emulator/v1 is covered there for the same reason the Identity Toolkit paths are.

2. Vary: Origin is now unconditional. The filter returned early on a missing Origin and emitted nothing, so an origin-less response was cacheable as if it were origin-independent. A shared cache could then hand that response — with no Access-Control-Allow-Origin on it — to a browser request that did carry an Origin, and the browser would block it. In expressjs/cors, configureOrigin pushes Vary: Origin unconditionally and applyHeaders only drops falsy header values, so Access-Control-Allow-Origin: undefined disappears while the Vary describing the negotiation stays (lib/index.js#L64-L71, #L232-L246).

Follow-up to #153 (review)

Type of change

• Bug fix (fix:)
• New feature (feat:)
• Breaking change (feat!: or fix!:)
• Docs / chore

GCP Compatibility

Both changes were read off the expressjs/cors@2.8.5 and firebase-tools sources linked above, which is the same reference #153 was built against.

Verified in a packaged build with curl:

• OPTIONS /emulator/v1/projects/p/accounts with an Origin → 204 carrying Access-Control-Allow-Origin, -Allow-Methods, -Allow-Headers and Vary: Origin, Access-Control-Request-Headers; the actual DELETE carries Access-Control-Allow-Origin and Vary: Origin.
• POST /identitytoolkit.googleapis.com/v1/accounts:signUp with no Origin → still 200, still no Access-Control-Allow-Origin, now with Vary: Origin.

One deliberate divergence left in place, since it is outside what the review asked for: expressjs/cors answers an origin-less OPTIONS with its own 204, whereas this filter still falls through to Quarkus' automatic-OPTIONS routing. A browser never sends a preflight without an Origin, and absorbing every OPTIONS on these three prefixes at Integer.MIN_VALUE + 1 is exactly the app-wide preflight absorption #153 removed from GcsCorsFilter. Happy to take it in a further PR if you'd rather match byte-for-byte.

Checklist

• ./mvnw test passes locally (969 tests, 0 failures)
• New or updated integration test added
• Commit messages follow Conventional Commits

[greptile-apps]

Greptile Summary

This PR extends Firebase Auth CORS handling to emulator endpoints and ensures responses consistently vary by request origin.

• Adds /emulator/v1/* to the Firebase Auth CORS route filter.
• Emits Vary: Origin even when the request has no Origin header.
• Adds integration coverage for emulator preflight, account deletion, and origin-less requests.

Confidence Score: 5/5

The PR appears safe to merge with focused implementation changes and appropriate integration coverage.

No actionable correctness, security, compatibility, or repository-rule violations remain in the current changes.

Important Files Changed

Filename	Overview
src/main/java/io/floci/gcp/services/firebaseauth/FirebaseAuthCorsRouteFilter.java	Extends existing CORS behavior to emulator routes and makes origin variance unconditional.
src/test/java/io/floci/gcp/services/firebaseauth/FirebaseAuthCorsRestIntegrationTest.java	Verifies CORS headers for emulator preflight and deletion requests, plus unconditional origin variance.

_{Reviews (3): Last reviewed commit: "style(firebaseauth): drop the Vary comme..." | Re-trigger Greptile}