canopycms-cdk 0.0.66-int.83 → 0.0.66-int.84

package/dist/constructs/asset-support.d.ts

@@ -217,13 +217,17 @@ export declare class AssetSupport extends Construct {
     /** Effective advisory upload-size cap (see `AssetSupportProps.maxUploadBytes`). */
     readonly maxUploadBytes: number;
     private readonly behaviors;
-    /** Distributions `attachTo` has already wired -- see that method's duplicate check. */
-    private readonly attachedDistributions;
     constructor(scope: Construct, id: string, props: AssetSupportProps);
     private buildBehaviors;
     /**
      * The two CloudFront behavior configs this system needs.
      *
+     * If you use this rather than `attachTo` -- which now takes an `overrides`
+     * parameter, so needing per-behavior options is no longer a reason to fall
+     * back here -- you own the ordering, and you should assert it: read the
+     * SYNTHESIZED template's `CacheBehaviors` array index, not your own source
+     * object, since the property is about emitted order.
+     *
      * Prefer `attachTo(distribution)` or `CanopyCmsDistribution`'s
      * `assetSupport` prop, which attach these to a distribution in the only
      * safe order automatically. This method exists as the escape hatch for a
@@ -250,6 +254,33 @@ export declare class AssetSupport extends Construct {
      * 0x2A, `t` = 0x74), so alphabetizing the keys reproduces exactly this
      * failure, with no synth or deploy error to catch it.
      *
+     * `overrides` is merged into BOTH behaviors, and exists because without it
+     * this method is unusable by exactly the adopters who most need the ordering
+     * guarantee. A distribution that runs a viewer-request function on every
+     * behavior - tier basic-auth, most commonly - needs the asset behaviors to
+     * carry that same `functionAssociations`, or `/assets/*` is anonymously
+     * readable on an authenticated tier. Before this parameter existed such an
+     * adopter had to fall back to `assetBehaviors()` plus two hand-ordered
+     * `addBehavior` calls: the precise shape this method was added to eliminate,
+     * re-entered while believing ordering was handled upstream, which is worse
+     * than never having had the method. (`responseHeadersPolicy` is the same
+     * story for a repo with a shared security-headers policy.)
+     *
+     * Merged into both rather than per-behavior on purpose: applying one set to
+     * both is what preserves the ordering guarantee as the only thing this
+     * method decides. A caller who genuinely needs the two behaviors to differ
+     * has left this method's remit and should use `assetBehaviors()` - and keep
+     * their own ordering assertion.
+     *
+     * Typed `Partial<AddBehaviorOptions>` because that is exactly what
+     * `addBehavior(pattern, origin, behaviorOptions?)` accepts - `origin` is a
+     * POSITIONAL argument there, so `BehaviorOptions` (which is
+     * `AddBehaviorOptions` plus `origin`) would let a caller pass a key the call
+     * silently ignores. Measured, because the first version of this comment
+     * claimed the opposite: widening the parameter and passing an `origin`
+     * override changes nothing in the emitted template, so this narrowing
+     * prevents a confusing no-op rather than a broken origin group.
+     *
      * Needs a concrete `cloudfront.Distribution` - `addBehavior` is an instance
      * method on that class, not on `IDistribution` (what an imported/looked-up
      * distribution reference gives you). For a distribution built entirely
@@ -258,7 +289,7 @@ export declare class AssetSupport extends Construct {
      * directly instead and list `/assets/t/*` before `/assets/*` yourself - see
      * `AssetCloudFrontBehaviors`'s doc comment.
      */
-    attachTo(distribution: cloudfront.Distribution): void;
+    attachTo(distribution: cloudfront.Distribution, overrides?: Partial<cloudfront.AddBehaviorOptions>): void;
     /**
      * Grant the CMS/editor principal (the CMS Lambda's role, typically) the
      * exact permissions `S3AssetStore` (packages/canopycms/src/assets/store-s3.ts)

package/dist/constructs/asset-support.js

@@ -111,6 +111,24 @@ const TRANSFORM_OUTPUT_RETENTION = Duration.days(180);
 const TRANSFORM_CACHE_MIN_TTL = Duration.seconds(0);
 const TRANSFORM_CACHE_DEFAULT_TTL = Duration.days(1);
 const TRANSFORM_CACHE_MAX_TTL = Duration.days(365);
+/**
+ * Distributions that already carry the asset behaviors, tracked at MODULE level
+ * rather than per instance.
+ *
+ * Per-instance (the first version of this) only caught the same `AssetSupport`
+ * attaching twice. Two `AssetSupport` constructs attaching to one distribution
+ * slipped through and synthesized
+ * ['/assets/t/*','/assets/*','/assets/t/*','/assets/*'] - the identical
+ * duplicate-path-pattern deploy failure the guard exists to convert into a
+ * synth error. There is no legitimate form of that: both instances attach the
+ * same two patterns, so the second is always wrong regardless of which
+ * construct owns it.
+ *
+ * A `WeakSet` keyed on the distribution object, so it holds no reference that
+ * would outlive the construct tree and cannot leak across CDK apps in a test
+ * process.
+ */
+const distributionsWithAssetBehaviors = new WeakSet();
 /**
  * The two CloudFront path patterns the asset system's behaviors are keyed
  * under, derived from `PREFIXES` above (the single source of truth for these
@@ -156,8 +174,6 @@ export const ASSET_BEHAVIOR_SPREAD_MISTAKE_KEYS = ['assets', 'assetsTransform'];
 export class AssetSupport extends Construct {
     constructor(scope, id, props) {
         super(scope, id);
-        /** Distributions `attachTo` has already wired -- see that method's duplicate check. */
-        this.attachedDistributions = new WeakSet();
         // Fail closed before anything else: refuse to build a stack around a
         // transform Lambda whose code asset was never verified to contain the
         // linux/arm64 sharp binary. Without this, `pnpm test` (whose
@@ -346,6 +362,12 @@ export class AssetSupport extends Construct {
     /**
      * The two CloudFront behavior configs this system needs.
      *
+     * If you use this rather than `attachTo` -- which now takes an `overrides`
+     * parameter, so needing per-behavior options is no longer a reason to fall
+     * back here -- you own the ordering, and you should assert it: read the
+     * SYNTHESIZED template's `CacheBehaviors` array index, not your own source
+     * object, since the property is about emitted order.
+     *
      * Prefer `attachTo(distribution)` or `CanopyCmsDistribution`'s
      * `assetSupport` prop, which attach these to a distribution in the only
      * safe order automatically. This method exists as the escape hatch for a
@@ -374,6 +396,33 @@ export class AssetSupport extends Construct {
      * 0x2A, `t` = 0x74), so alphabetizing the keys reproduces exactly this
      * failure, with no synth or deploy error to catch it.
      *
+     * `overrides` is merged into BOTH behaviors, and exists because without it
+     * this method is unusable by exactly the adopters who most need the ordering
+     * guarantee. A distribution that runs a viewer-request function on every
+     * behavior - tier basic-auth, most commonly - needs the asset behaviors to
+     * carry that same `functionAssociations`, or `/assets/*` is anonymously
+     * readable on an authenticated tier. Before this parameter existed such an
+     * adopter had to fall back to `assetBehaviors()` plus two hand-ordered
+     * `addBehavior` calls: the precise shape this method was added to eliminate,
+     * re-entered while believing ordering was handled upstream, which is worse
+     * than never having had the method. (`responseHeadersPolicy` is the same
+     * story for a repo with a shared security-headers policy.)
+     *
+     * Merged into both rather than per-behavior on purpose: applying one set to
+     * both is what preserves the ordering guarantee as the only thing this
+     * method decides. A caller who genuinely needs the two behaviors to differ
+     * has left this method's remit and should use `assetBehaviors()` - and keep
+     * their own ordering assertion.
+     *
+     * Typed `Partial<AddBehaviorOptions>` because that is exactly what
+     * `addBehavior(pattern, origin, behaviorOptions?)` accepts - `origin` is a
+     * POSITIONAL argument there, so `BehaviorOptions` (which is
+     * `AddBehaviorOptions` plus `origin`) would let a caller pass a key the call
+     * silently ignores. Measured, because the first version of this comment
+     * claimed the opposite: widening the parameter and passing an `origin`
+     * override changes nothing in the emitted template, so this narrowing
+     * prevents a confusing no-op rather than a broken origin group.
+     *
      * Needs a concrete `cloudfront.Distribution` - `addBehavior` is an instance
      * method on that class, not on `IDistribution` (what an imported/looked-up
      * distribution reference gives you). For a distribution built entirely
@@ -382,7 +431,7 @@ export class AssetSupport extends Construct {
      * directly instead and list `/assets/t/*` before `/assets/*` yourself - see
      * `AssetCloudFrontBehaviors`'s doc comment.
      */
-    attachTo(distribution) {
+    attachTo(distribution, overrides) {
         // `addBehavior` does not dedupe, and these calls bypass
         // `CanopyCmsDistribution`'s own synth-time guard because they run after
         // that distribution is constructed. So attaching twice -- passing the
@@ -391,18 +440,40 @@ export class AssetSupport extends Construct {
         // ['/assets/t/*','/assets/*','/assets/t/*','/assets/*'] and fails at
         // deploy time when CloudFront rejects the duplicate patterns. Refuse it
         // here instead, where the message can say which two routes collided.
-        if (this.attachedDistributions.has(distribution)) {
+        if (distributionsWithAssetBehaviors.has(distribution)) {
             throw new Error(`AssetSupport: attachTo() was already called for this distribution. Each pattern ` +
                 `would be attached twice and CloudFront rejects duplicate path patterns at deploy ` +
                 `time. This usually means the distribution was given CanopyCmsDistribution's ` +
                 `\`assetSupport\` prop (which calls attachTo for you) as well as an explicit ` +
                 `attachTo() call -- keep one.`);
         }
-        this.attachedDistributions.add(distribution);
+        distributionsWithAssetBehaviors.add(distribution);
+        // Drop explicitly-`undefined` keys before merging. A spread copies own
+        // enumerable keys INCLUDING ones whose value is undefined, so
+        // `{ ...transformRest, ...{ cachePolicy: undefined } }` deletes the
+        // construct's choice and lets CDK substitute its own default - which is a
+        // DIFFERENT default. Measured: `cachePolicy: undefined` swaps this
+        // behavior's custom policy (TRANSFORM_CACHE_MIN_TTL = 0, which exists
+        // solely to stop the oversized-output redirect loop documented above) for
+        // the managed CACHING_OPTIMIZED and its 1-second min TTL; and
+        // `viewerProtocolPolicy: undefined` downgrades BOTH behaviors from
+        // redirect-to-https to allow-all, serving assets over plain HTTP.
+        //
+        // This is not a contrived input - it is what forwarding optional props
+        // produces: `attachTo(dist, { cachePolicy: props.maybePolicy })` with the
+        // prop unset. It typechecks (every AddBehaviorOptions field is already
+        // optional), synthesizes and deploys clean.
+        const definedOverrides = Object.fromEntries(Object.entries(overrides ?? {}).filter(([, value]) => value !== undefined));
         const { origin: transformOrigin, ...transformRest } = this.behaviors.assetsTransform;
         const { origin: assetsOrigin, ...assetsRest } = this.behaviors.assets;
-        distribution.addBehavior(ASSETS_TRANSFORM_PATH_PATTERN, transformOrigin, transformRest);
-        distribution.addBehavior(ASSETS_PATH_PATTERN, assetsOrigin, assetsRest);
+        distribution.addBehavior(ASSETS_TRANSFORM_PATH_PATTERN, transformOrigin, {
+            ...transformRest,
+            ...definedOverrides,
+        });
+        distribution.addBehavior(ASSETS_PATH_PATTERN, assetsOrigin, {
+            ...assetsRest,
+            ...definedOverrides,
+        });
     }
     /**
      * Grant the CMS/editor principal (the CMS Lambda's role, typically) the

package/dist/constructs/cms-distribution.d.ts

@@ -66,9 +66,15 @@ export interface CanopyCmsDistributionProps {
      * Attach `AssetSupport`'s CloudFront behaviors (`/assets/*` and
      * `/assets/t/*`) to the distribution this construct builds, in the only
      * safe order - see `AssetSupport.attachTo()`'s doc comment for why the
-     * order matters. Equivalent to calling
-     * `assetSupport.attachTo(distribution)` yourself right after construction,
-     * but with nothing to forget.
+     * order matters. Calls `assetSupport.attachTo(distribution)` for you right
+     * after construction, with nothing to forget.
+     *
+     * NOT fully equivalent to calling `attachTo` yourself: this path cannot pass
+     * that method's `overrides` argument. If the asset behaviors need
+     * per-behavior options - a viewer-request function for tier auth being the
+     * motivating case, since without it `/assets/*` is anonymously readable on
+     * an authenticated tier - drop this prop and call
+     * `assetSupport.attachTo(this.distribution, { ... })` after construction.
      *
      * Prefer this over passing `assetSupport.assetBehaviors()` through
      * `additionalBehaviors` by hand - that stays available as an escape hatch

package/dist/constructs/cms-distribution.js

@@ -20,7 +20,21 @@ import { ASSETS_PATH_PATTERN, ASSETS_TRANSFORM_PATH_PATTERN, ASSET_BEHAVIOR_SPRE
 function mergeBehaviors(defaults, caller, attachingAssetSupport) {
     if (!caller)
         return defaults;
-    const uncollided = Object.fromEntries(Object.entries(defaults).filter(([pattern]) => !(pattern in caller)));
+    // Compare NORMALIZED keys here too. CloudFront treats a leading '/' as
+    // optional, so a caller passing `'_next/static/*'` did not displace this
+    // construct's own `'/_next/static/*'` default and both were emitted -- two
+    // behaviors CloudFront reads as the same pattern, which it rejects at
+    // deploy. Same reason the hazard checks below normalize.
+    const callerPatterns = new Set(Object.keys(caller).map(normalizePathPattern));
+    const uncollided = Object.fromEntries(Object.entries(defaults).filter(([pattern]) => !callerPatterns.has(normalizePathPattern(pattern))));
+    const normalizedCallerKeys = Object.keys(caller).map(normalizePathPattern);
+    const duplicateCallerPattern = normalizedCallerKeys.find((pattern, i) => normalizedCallerKeys.indexOf(pattern) !== i);
+    if (duplicateCallerPattern !== undefined) {
+        throw new Error(`CanopyCmsDistribution: additionalBehaviors has two keys that CloudFront reads as the ` +
+            `same path pattern (${JSON.stringify(duplicateCallerPattern)} with and without its ` +
+            `leading '/'). CloudFront rejects duplicate path patterns at deploy time. Keep one ` +
+            `spelling.`);
+    }
     const merged = { ...uncollided, ...caller };
     assertNoAssetBehaviorOrderingHazards(merged, attachingAssetSupport);
     return merged;
@@ -68,6 +82,7 @@ function mergeBehaviors(defaults, caller, attachingAssetSupport) {
 function normalizePathPattern(pattern) {
     return pattern.startsWith('/') ? pattern.slice(1) : pattern;
 }
+/** See the three-hazard list documented above `normalizePathPattern`. */
 function assertNoAssetBehaviorOrderingHazards(merged, attachingAssetSupport) {
     const keys = Object.keys(merged).map(normalizePathPattern);
     const assetsPattern = normalizePathPattern(ASSETS_PATH_PATTERN);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "canopycms-cdk",
-  "version": "0.0.66-int.83",
+  "version": "0.0.66-int.84",
   "description": "AWS CDK constructs and EC2 worker for CanopyCMS deployment",
   "license": "MIT",
   "repository": {
@@ -30,7 +30,7 @@
   "peerDependencies": {
     "aws-cdk-lib": "^2.260.0",
     "constructs": "^10.0.0",
-    "canopycms": "0.0.66-int.83"
+    "canopycms": "0.0.66-int.84"
   },
   "peerDependenciesMeta": {
     "aws-cdk-lib": {
@@ -54,8 +54,8 @@
     "tsx": "^4.19.0",
     "typescript": "^5.6.3",
     "vitest": "^4.1.0",
-    "canopycms": "0.0.66-int.83",
-    "canopycms-auth-clerk": "0.0.66-int.83"
+    "canopycms": "0.0.66-int.84",
+    "canopycms-auth-clerk": "0.0.66-int.84"
   },
   "scripts": {
     "build": "rm -rf dist && tsc && node ../../scripts/add-js-extensions.mjs dist",