Verifique sem um backend

Um token do Caputchin não prova nada até que algo o confirme. Normalmente esse algo é o seu próprio backend, que chama /siteverify e decide se confia na requisição. A verificação hospedada move esse passo para o Caputchin: seu formulário posta em um encaminhador do Caputchin, o Caputchin verifica o token, descarta qualquer coisa que falhe, e encaminha só os envios verificados para um destino que você escolher.

É a mesma decisão de confiança da conferência no backend, rodada do lado do Caputchin em vez do seu. O ponto é que não há chamada /siteverify para escrever nem segredo para guardar em um servidor, porque não há servidor.

A verificação hospedada é um recurso pago, disponível no Alpha em diante.

Para quem serve

A verificação hospedada existe para o caso em que rodar um backend só para conferir um token é mais do que o projeto precisa.

Se você de fato roda um backend e quer verificar ali, use verificar no seu backend em vez disso. Os dois são alternativas, não camadas.

Como funciona

O encaminhador segura o envio apenas em memória pelo instante que leva para entregá-lo. Não há armazenamento entre o post e a entrega, e o campo caputchin-token é removido antes de o payload chegar ao seu destino.

Destinos

Você configura um ou ambos por chave de site. Ativar os dois é um padrão comum: enviar para um webhook para processamento e enviar a si mesmo uma cópia por e-mail.

As entregas não são assinadas. O segredo da URL do encaminhador é o que autentica uma chamada de webhook, então mantenha a URL fora de repositórios públicos e de código do lado do cliente. O tutorial de configuração mostra o payload exato do webhook.

O que é mantido privado

A verificação hospedada segue a mesma postura de nenhum-dado-de-visitante do resto do Caputchin:

• Os envios nunca são armazenados. Eles vivem na memória do processo pela duração do encaminhamento, depois somem. Construa seu próprio registro do lado do webhook se quiser um.
• Nenhum dado sobre quem enviou é coletado. Nenhum IP, nenhum User-Agent, nenhuma impressão digital, nenhum rastreamento.
• A telemetria é só agregada. O Caputchin conta sucessos e falhas de entrega para que você veja se seus destinos estão saudáveis, nunca o conteúdo de nenhum envio. Veja estatísticas.

Como uma URL fornecida pelo cliente é mantida segura

Uma URL que os servidores do Caputchin vão chamar é um risco clássico de Server-Side Request Forgery. O encaminhador rejeita qualquer URL de webhook cujo host seja um endereço privado, de loopback, link-local ou de metadados de nuvem, tanto quando você a salva quanto de novo logo antes de cada entrega. As categorias bloqueadas incluem:

Codificações que tentam disfarçar um endereço bloqueado também são pegas: um host em inteiro decimal como http://2130706433/ ou um host em hex como http://0x7f000001/ (ambos significando 127.0.0.1) são rejeitados. Só URLs http e https são aceitas; qualquer outro esquema é recusado. O encaminhador também se recusa a seguir redirecionamentos, então um endpoint de webhook não pode desviar a chamada para um alvo interno. Uma URL bloqueada surge como um erro genérico em vez de um específico, então não pode ser usada para sondar uma rede. Seu webhook precisa, portanto, viver em uma URL https pública.

O que é deixado de fora de propósito

• Sem caixa de entrada de envios. Não há histórico armazenado de envios para navegar no painel.
• Sem adaptadores próprios de Discord, Slack, Telegram ou SMS. Só webhook e e-mail. Um webhook pode distribuir para qualquer um desses do seu lado.
• Sem upload de arquivos. O encaminhador aceita campos de texto; um envio carregando um arquivo é rejeitado.
• Sem transformação de payload. O que o formulário posta é o que seu destino recebe, mais os metadados de verificação.

Veja também

• Configurar a verificação hospedada: um passo a passo que a conecta a uma caixa de entrada de teste primeiro.
• Estatísticas de verificação hospedada: ler a saúde da entrega.
• Verificar no seu backend: a alternativa para quando você roda um servidor.