Formulários de conta e anexos

Conta do comprador V3

O papel opcional account compõe todas as views da conta. buyer.enabled controla atalhos, buyer.authenticated separa entrada/cadastro de conta/pedidos/saída. Layouts precisam passar buyer: buyer ao render isolado do header. Nunca use o objeto como autorização: ela é refeita no servidor. Revisões sem o papel recebem buyer.enabled: false; não criar URLs de conta incondicionais.

Formulários declaram method="post" e action interno correspondente à API, inclusive saída, dados pessoais, pagamento e checkout. Sem runtime, o envio nativo é recusado pelo servidor sem colocar credenciais na URL. Formulários usam data-buyer-form, data-buyer-action (entrar, cadastro, dados, endereco, senha, sair, pagamento) e data-buyer-csrf="{{ buyer.csrf }}". Pagamento acrescenta data-buyer-order. Inclua botão type="submit", mensagem data-buyer-message com role/status e spans data-buyer-error="nomeDoCampo" vinculados por aria-describedby. Inputs de senha usam autocomplete current-password ou new-password; data-buyer-toggle="idDoInput" alterna visibilidade e aria-pressed. Senhas novas devem ser obrigatórias e limitar a 128 caracteres, sem minlength de 12 nem descrição dessa exigência. O servidor aceita senha não vazia e preserva espaços; login mantém o limite histórico de entrada. Rótulos são sempre visíveis. O runtime controla processamento, bloqueio de repetição, foco no erro, requests same-origin e redirecionamento. Não envia forms em preview.

reCAPTCHA v2 nos formulários públicos da conta

O reCAPTCHA está temporariamente suspenso pela plataforma. O endpoint /api/account/captcha retorna { "provider": "recaptcha-v2", "enabled": false }. O runtime oculta o container, não carrega o SDK do Google e não envia X-Recaptcha-Token; as quatro operações de conta dispensam a verificação. CSRF, validação de origem e demais regras de conta permanecem ativos. A suspensão é definida no servidor, não pelo tema ou pela requisição. Na prévia, o hook continua demonstrativo, sem operações reais.

Quando reativado pela plataforma, as ações entrar, cadastro, recuperar e redefinir-senha exigem reCAPTCHA v2 do tipo checkbox. Dentro do respectivo [data-buyer-form], o tema posiciona:

<div data-recaptcha></div>

Não é uma tag Liquid especial. É um ponto de montagem HTML que a IA pode colocar em qualquer posição dentro do formulário. data-recaptcha-theme="dark" e data-recaptcha-size="compact" são opcionais; os padrões são light e normal. O tema controla o espaço ao redor; a interface interna é do Google.

O runtime consulta /api/account/captcha na própria origem para obter a chave pública da plataforma e carrega uma única vez o SDK oficial, com renderização explícita. Cada formulário recebe seu próprio widget. O tema não fornece chaves, scripts nem callbacks. Se o hook estiver ausente em uma revisão antiga, o runtime acrescenta o container ao final do formulário protegido. Repetir o hook não cria vários desafios no mesmo formulário: somente o primeiro é usado.

O token segue em X-Recaptcha-Token no POST JSON da conta, junto do CSRF existente. O campo g-recaptcha-response criado pelo SDK não entra no corpo comercial. O Node valida o token com o Google e confere o hostname contra a origem da loja resolvida pelo servidor. Remover o widget, alterar atributos ou enviar diretamente ao endpoint não dispensa a verificação. A exigência não usa a antiga flag flg_habilita_captcha, nem pode ser desligada pelo tema ou por dados da requisição.

Token ausente/inválido/expirado resulta em erro 400; configuração ausente ou falha do provedor resulta em 503. Nenhuma dessas falhas executa a operação protegida. O runtime mostra mensagens em [data-buyer-message], renova o desafio após cada tentativa HTTP (inclusive erro de validação ou de rede) e trata a expiração. Os tokens são de uso único e têm validade curta, conforme a verificação oficial do Google.

Na prévia, o container mostra uma indicação demonstrativa: não consulta chaves, não carrega o Google e não envia formulários. Essa integração protege os quatro endpoints de conta listados; não cria formulários de contato nem acrescenta CAPTCHA ao checkout, pagamento ou edição de dados autenticada.

Campos e operações da conta

