Skip to main content
Este sistema automaticamente adiciona headers customizados a todas as requisições para a API do Asaas, permitindo identificar o canal/parceria de origem das transações.

Variáveis de Ambiente Necessárias

Adicione as seguintes variáveis no seu arquivo .env:

Headers Enviados Automaticamente

Quando habilitado (ASAAS_ORIGIN_HEADERS_ENABLED=true), o sistema envia os seguintes headers em todas as chamadas para a API do Asaas:
  • Origin: Identificador fixo do canal (valor de ASAAS_ORIGIN_HEADER)
  • Origin-Channel-Access-Token: Token de acesso do canal (valor de ASAAS_CHANNEL_ACCESS_TOKEN)
  • Origin-Channel-External-Reference: Referência dinâmica do tenant/loja atual

Como funciona a referência externa (Origin-Channel-External-Reference)

O sistema obtém automaticamente a referência do tenant/loja através da seguinte ordem de prioridade:
  1. Sessão web: Se session('loja_id') existir, usa formato loja_{id}
  2. Domínio/Host: Se for multi-tenant por domínio, extrai do host (ex: tenant_minhaloja para minhaloja.seudominio.com)
  3. Fallback: Usa valor de ASAAS_DEFAULT_EXTERNAL_REFERENCE se configurado

Arquivos Modificados

Novos Arquivos

  • app/Services/OriginChannelHeaders.php - Serviço responsável por gerar os headers dinâmicos
  • docs/asaas_origin_headers.md - Esta documentação

Arquivos Modificados

  • config/asaas.php - Adicionadas configurações dos headers de origem
  • app/Providers/AppServiceProvider.php - Registrado o serviço no container
  • vendor/leopaulo88/asaas-sdk-laravel/src/Support/AsaasClient.php - Modificado getHeaders() para incluir headers dinâmicos

Exemplo de Headers Enviados

Com as configurações:
E uma sessão com loja_id = 42, todas as requisições para o Asaas incluirão:

Desabilitação

Para desabilitar os headers customizados, simplesmente configure:

Logs e Debug

O sistema loga avisos em caso de erros na geração de headers, mas falha silenciosamente para não quebrar o fluxo de pagamentos. Verifique logs com:

Importante

⚠️ Modificação do Vendor: O arquivo vendor/leopaulo88/asaas-sdk-laravel/src/Support/AsaasClient.php foi modificado. Recomendações:
  • Considerar fazer um fork do pacote e usar nova versão
  • Ou usar patches do Composer (cweagans/composer-patches)
  • Documentando esta modificação para atualizações futuras do pacote

Implementação Detalhada

Esta seção documenta todos os passos realizados para implementar o sistema de headers de canal.

1. Criação do Serviço Principal

Arquivo: app/Services/OriginChannelHeaders.php Serviço responsável por gerar os headers dinâmicos baseado na configuração e contexto atual:

2. Configuração no arquivo config/asaas.php

Adicionada nova seção de configuração:

3. Registro no Container Laravel

Arquivo: app/Providers/AppServiceProvider.php Adicionado no método register():

4. Modificação do SDK Asaas

Arquivo: vendor/leopaulo88/asaas-sdk-laravel/src/Support/AsaasClient.php Modificado o método getHeaders():

5. Arquivo de Exemplo de Configuração

Arquivo: .env.asaas.example

6. Atualização da Documentação Principal

Arquivo: docs/asaas_module.md Adicionada seção sobre headers de canal na documentação principal do módulo Asaas.

7. Fluxo de Funcionamento

  1. Inicialização: Sistema verifica se ASAAS_ORIGIN_HEADERS_ENABLED=true
  2. Detecção do Tenant: Obtém referência do tenant atual via:
    • session('loja_id') → formato loja_{id}
    • Host/domínio → formato tenant_{subdomain} ou host_{domain}
    • Fallback → valor de ASAAS_DEFAULT_EXTERNAL_REFERENCE
  3. Geração de Headers: Monta array com 3 headers customizados
  4. Injeção Automática: Todos os métodos do SDK (payments()->create(), pixQrCode(), etc.) incluem os headers
  5. Logging: Erros são logados mas não quebram o fluxo de pagamento

