@webpieces/http-routing 0.3.378 → 0.3.380
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +4 -4
- package/src/WebpiecesConfig.d.ts +19 -6
- package/src/WebpiecesConfig.js +19 -6
- package/src/WebpiecesConfig.js.map +1 -1
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@webpieces/http-routing",
|
|
3
|
-
"version": "0.3.
|
|
3
|
+
"version": "0.3.380",
|
|
4
4
|
"description": "Decorator-based routing with auto-wiring for WebPieces",
|
|
5
5
|
"type": "commonjs",
|
|
6
6
|
"main": "./src/index.js",
|
|
@@ -22,9 +22,9 @@
|
|
|
22
22
|
},
|
|
23
23
|
"dependencies": {
|
|
24
24
|
"@inversifyjs/binding-decorators": "1.1.5",
|
|
25
|
-
"@webpieces/core-context": "0.3.
|
|
26
|
-
"@webpieces/core-util": "0.3.
|
|
27
|
-
"@webpieces/gcp-identity": "0.3.
|
|
25
|
+
"@webpieces/core-context": "0.3.380",
|
|
26
|
+
"@webpieces/core-util": "0.3.380",
|
|
27
|
+
"@webpieces/gcp-identity": "0.3.380",
|
|
28
28
|
"inversify": "7.10.4",
|
|
29
29
|
"jsonwebtoken": "9.0.2",
|
|
30
30
|
"minimatch": "10.0.1"
|
package/src/WebpiecesConfig.d.ts
CHANGED
|
@@ -4,13 +4,26 @@
|
|
|
4
4
|
*/
|
|
5
5
|
export declare class WebpiecesConfig {
|
|
6
6
|
/**
|
|
7
|
-
*
|
|
8
|
-
*
|
|
9
|
-
* lets a server that also serves its own UI answer its own api calls) and `localhost:*` (dev).
|
|
7
|
+
* The browser origins allowed to call this api CROSS-ORIGIN. Empty/unset (the default) means
|
|
8
|
+
* CORS middleware is NEVER MOUNTED — leave it that way in production.
|
|
10
9
|
*
|
|
11
|
-
*
|
|
12
|
-
*
|
|
13
|
-
*
|
|
10
|
+
* You almost never want this in production. A server that also serves its own browser app does
|
|
11
|
+
* NOT need cors: a browser applies no cors check to a same-origin request. Turning cors on grants
|
|
12
|
+
* every origin listed here the right to make CREDENTIALED cross-origin calls and READ the
|
|
13
|
+
* responses, so an unnecessary entry here is pure attack surface.
|
|
14
|
+
*
|
|
15
|
+
* Set it in exactly two cases, where the browser really is on a different origin than the api:
|
|
16
|
+
* 1. LOCAL DEV — `ng serve` on :4200 calling an api on :8080. Use the wildcard port, because the
|
|
17
|
+
* dev-server port moves: `config.corsOrigins = ['http://localhost:*'];`
|
|
18
|
+
* 2. A UI HOSTED ON A DIFFERENT HOST than the api (CDN / custom domain):
|
|
19
|
+
* `config.corsOrigins = ['https://app.example.com'];`
|
|
20
|
+
*
|
|
21
|
+
* Matching is EXACT, with one exception: a `*` in the PORT position matches any port
|
|
22
|
+
* (`http://localhost:*`). It is not a general wildcard — it never spans a host, so
|
|
23
|
+
* `http://localhost:*` will not match `http://localhost.evil.com`, and a bare `*` matches
|
|
24
|
+
* nothing. The server's OWN origin is always allowed when cors is mounted (a browser sends
|
|
25
|
+
* `Origin` on every POST, even a same-origin one, so the middleware would otherwise 403 the
|
|
26
|
+
* server's own UI).
|
|
14
27
|
*/
|
|
15
28
|
corsOrigins?: string[];
|
|
16
29
|
/**
|
package/src/WebpiecesConfig.js
CHANGED
|
@@ -7,13 +7,26 @@ exports.WEBPIECES_CONFIG_TOKEN = exports.WebpiecesConfig = void 0;
|
|
|
7
7
|
*/
|
|
8
8
|
class WebpiecesConfig {
|
|
9
9
|
/**
|
|
10
|
-
*
|
|
11
|
-
*
|
|
12
|
-
* lets a server that also serves its own UI answer its own api calls) and `localhost:*` (dev).
|
|
10
|
+
* The browser origins allowed to call this api CROSS-ORIGIN. Empty/unset (the default) means
|
|
11
|
+
* CORS middleware is NEVER MOUNTED — leave it that way in production.
|
|
13
12
|
*
|
|
14
|
-
*
|
|
15
|
-
*
|
|
16
|
-
*
|
|
13
|
+
* You almost never want this in production. A server that also serves its own browser app does
|
|
14
|
+
* NOT need cors: a browser applies no cors check to a same-origin request. Turning cors on grants
|
|
15
|
+
* every origin listed here the right to make CREDENTIALED cross-origin calls and READ the
|
|
16
|
+
* responses, so an unnecessary entry here is pure attack surface.
|
|
17
|
+
*
|
|
18
|
+
* Set it in exactly two cases, where the browser really is on a different origin than the api:
|
|
19
|
+
* 1. LOCAL DEV — `ng serve` on :4200 calling an api on :8080. Use the wildcard port, because the
|
|
20
|
+
* dev-server port moves: `config.corsOrigins = ['http://localhost:*'];`
|
|
21
|
+
* 2. A UI HOSTED ON A DIFFERENT HOST than the api (CDN / custom domain):
|
|
22
|
+
* `config.corsOrigins = ['https://app.example.com'];`
|
|
23
|
+
*
|
|
24
|
+
* Matching is EXACT, with one exception: a `*` in the PORT position matches any port
|
|
25
|
+
* (`http://localhost:*`). It is not a general wildcard — it never spans a host, so
|
|
26
|
+
* `http://localhost:*` will not match `http://localhost.evil.com`, and a bare `*` matches
|
|
27
|
+
* nothing. The server's OWN origin is always allowed when cors is mounted (a browser sends
|
|
28
|
+
* `Origin` on every POST, even a same-origin one, so the middleware would otherwise 403 the
|
|
29
|
+
* server's own UI).
|
|
17
30
|
*/
|
|
18
31
|
corsOrigins;
|
|
19
32
|
/**
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"WebpiecesConfig.js","sourceRoot":"","sources":["../../../../../packages/http/http-routing/src/WebpiecesConfig.ts"],"names":[],"mappings":";;;AAAA;;;GAGG;AACH,MAAa,eAAe;IACxB
|
|
1
|
+
{"version":3,"file":"WebpiecesConfig.js","sourceRoot":"","sources":["../../../../../packages/http/http-routing/src/WebpiecesConfig.ts"],"names":[],"mappings":";;;AAAA;;;GAGG;AACH,MAAa,eAAe;IACxB;;;;;;;;;;;;;;;;;;;;;OAqBG;IACH,WAAW,CAAY;IAEvB;;;;OAIG;IACH,iBAAiB,CAAW;IAE5B;;;OAGG;IACH,YAAY,CAAU;CACzB;AArCD,0CAqCC;AAED;;GAEG;AACU,QAAA,sBAAsB,GAAG,MAAM,CAAC,GAAG,CAAC,iBAAiB,CAAC,CAAC","sourcesContent":["/**\n * Configuration for WebPieces server.\n * Per CLAUDE.md: Data-only structure = class\n */\nexport class WebpiecesConfig {\n /**\n * The browser origins allowed to call this api CROSS-ORIGIN. Empty/unset (the default) means\n * CORS middleware is NEVER MOUNTED — leave it that way in production.\n *\n * You almost never want this in production. A server that also serves its own browser app does\n * NOT need cors: a browser applies no cors check to a same-origin request. Turning cors on grants\n * every origin listed here the right to make CREDENTIALED cross-origin calls and READ the\n * responses, so an unnecessary entry here is pure attack surface.\n *\n * Set it in exactly two cases, where the browser really is on a different origin than the api:\n * 1. LOCAL DEV — `ng serve` on :4200 calling an api on :8080. Use the wildcard port, because the\n * dev-server port moves: `config.corsOrigins = ['http://localhost:*'];`\n * 2. A UI HOSTED ON A DIFFERENT HOST than the api (CDN / custom domain):\n * `config.corsOrigins = ['https://app.example.com'];`\n *\n * Matching is EXACT, with one exception: a `*` in the PORT position matches any port\n * (`http://localhost:*`). It is not a general wildcard — it never spans a host, so\n * `http://localhost:*` will not match `http://localhost.evil.com`, and a bare `*` matches\n * nothing. The server's OWN origin is always allowed when cors is mounted (a browser sends\n * `Origin` on every POST, even a same-origin one, so the middleware would otherwise 403 the\n * server's own UI).\n */\n corsOrigins?: string[];\n\n /**\n * Record EVERY request as a test case (fixture + generated spec), instead\n * of only requests carrying the x-webpieces-recording header.\n * Intended for tests/dev - do not leave on in production.\n */\n recordingAlwaysOn?: boolean;\n\n /**\n * Directory where recorded fixtures + generated specs are written.\n * When unset, recordings are only logged.\n */\n recordingDir?: string;\n}\n\n/**\n * DI token for WebpiecesConfig injection.\n */\nexport const WEBPIECES_CONFIG_TOKEN = Symbol.for('WebpiecesConfig');\n"]}
|