Skip to content

Commit 48c2333

Browse files
xyosxyos
authored
Merge branch 'main' into docs/api-namespace-jsdoc
2 parents 0d107aa + d1b4900 commit 48c2333

329 files changed

Lines changed: 41619 additions & 27544 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎.changeset/audit-logging-defaults.md‎

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
---
2+
"@aws-blocks/core": minor
3+
"@aws-blocks/blocks": minor
4+
---
5+
6+
fix(core): warn at synth when a durable stack disables API Gateway access logging
7+
8+
A synth-time warning now fires on every durable (non-`DESTROY` removal policy)
9+
stack that has API Gateway access logging disabled — this includes the default
10+
`BlocksPresets.production` posture, where `accessLogging` is off by default. The
11+
warning id is `blocks:apigateway:access-logging-disabled`.
12+
13+
Because it is a warning, ordinary `cdk synth`/`deploy` still succeed, but
14+
`cdk synth`/`deploy --strict` treat warnings as errors and fail until you either
15+
opt in or acknowledge it.
16+
17+
Opt in by setting `accessLogging: true` in the backend's `defaults` (this also
18+
turns on S3 server access logging for any FileBucket, each getting its own log
19+
bucket). To keep it off deliberately, acknowledge the warning on the stack or
20+
backend returned by `create()`, after it resolves:
21+
22+
```ts
23+
const backend = await BlocksBackend.create(stack, 'Blocks', { /* … */ });
24+
Annotations.of(backend).acknowledgeWarning('blocks:apigateway:access-logging-disabled');
25+
```
26+
27+
Acknowledging on the `App` before `create()` does not suppress it.

‎.changeset/auth-basic-revoke-on-signout.md‎

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
---
2+
"@aws-blocks/bb-auth-basic": minor
3+
"@aws-blocks/auth-common": minor
4+
"@aws-blocks/blocks": patch
5+
---
6+
7+
AuthBasic now revokes the session token server-side on sign-out. Each session
8+
JWT carries a unique `jti`; `signOut` records that id on a revocation list (in
9+
the existing codes store, expiring with the token) so a replayed cookie is
10+
rejected even though the JWT is still unexpired and signature-valid. The
11+
umbrella `@aws-blocks/blocks` is bumped because the bundled `bb-auth-basic`
12+
README/DESIGN docs it mirrors have changed.
13+
14+
This is a `minor` (not `patch`) bump because it adds exported error constants —
15+
`AuthBasicErrors.SessionRevoked` (`SessionRevokedException`, thrown by
16+
`requireAuth` for a signed-out/revoked session, vs `SessionExpiredException` for
17+
an absent/aged-out one) and `AuthBasicErrors.SignOutIncomplete`
18+
(`SignOutIncompleteException`, 503, thrown when the revocation write fails) —
19+
and documents a new throwable name on the shared `BlocksAuth.requireAuth`
20+
contract in `@aws-blocks/auth-common`.
21+
22+
`signOut` always clears the local cookie (so sign-out on this device never
23+
leaves the user stuck signed in), even when the server-side revocation write
24+
fails; in that case it throws a stable `SignOutIncompleteException` rather than
25+
the raw SDK error, so no `$metadata`/ARNs leak to the client.
26+
27+
Legacy-surface behavior change: the deprecated `buildApi().signOut` previously
28+
always resolved to `{ success: true }`; it now awaits `signOut` and so can
29+
reject with `SignOutIncompleteException` (503) when the revocation write fails.
30+
Only direct `buildApi` callers are affected — the `createApi()` state machine
31+
catches it into the `AuthState.error` field.
32+
33+
Operator note: the `codes` store gains `{ ttl: true }`. For an already-deployed
34+
AuthBasic app this is an in-place DynamoDB TimeToLive enablement (an `UpdateTable`)
35+
on the next `cdk deploy` — no data migration, and correctness does not depend on
36+
the reaper (reads filter expired items regardless). Caveat: DynamoDB rejects
37+
another `UpdateTimeToLive` on the same table for ~1 hour after a change, so if an
38+
unrelated resource fails in the same deploy, CloudFormation rollback (which
39+
disables TTL) — or a deploy → rollback → redeploy within that hour — can land in
40+
`UPDATE_ROLLBACK_FAILED`. Deploy AuthBasic apps with this in mind.

‎.changeset/auth-common-submitauthaction.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
---
2+
"@aws-blocks/auth-common": patch
3+
---
4+
5+
Add `submitAuthAction(api, input)` — a browser-only helper that calls `setAuthState` and then drives the local auth notification so `onAuthChange` subscribers and `AuthenticatedContent` re-render on a real signed-in/signed-out transition. This closes the `setAuthState` → `onAuthChange` reactivity gap where a custom auth UI stayed stale unless it also called `broadcastAuthChange` by hand. The framework's own `Authenticator` now routes every action through `submitAuthAction` as the single notifier, so there is no double-fire; challenge/retriable states are not broadcast. Fixes #185.

‎.changeset/blocks-umbrella-submitauthaction.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
---
2+
"@aws-blocks/blocks": minor
3+
---
4+
5+
Re-export `submitAuthAction` from the umbrella `@aws-blocks/blocks/ui` entry point, alongside the existing `Authenticator`, `AuthenticatedContent`, `AccountMenuBar`, `onAuthChange`, and `broadcastAuthChange` exports. Consumers building a custom auth UI on `@aws-blocks/blocks` can now import the helper that pairs `setAuthState` with the local auth notification — so `onAuthChange` subscribers and `AuthenticatedContent` re-render on a real signed-in/signed-out transition — without reaching into `@aws-blocks/auth-common` directly. Relates to #185; addresses #208 review feedback.

