Skip to content

migrate: preservar Secret blocks criptografados (não inline plaintext) + doc browser-key vs server-secret #488

Description

@JonasJesus42

Observação (portal-davinci run, 2026-08-20)

Contexto

A Google Maps apiKey está em plaintext no decofile migrado (AIzaSy...). Verifiquei: o original portal-davinci já estava plaintext — então não é regressão, é dívida herdada copiada fielmente.

Dois pontos pro plugin

1. Migrate deve preservar Secret blocks como Secret (não decriptar pra plaintext)
Se um site original usa Secret blocks (valor criptografado, decriptado server-side via deco decrypt key), a migração NÃO pode decriptar pra plaintext no decofile de destino — seria regressão de segurança. Validar que deco-migrate preserva __resolveType de Secret e o ciphertext.

2. Distinguir browser-key de server-secret na doc/triager

  • Server-only (VTEX token, API secret): deve ser Secret — decriptado server-side, nunca no client.
  • Browser key (Google Maps): inerentemente pública (vai pro client no key: do script). Secret protege o decofile mas não esconde do usuário — a proteção real é HTTP referrer restriction. O triager podia sugerir: 'apiKey em plaintext no decofile → mover pra Secret; se for browser-key, garantir referrer restriction no provider'.

Runtime na CF

Secret blocks precisam da decrypt key no env/secret da CF Worker pra decriptar em runtime. Se não estiver setada → Secret vira vazio → seção quebra. O template-bootstrap deveria checar isso.


Transferida de decocms/parity#250 (bug de template do deco-migrate / @decocms/blocks-cli, fora do escopo do repo parity).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions