Custom Domain

Sirva o RMM no domínio da própria organização — mdm.acme.com em vez do domínio compartilhado.

Aberta em /custom-domain.

Como funciona

1. Você declara o domínio desejado

2. O RMM gera um token de verificação único

3. Você adiciona 2 registros DNS:

   • CNAME — aponta o subdomínio pra hospedagem compartilhada

   • TXT — em _datadike-verify.<seu-domínio>, com o valor do token

4. Clica Verify DNS ownership — o RMM resolve os dois registros e libera

5. Configura o certificado TLS e o reverse proxy do seu lado (guia abaixo)

Registros DNS que a página gera

Quando você salva o domínio, a página mostra a tabela pronta pra colar no seu provedor DNS:

Host	Type	Value
mdm.acme.com	CNAME	mobile.datadike.com
_datadike-verify.mdm.acme.com	TXT	ddvfy-<token único>

Divisão de responsabilidades

O RMM controla apenas a camada de aplicação — dado um Host: mdm.acme.com entrante, ele resolve pra qual tenant pertence e serve as páginas corretas com branding, login e SSO daquele tenant.

A camada de infra (TLS + roteamento HTTP) é do cliente. Existem dois caminhos comuns:

Caminho A — Cloudflare (mais rápido)

1. Adicione o domínio na Cloudflare

2. CNAME mdm.acme.com → mobile.datadike.com

3. SSL mode: Full (strict)

4. Cloudflare emite o certificado edge gratuitamente

O reverse-proxy DataDike aceita a requisição desde que o SNI/TLS bata com o certificado da Cloudflare. Não precisa configurar nada do nosso lado.

Caminho B — reverse proxy próprio (mais controle)

1. Emita seu próprio certificado (ACM, Let's Encrypt, etc.)

2. Configure nginx / ALB / HAProxy fazendo proxy_pass pro nosso backend

3. Preserve o header Host — o RMM usa ele pra decidir qual tenant serve

Exemplo nginx:

server {
    server_name mdm.acme.com;
    ssl_certificate     /etc/ssl/mdm.acme.com.crt;
    ssl_certificate_key /etc/ssl/mdm.acme.com.key;

    location / {
        proxy_set_header Host mdm.acme.com;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_pass https://mobile.datadike.com;
    }
}

Multi-tenancy garantida

• Um domínio só pode ser reivindicado por um tenant. Se outro tentar reivindicar o mesmo, o RMM devolve 409 com mensagem explicando

• Verificação DNS obrigatória — nada é roteado antes do TXT confirmar

• O índice global de domínios mapeia mdm.acme.com → tenant específico. Se alguém subir Host header diferente, o RMM 404

Página de login em custom domain

Quando o usuário entra em mdm.acme.com, a página de login chama /api/v1/public/tenant-for-host e:

• Descobre qual tenant é dono do domínio

• Pré-preenche a workspace para o botão "Sign in with SSO"

• Mostra o branding (logo + nome) do tenant

Domínio compartilhado (mobile.datadike.com) continua funcionando pra todos — não é obrigatório usar custom domain.

O que quebra se você desativar

• Envio de convites: os links continuam usando o PUBLIC_APP_URL configurado (default mobile.datadike.com). Emails enviados enquanto o custom domain estava ativo continuam válidos, mas apontam pro custom domain — atenção se você desativar antes que os convites expirem

• SSO callback: precisa que a URL registrada no IdP bata com o domínio ativo

Sem downtime

Ligar / desligar custom domain é atômico. Sessões ativas seguem funcionando; a mudança só afeta a próxima requisição.