‎.changeset/container-compute-no-local-docker.md‎

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
---
2+
"@aws-blocks/bb-container-compute": patch
3+
"@aws-blocks/bb-compute": patch
4+
"@aws-blocks/core": patch
5+
---
6+
7+
Container compute no longer requires a local Docker daemon to deploy. Instead of
8+
building a container image from a Dockerfile (`ContainerImage.fromAsset`, which
9+
shells out to `docker build`), the task now runs a stock public Node image
10+
(`public.ecr.aws/docker/library/node:24-slim` by default) verbatim via
11+
`fromRegistry`, and the application code is shipped as an S3 asset and fetched at
12+
container start by a dependency-free bootstrap using the task IAM role. `cdk
13+
deploy` of a container-backed `Compute`/`AsyncJob` now needs no Docker.
14+
15+
The container base image moves from Node 22 to Node 24 to match the framework's
16+
default Lambda runtime (`DEFAULT_NODE_RUNTIME`).
17+
18+
The `image` option on a `container` `Compute` keeps its name but its contract is
19+
clarified: it is the runtime image, used verbatim (no build), and must provide a
20+
Node 24 runtime; your application code is always injected by Blocks at boot, not
21+
baked into the image.

‎.changeset/core-config-bucket-ssl-logging.md‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
---
2+
"@aws-blocks/core": minor
3+
"@aws-blocks/blocks": minor
4+
---
5+
6+
fix(core): enforce TLS, enable versioning, and add access logging on the config bucket
7+
8+
The shared config bucket (`BlocksConfigBucket`, holding `blocks-config.json`) now sets `enforceSSL: true` (a bucket policy denying non-TLS access), `versioned: true` (making the pre-existing noncurrent-version expiration rule effective, so an overwritten config stays recoverable for ~24h before the 1-day noncurrent expiry removes it), and delivers S3 server access logs to a new dedicated, locked-down log bucket. Because `blocks-config.json` is derived from the CDK app, the durable way to restore a prior config is to redeploy; the ~24h window is only a short in-transit safety net. The log bucket resolves its removal policy and log-retention from the stack `defaults` (production ⇒ RETAIN + 365-day expiry, sandbox ⇒ DESTROY + 7-day expiry), so production access logs are not torn down with the stack. Every stack now synthesizes an additional log bucket + bucket policy + versioning config.
9+
10+
Note: enabling bucket versioning is one-way — S3 can only move a versioned bucket to Suspended, never back to unversioned — so reverting this change leaves the config bucket in the Suspended state rather than unversioned.

‎.changeset/core-declare-lib-dynamodb-devdep.md‎

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
---
2+
"@aws-blocks/core": patch
3+
"@aws-blocks/blocks": patch
4+
---
5+
6+
chore(core): declare the `@aws-sdk` devDependencies its tests already use
7+
8+
`packages/core`'s `client-user-agent.test.ts` dynamically imports
9+
`@aws-sdk/client-dynamodb` and `@aws-sdk/lib-dynamodb` but never declared them,
10+
relying on the packages being hoisted to the root by `bb-kv-store`/
11+
`bb-distributed-table`. A dependency bump that reshuffles hoisting drops that
12+
incidental resolution and breaks `core`'s build. Declare both as
13+
devDependencies so the imports resolve regardless of hoisting.

‎.changeset/cron-job-mock-far-schedules.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
---
2+
"@aws-blocks/bb-cron-job": patch
3+
---
4+
5+
The local CronJob mock no longer runs a cron job on a date its schedule doesn't match. A schedule with no match within a year (such as `cron(0 0 29 2 ? *)`) used to fire an hour later; a fire time more than about 24.8 days away (such as a yearly schedule) used to fire right away because it overflowed `setTimeout`. Both now wait for the real fire time.

‎.changeset/db-pull-env-upsert.md‎

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
---
2+
"@aws-blocks/bb-data": patch
3+
---
4+
5+
fix(bb-data): `db pull` no longer erases other settings in `.env.local` and `.env.production`
6+
7+
`db pull` used to replace the whole env file with a single `SUPABASE_DB_URL=` line, deleting anything else you kept there (for example `AWS_PROFILE` or an OIDC client secret). Because these files are usually gitignored, those values couldn't be recovered. `db pull` now adds or updates only the `SUPABASE_DB_URL` entry and keeps every other line, comment, blank line, line ending and the file's permissions. An existing `SUPABASE_DB_URL` is updated in place rather than duplicated: the whole line after `=` is rewritten, so nothing from the old value is left behind (including the tail of an unquoted password containing `#` written by an earlier `db pull`), and a comment at the end of that line is not kept. A connection string that needs quoting (for example one containing `#`) is quoted so it reads back intact. As before, the file is written in place, so its owner, group and ACLs are kept too. If `.env.local` can't be updated safely (for example, the change would alter how another entry is read), `db pull` now stops before connecting or generating any files, instead of failing after writing them. When `.env.production` already exists, the production prompt now asks whether to update its `SUPABASE_DB_URL` entry and says that other settings are kept.

‎.changeset/demo-dsql-canary-e2e.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
---
2+
"@aws-blocks/create-blocks-app": patch
3+
---
4+
5+
Add a DistributedDatabase (SQL) atomic-transfer e2e to the demo template, raising daily canary coverage to 12/20 Building Blocks.

0 commit comments

Comments
 (0)