Skip to content

fix(vtex): initVtexFromBlocks must not clobber decrypted creds - #456

Open
JonasJesus42 wants to merge 1 commit into
mainfrom
fix/vtex-initfromblocks-no-clobber
Open

fix(vtex): initVtexFromBlocks must not clobber decrypted creds#456
JonasJesus42 wants to merge 1 commit into
mainfrom
fix/vtex-initfromblocks-no-clobber

Conversation

@JonasJesus42

@JonasJesus42 JonasJesus42 commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Problema

initVtexFromBlocks (@decocms/apps-vtex) é usado pelos sites como hook initPlatform e roda a cada resolve (onBeforeResolve). Ele só entende appKey/appToken como string pura:

const appKey = typeof vtexBlock.appKey === "string" ? vtexBlock.appKey : undefined;

Mas o CMS guarda os secrets criptografados ({ encrypted }), que o autoconfigAppsconfigure() descriptografa de forma assíncrona via resolveSecret e instala com configureVtex. Como initVtexFromBlocks escrevia undefined no caso não-string (objeto criptografado), a cada resolve ele clobberava as credenciais descriptografadas → chamadas VTEX privilegiadas (escrita no MasterData) saíam anônimas403 "Cannot write in private fields".

Quebrou o form de lead-capture da Bagaggio (deco-sites/bagaggio-tanstack), que precisou de um workaround ensureVtexAuth() no próprio site.

Fix

Quando o appKey/appToken do bloco não é uma string usável, preservar a credencial já configurada (via getVtexConfig()) em vez de sobrescrever com undefined. Sync e mínimo; o caminho de decrypt assíncrono continua sendo responsabilidade do configure().

Teste

initVtexFromBlocks.test.ts (novo): garante que uma cred já descriptografada não é clobberada quando o bloco traz appKey como objeto { encrypted }, e que uma string ainda é aplicada normalmente.

  • ✅ suite @decocms/apps-vtex: 268 testes passam (+2 novos)
  • ✅ typecheck limpo

Impacto

Sites deixam de precisar de workaround pra escrita no MasterData quando as creds VTEX estão criptografadas no bloco deco-vtex.

🤖 Generated with Claude Code


Summary by cubic

Stops initVtexFromBlocks in @decocms/apps-vtex from overwriting decrypted VTEX credentials when blocks contain encrypted secrets, keeping VTEX calls authenticated. Fixes 403 errors on MasterData writes and removes the need for site workarounds.

  • Bug Fixes
    • Preserve existing appKey/appToken from getVtexConfig() when block values aren’t plain strings; still apply plain strings when present.
    • Added regression tests covering encrypted and plain-string cases.

Written for commit d3deb32. Summary will update on new commits.

Review in cubic

initVtexFromBlocks is wired as the site's initPlatform hook and re-runs on
every resolve (onBeforeResolve). It only reads PLAIN-STRING appKey/appToken,
but the CMS stores them encrypted ({ encrypted }) — decrypted asynchronously by
autoconfigApps' configure() via resolveSecret. Writing undefined for the
non-string case clobbered those decrypted credentials on every resolve, so
privileged VTEX calls (MasterData writes) went out anonymous and VTEX answered
403 'Cannot write in private fields'. Broke Bagaggio's lead-capture form
(deco-sites/bagaggio-tanstack), which needed a site-side ensureVtexAuth()
workaround.

When the block's appKey/appToken isn't a usable string, preserve whatever
credential is already configured (via getVtexConfig()) instead of overwriting
it. Sync, minimal; the async decrypt path stays owned by configure().

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@JonasJesus42
JonasJesus42 requested a review from a team August 7, 2026 18:48
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