Skip to content

feat: Implement AAStarValidator#2

Merged
fanhousanbu merged 1 commit into
masterfrom
feat/validator-prod
Aug 10, 2025
Merged

feat: Implement AAStarValidator#2
fanhousanbu merged 1 commit into
masterfrom
feat/validator-prod

Conversation

@fanhousanbu

Copy link
Copy Markdown
Collaborator

No description provided.

@fanhousanbu fanhousanbu merged commit 34c5c21 into master Aug 10, 2025
@fanhousanbu fanhousanbu deleted the feat/validator-prod branch August 10, 2025 12:02
fanhousanbu pushed a commit that referenced this pull request Aug 10, 2025
jhfnetboy added a commit that referenced this pull request Jun 20, 2026
…322 review)

Addresses the 3 non-blocking hardening findings:
 #1 [Medium] fail-closed: in production the server KMS_API_KEY is required; the
    client x-api-key fallback is honored only outside production (dev). No key at
    all → 500 (never proxy unauthenticated). Stops a misconfigured prod deploy
    from silently lending the browser-supplied key.
 #2 [Low-Med] same-origin guard: reject requests whose Origin host != app host, so
    the privileged server key can't be borrowed by an external caller to hit
    arbitrary KMS endpoints with a forged Origin. Absent Origin (same-origin GET)
    is allowed.
 #3 [Low] body cap: reject >64KB bodies (content-length pre-check + post-read
    length check) — KMS/WebAuthn payloads are tiny.

Verified on a production build: same-origin -> 200, cross-origin -> 403,
70KB body -> 413, normal payload -> 200.
jhfnetboy added a commit that referenced this pull request Jun 20, 2026
* feat(frontend): server-side KMS proxy (inject api key, keep it out of the browser)

Replace the next.config /kms-api rewrite with a Node route handler at
app/kms-api/[...path]. It proxies browser→KMS calls and injects the KMS api key
from a SERVER env var (KMS_API_KEY), so the key no longer needs to ship in the
client bundle via NEXT_PUBLIC_KMS_API_KEY (the production-correct handling we
agreed on). Forwards the browser Origin unchanged (KMS uses it for rp.id +
allowed-origin check). Status-only logging; never logs the request body
(WebAuthn credentials), surfaces KMS error text on 4xx/5xx.

Verified end-to-end via the Cloudflare-tunnel public domain (yaa.aastar.io):
passkey registration / KMS CreateKey succeeds once KMS_ORIGIN allows the origin.

Follow-up: drop NEXT_PUBLIC_KMS_API_KEY from the frontend env so the key is
server-only (the handler already prefers KMS_API_KEY).

* harden(kms-proxy): fail-closed key + same-origin guard + body cap (PR #322 review)

Addresses the 3 non-blocking hardening findings:
 #1 [Medium] fail-closed: in production the server KMS_API_KEY is required; the
    client x-api-key fallback is honored only outside production (dev). No key at
    all → 500 (never proxy unauthenticated). Stops a misconfigured prod deploy
    from silently lending the browser-supplied key.
 #2 [Low-Med] same-origin guard: reject requests whose Origin host != app host, so
    the privileged server key can't be borrowed by an external caller to hit
    arbitrary KMS endpoints with a forged Origin. Absent Origin (same-origin GET)
    is allowed.
 #3 [Low] body cap: reject >64KB bodies (content-length pre-check + post-read
    length check) — KMS/WebAuthn payloads are tiny.

Verified on a production build: same-origin -> 200, cross-origin -> 403,
70KB body -> 413, normal payload -> 200.
jhfnetboy added a commit that referenced this pull request Jul 2, 2026
…-at-birth) (#417)

The dashboard's account-creation dialog — the real onboarding path for a fresh user — called
the legacy single-shot createWithP256Guardians, which leaves the account UNDEPLOYED. Its first
gasless transfer then reverts at prepare time (v0.22 factory can't deploy-in-initCode), and the
user is pushed into the aPNTs-gated tier-setup to pre-deploy. Beta blocker (docs/CREATE_FLOW_BETA_BUG.md #1).

Switch to the v0.23 passkey-at-birth flow the backend already exposes (and the live DEMO used):
prepare-create-with-passkey → owner device-passkey ceremony (startAuthentication) →
submit-create-with-passkey (relayer deploys). The account is DEPLOYED + wired (owner passkey +
validator) at birth, so the first transfer works with no separate pre-deploy step.

+ api.ts wrappers for the two phases. tsc + lint green.

NOTE: needs a dialog-flow validation (test stack / cos72: register → create account → confirm
deployed → transfer) before merge — critical onboarding path. Follow-ups: #2 bake default
tiers via initialTokenConfigs, #3 tier-setup self-pay fallback.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant