fix(cors): defer parameter resolution in https callables and requests

[inlined]

Description

Fixes an issue where passing a parameterized CORS origin (Expression) to HTTPS functions attempts to evaluate the parameter at global module definition time rather than request runtime. This also updates V1 https.onRequest to accept an options object (HttpsOptions) supporting custom cors configuration, aligning with V2.

Scenarios Tested

• Added unit tests in spec/common/providers/https.spec.ts verifying that resolveCorsOrigin successfully extracts runtime values from StringParam and ListParam Expressions.
• Added unit tests in spec/v1/providers/https.spec.ts verifying V1 onRequest correctly enforces custom CORS options and does not crash when passed an Expression.
• Added unit tests in spec/v2/providers/https.spec.ts verifying passing Expressions to onRequest and onCall CORS options does not cause definition-time crashes.
• Ran the full npm test suite to ensure no regressions.

[gemini-code-assist]

Code Review

This pull request adds support for configuring CORS options using parameter expressions (such as defineString and defineList) in both v1 and v2 HTTPS and callable functions. It introduces a resolveCorsOrigin helper to dynamically resolve these expressions per request and includes comprehensive unit tests. The review feedback highlights a critical bug in src/v1/function-builder.ts where arguments is incorrectly used inside an arrow function, which will cause runtime failures. Additionally, it is recommended to use typeof checks instead of arguments.length in src/v1/providers/https.ts for better robustness and consistency.

[gemini-code-assist]

Using arguments inside an arrow function is a critical bug. Arrow functions do not bind their own arguments object; instead, they inherit it from the enclosing scope (in this case, the get https() getter, which has 0 arguments). Consequently, arguments.length === 1 will always evaluate to false, causing the function to incorrectly treat a single handler argument as options and leaving the actual handler undefined, leading to runtime crashes when requests are received.

To fix this, check typeof optsOrHandler === "function" instead of relying on arguments.length.

Suggested change

	onRequest: (
	optsOrHandler:
	| https.HttpsOptions
	| ((req: https.Request, resp: express.Response) => void | Promise<void>),
	handler?: (req: https.Request, resp: express.Response) => void | Promise<void>
	) => {
	let opts: https.HttpsOptions;
	let userHandler: (req: https.Request, resp: express.Response) => void | Promise<void>;
	if (arguments.length === 1) {
	opts = {};
	userHandler = optsOrHandler as any;
	} else {
	opts = optsOrHandler as https.HttpsOptions;
	userHandler = handler!;
	}
	return https._onRequestWithOptions(userHandler, { ...this.options, ...opts } as any);
	},
	onRequest: (
	optsOrHandler:
	| https.HttpsOptions
	| ((req: https.Request, resp: express.Response) => void | Promise<void>),
	handler?: (req: https.Request, resp: express.Response) => void | Promise<void>
	) => {
	let opts: https.HttpsOptions;
	let userHandler: (req: https.Request, resp: express.Response) => void | Promise<void>;
	if (typeof optsOrHandler === "function") {
	opts = {};
	userHandler = optsOrHandler;
	} else {
	opts = optsOrHandler as https.HttpsOptions;
	userHandler = handler!;
	}
	return https._onRequestWithOptions(userHandler, { ...this.options, ...opts } as any);
	},

[gemini-code-assist]

For consistency and robustness, it is highly recommended to check typeof optsOrHandler === "function" instead of relying on arguments.length. This avoids potential issues if the function is refactored into an arrow function in the future and aligns with modern TypeScript practices.

Suggested change

	export function onRequest(
	handler: (req: Request, resp: express.Response) => void | Promise<void>
	optsOrHandler:
	| HttpsOptions
	| ((req: Request, resp: express.Response) => void | Promise<void>),
	handler?: (req: Request, resp: express.Response) => void | Promise<void>
	): HttpsFunction {
	return _onRequestWithOptions(handler, {});
	let opts: HttpsOptions;
	let userHandler: (req: Request, resp: express.Response) => void | Promise<void>;
	if (arguments.length === 1) {
	opts = {};
	userHandler = optsOrHandler as any;
	} else {
	opts = optsOrHandler as HttpsOptions;
	userHandler = handler!;
	}
	return _onRequestWithOptions(userHandler, opts as DeploymentOptions);
	}
	export function onRequest(
	optsOrHandler:
	| HttpsOptions
	| ((req: Request, resp: express.Response) => void | Promise<void>),
	handler?: (req: Request, resp: express.Response) => void | Promise<void>
	): HttpsFunction {
	let opts: HttpsOptions;
	let userHandler: (req: Request, resp: express.Response) => void | Promise<void>;
	if (typeof optsOrHandler === "function") {
	opts = {};
	userHandler = optsOrHandler;
	} else {
	opts = optsOrHandler as HttpsOptions;
	userHandler = handler!;
	}
	return _onRequestWithOptions(userHandler, opts as DeploymentOptions);
	}

[wandamora]

LGTM, Jetski suggested some edge cases you can add to your testing. Maybe it's useful.

1. Expression Resolution Failure / Missing Environment Variables:

   Scenario: What happens when a StringParam is used for CORS, but the corresponding environment variable is completely missing or empty at runtime?
   Test: Assert that resolveCorsOrigin handles this gracefully (e.g., throws a clear error, falls back to blocking CORS, or uses a default value) rather than letting the function crash silently.

2. CORS Option with Empty Array/List Expression:

   Scenario: A ListParam is resolved, but it evaluates to an empty list [].
   Test: Verify that an empty list doesn't cause runtime exceptions in the cors library and behaves as expected (typically denying all origins).

[inlined]

1 Should be impossible but neither hurt to test against.

[sceee]

Hi @inlined thanks for merging this - just wanted to quickly double check as it seems to be like this - the correct way of setting a RegExp value from the .env is to use defineString, right?

E.g.
.env file:

ALLOWED_CORS_ORIGINS="^http:\/\/.+\.example\.com$"

Code:

export const corsOrigins = defineString('ALLOWED_CORS_ORIGINS')

export const myFn = onCall<XYZ, Promise<ABC>>(
  {
    cors: corsOrigins,
  },
  async (request) => {
      // Handle...
  },
)

So defineString correctly interprets the value as "string regex", right?

[sceee]

Hi @inlined thanks for merging this - just wanted to quickly double check as it seems to be like this - the correct way of setting a RegExp value from the .env is to use defineString, right?

E.g. .env file:

ALLOWED_CORS_ORIGINS="^http:\/\/.+\.example\.com$"

Code:

export const corsOrigins = defineString('ALLOWED_CORS_ORIGINS')

export const myFn = onCall<XYZ, Promise<ABC>>(
  {
    cors: corsOrigins,
  },
  async (request) => {
      // Handle...
  },
)

So defineString correctly interprets the value as "string regex", right?

Hi @inlined , unfortunately, when testing this it turned out this setup breaks CORS because the string is not parsed as RegExp but just as string (which browsers can't interpred), so it's unfortunately not working as I intended to use it.
When trying to work around this limitation, I faced another issue which I created #1943 for.

Can you think of another solution that would work and would allow to dynamically define CORS origins based on the environment?