Entrar: email, password, returnTo. Cadastro: name, email, password, personType, returnTo e, se mantidos pelo tema conforme buyer.registrationFields (campos habilitados no painel), phone, document, birthDate, sex, stateRegistration, whereFound/whereFoundOther, o endereço (postalCode, street, number, complement, neighborhood, city, state) e custom_<id> por campo personalizado. O servidor aceita campos habilitados que o tema omite, inclusive telefone e campos personalizados obrigatórios no painel. Campos enviados são validados; um endereço enviado precisa estar completo. Campos não habilitados são recusados pelo servidor. Dados: name, phone, document, personType; e-mail é readonly e não é enviado. Senha: currentPassword, password. Saída é POST; não há GET com efeito colateral. Dados monetários dos pedidos continuam usando money.

Endereço principal: formulário separado em Meus dados com ação endereco, POST /api/account/endereco, campos postalCode, street, number, complement, neighborhood, city, state. Apenas complemento é opcional. O servidor fornece buyer.address nessas telas e no checkout, ou null se não existir endereço.

No checkout autenticado, o tema pode incluir checkbox name="saveAddress", sem checked, com texto “Salvar este endereço na minha conta”. O runtime envia booleano; ausente/desmarcado não modifica a conta. O consentimento não é preservado ao trocar de sessão. Um rascunho sem endereço digitado não apaga o principal pré-preenchido; quando há endereço digitado, ele prevalece para aquela compra. Nenhum preenchimento consulta API de CEP. Conta e pedido mantêm fotografias de endereço distintas.

Checkout atualizado acrescenta data-buyer-csrf e data-buyer-store. Links de entrada/cadastro usam data-checkout-login e retorno /checkout. O runtime preserva campos na aba por 30 minutos, sem guardar senha, sessão, token ou tentativa. A volta ganha outro UUID; exige conferir frete e enviar novamente. data-checkout-session-choice apresenta nova entrada ou escolha explícita de visitante (data-buyer-guest="true" no formulário de saída). Erros de campo recebem data-checkout-field-error; estados de identidade nunca reenviam o pedido.

O servidor persiste loja e identidade inicial em node_checkout_attempt ao fornecer checkout.attemptId. O único cookie de identidade é lv_buyer_v3; não há cookie por UUID, marcador global ou prova de tentativa no body. Revisões anteriores continuam enviando somente checkoutAttemptId. A sessão atual precisa corresponder ao proprietário inicial autenticado. Tentativas de visitante continuam visitantes, mesmo após login em outra aba. Para vincular à conta, entrar e abrir outro checkout. Logout nunca altera a identidade de uma tentativa existente.

O runtime mantém a mesma tentativa em retries, sem gerar outra automaticamente. invalid_checkout_attempt, buyer_identity_changed, session_expired e buyer_unavailable mostram recuperação explícita. O campo buyerContext de revisões anteriores é aceito mas ignorado para autorização; o Aura novo não o emite. O cookie anti-CSRF dos formulários de conta permanece independente das tentativas. SQL manual, transição de abas abertas antes do deployment, snapshots e limites de infraestrutura estão em Área do comprador V3.

Anexos de pedido

O runtime compartilhado lê [data-order-attachment-input] dentro do checkout e adiciona o arquivo à mesma requisição/tentativa de compra. Sem seleção, preserva o contrato anterior. PDF/PNG/JPEG/WebP até 5 MiB; validação definitiva no servidor. [data-order-attachment-clear] limpa somente a seleção local, sem rede.

Na conta, [data-order-attachment-form] exige data-order-id, data-attachment-id (vazio quando ausente), data-buyer-csrf, método POST e action interno explícito. O submit normal envia o arquivo; um submit com data-order-attachment-remove envia attachment null. A região [data-order-attachment-message] recebe progresso/erro. O runtime bloqueia envios simultâneos e toda mutação em preview, envia Origin/CSRF pelo contrato de conta e recarrega o pedido após sucesso. Falha de rede orienta recarregar antes de repetir. O backend compara o anexo esperado para não sobrescrever alteração concorrente.

O tema decide livremente posição, texto e apresentação. Campos e comportamento não ficam em settings nem em JSON visual. Ver contrato completo.

Recuperação de senha

O formulário data-buyer-action="recuperar" envia email e returnTo ao POST /api/account/recuperar. A resposta é genérica para contas ausentes, bloqueadas ou ambíguas. O formulário data-buyer-action="redefinir-senha" declara inputs token vazio, password e returnTo, e POST /api/account/redefinir-senha. O runtime lê o fragmento do link somente na página de redefinição, limpa esse fragmento do histórico e transmite o segredo no corpo JSON com CSRF. Não usar query string, localStorage nem GET para enviar senha/token. O backend exige novo login após concluir. buyer.recoveryEnabled indica a disponibilidade funcional.

A página de redefinição declara data-buyer-recovery-page mesmo quando o formulário está indisponível; isso permite limpar o fragmento também nesse estado.