Regras de edge

Todo servidor roda um proxy web na frente das suas aplicações. As regras abaixo rodam ali, antes de a requisição chegar à sua aplicação. A maioria delas fica na aba Configurações → Rede da aplicação e passa a valer a partir do próximo deploy.

Você também pode configurá-las pela API (GET / PATCH /api/applications/:id/edge, que mescla as chaves enviadas) ou na seção edge: do railyard.yml.

Acesso: senha e regras de IP

O card Acesso faz três coisas:

• Senha. Coloca uma senha na aplicação, útil para stagings, previews e ferramentas administrativas.
• Regras de IP. Permita ou bloqueie um endereço ou faixa CIDR por linha. Todo o resto recebe 403.
• Sem indexação. Os endereços padrão e de preview já informam aos mecanismos de busca para não indexá-los.

HTTPS

Todo endereço recebe um certificado, e uma visita por HTTP simples é redirecionada para HTTPS por padrão. Desative Redirecionar HTTP para HTTPS só para clientes que não conseguem seguir um redirecionamento, como dispositivos antigos ou verificadores de integridade — nesse caso a aplicação também passa a responder em HTTP simples. Vale a partir do próximo deploy.

Redirecionamentos e rewrites

Redirecionamentos e rewrites aceita uma regra por linha. As regras são verificadas em ordem, e a primeira que casar vence:

/blog/* https://blog.example.com/*{?query} 301
www.shop.example.com/promo /sale 302
/old-api/* /api rewrite
/legacy /new

• Tipo: 301, 302, 307, 308 ou rewrite. O padrão é 301.
• Host: um host antes do caminho limita a regra a esse endereço.
• * no final: carrega o restante do caminho junto.
• Rewrites servem outro caminho da mesma aplicação e mantêm a query string.

Você pode ter até 100 regras. Elas ficam desativadas durante o modo de manutenção.

Headers de resposta e CORS

Headers de resposta e CORS aceita uma regra de header por linha:

* X-Frame-Options: DENY
/api/* Cache-Control: no-store
* -X-Powered-By

Um header que você define substitui o valor enviado pela sua aplicação, e -Nome remove o header. Você pode ter até 50 regras.

Para CORS, liste as origens permitidas, depois os métodos, os headers, se credenciais são permitidas e um max age. O proxy responde às requisições preflight por conta própria, então elas nunca chegam à aplicação, e outras origens não recebem headers de CORS. Se a aplicação tiver senha, os preflights recebem 401.

Páginas de erro e manutenção

• Página de erro: exibida com o status real (502, 503 ou 504) quando a aplicação não consegue responder porque travou, está reiniciando ou está lenta demais.
• Página de manutenção: substitui a página padrão do Railyard enquanto o modo de manutenção está ativo. Ainda é enviada com status 503.

Cole o HTML, ou informe um endereço e o Railyard copia a página a cada vez que você salvar. Uma página copiada pode ter até 64 KB e precisa estar em um endereço público. As páginas são servidas como estão, então use URLs completas para imagens e estilos. O card tem um link de preview.

Roteamento por caminho

Roteamento por caminho serve esta aplicação sob um caminho do endereço de outra aplicação, como shop.example.com/api para a sua API, em um único certificado. Você pode manter o prefixo ou removê-lo.

As duas aplicações precisam estar no mesmo servidor. Roteamento entre servidores ainda não é suportado.

Seu próprio certificado SSL

Configurações → Domínios → Seus próprios certificados. Cole um certificado PEM, com a cadeia, e uma chave PEM sem criptografia. Antes de salvar, o Railyard verifica que:

• a chave combina com o certificado;
• o certificado está válido agora;
• ele cobre pelo menos um dos endereços da aplicação.

O certificado e a chave são armazenados criptografados, e a API nunca retorna a chave. O card mostra a data de expiração, e o Railyard envia um aviso pelas regras de aplicação fora do ar da aplicação 14 dias antes de expirar. Depois que expira, o próximo deploy volta a usar certificados automáticos do Let’s Encrypt. Certificados não podem ficar no railyard.yml, porque isso colocaria uma chave privada no git.

API: GET / POST /api/applications/:id/certificates, DELETE …/certificates/:cert_id.

Limite de taxa (beta)

Limite de taxa define requisições por minuto por IP de cliente. Você pode definir um limite para a aplicação inteira e adicionar limites por caminho:

Whole app: 600
/login 10
/api/* 120

Uma requisição acima do limite recebe 429 com Retry-After.

Beta: limites de taxa precisam da imagem de proxy de edge própria do Railyard no servidor, e essa imagem ainda está sendo distribuída gradualmente. Até seu servidor tê-la, as regras são salvas mas não são aplicadas, e tanto o card quanto o log do deploy avisam isso.

Outros limites:

• Os contadores vivem na memória de cada servidor, então uma aplicação em vários servidores tem o limite aplicado por servidor.
• Atrás do Cloudflare ou de outro proxy, todo visitante aparece com o IP desse proxy, e proxies confiáveis ainda não podem ser configurados.

Bloqueio por país (beta)

Países aceita códigos de país de duas letras em duas listas, permitir apenas e bloquear. UNK cobre endereços sem país conhecido.

• Visitantes bloqueados recebem 403, antes dos limites de taxa, redirecionamentos ou da sua aplicação.
• Endereços privados e internos sempre passam.
• Os dados de país vêm do DB-IP Lite.

Isso precisa da mesma imagem de proxy de edge do limite de taxa, então hoje as regras são salvas mas não aplicadas. A mesma limitação do Cloudflare se aplica.

Firewall de aplicação web (beta)

Firewall de aplicação web passa toda requisição pelo OWASP Core Rule Set (injeção de SQL, XSS e as outras categorias do CRS) antes de ela chegar à aplicação. Defina o modo: Desativado (sem verificações), Detectar (registrado nos logs, nunca bloqueia — use isso primeiro para ver o que seria bloqueado) ou Bloquear (aplicado de fato, retorna 403). Vale a partir do próximo deploy; uma requisição bloqueada aparece nos logs da aplicação como qualquer outro bloqueio de edge.

Isso precisa da mesma imagem de proxy de edge do limite de taxa e do bloqueio por país, então até seu servidor tê-la a configuração é salva mas não aplicada, e o card avisa isso.

Cloudflare e rede privada

Colocar o CDN e o WAF do Cloudflare na frente do endereço de uma aplicação, a malha privada entre aplicações, e um único certificado para um domínio wildcard inteiro estão em Rede.

Domínios personalizados

Adicionar domínios, pares com/sem www, subdomínios wildcard e a verificação de propriedade estão em Domínios.