8. Exemplo de Requisição Resultante

Com configuração:
E sessão com loja_id = 42, uma requisição típica para criar pagamento incluiria:

9. Verificação e Testes

Para testar se está funcionando:
  1. Verificar configuração:
  1. Testar geração de headers:
  1. Monitorar logs:

10. Considerações de Segurança

  • Token sensível: ASAAS_CHANNEL_ACCESS_TOKEN deve ser tratado como credencial secreta
  • Fallback seguro: Sistema falha silenciosamente para não quebrar pagamentos
  • Logs limitados: Não loga dados sensíveis, apenas erros de configuração
  • Validação: Headers só são enviados se todas as validações passarem

11. Manutenção e Atualizações

Importante para futuras atualizações do pacote leopaulo88/asaas-sdk-laravel:
  1. Backup da modificação: Salve o diff do AsaasClient.php
  2. Monitor de atualizações: Use composer show leopaulo88/asaas-sdk-laravel
  3. Reaplicação: Após atualizar o pacote, reaplicar a modificação no getHeaders()
Opções recomendadas:
  • Fork do repositório: git clone + modificação + composer.json apontando para seu fork
  • Patches do Composer: Use cweagans/composer-patches para automatizar a aplicação

Melhorias Implementadas (Janeiro 2025)

Esta seção documenta as melhorias de segurança e robustez para multi-tenant implementadas após análise detalhada do sistema.

1. Priorização Correta de Detecção de Tenant

Problema Identificado: A detecção de tenant via session('loja_id') pode falhar em contextos CLI/queue, e o fallback para subdomínio podia extrair dados incorretos de domínios customizados de clientes. Solução Implementada: Nova ordem de prioridade robusta no método getCurrentTenantReference():
Benefícios:
  • current_loja tem prioridade máxima (funciona em todos os contextos)
  • ✅ Subdomínio só é extraído de domínios *.nortgraf.com.br (evita problemas com domínios customizados)
  • ✅ Fallback garantido para CLI, jobs sem contexto
  • ✅ Logging melhorado com trace apenas em ambiente local

2. Atualização de Variáveis de Ambiente com Nomenclatura Melhorada

Problema: Nomes de variáveis ambíguos que podiam causar confusão. Solução: Nomenclatura mais clara e consistente:
Atualização na Configuração:

3. Debug Logging Temporário para Validação

Objetivo: Confirmar que headers estão sendo aplicados corretamente em produção. Implementação: Debug logging temporário no AsaasClient.php:
⚠️ Importante: Este logging é temporário e deve ser removido após validação em produção.

4. Exemplo de Configuração Atualizada

Arquivo: .env.asaas.example (atualizado)

5. Validação em Produção

Plano de Teste Direto:
  1. Configurar ambiente:
  1. Criar pagamento PIX sandbox:
  1. Verificar logs:
Expected Output:

6. Benefícios das Melhorias

Robustez Multi-tenant:
  • ✅ Funciona consistentemente em web, CLI, queue, jobs
  • ✅ Nunca “chuta” subdomínio de domínios customizados do cliente
  • ✅ Sempre tem fallback funcional
Segurança:
  • ✅ Logging limitado, não expõe tokens
  • ✅ Graceful degradation se serviço falhar
  • ✅ Validações de contexto antes de extract
Manutenibilidade:
  • ✅ Nomes de variáveis mais claros
  • ✅ Debug temporário para validação
  • ✅ Documentação completa atualizada
Compatibilidade:
  • ✅ Backwards-compatible com configurações existentes
  • ✅ Zero breaking changes no comportamento
  • ✅ Funciona com todos os métodos existentes do Asaas

7. Próximos Passos

  1. ✅ Implementação completa - Todas as melhorias aplicadas
  2. 🟡 Validação produção - Criar PIX sandbox e confirmar logs
  3. 🟡 Remover debug logs - Após confirmação que funciona
  4. 🟡 Documentar fork/patch - Para manutenção do vendor modification