Começando com 4D 21, desenvolvedores 4D podem agora ter controle total sobre respostas HTTP usando um simples arquivo de configuração: HTTPRules.json. Se está procurando aumentar a segurança, otimizar a performance, ou gerenciar o acesso a recursos estáticos, essa caraterística lhe dá a flexibilidade que precisa, sem escrever uma única linha de código.
Vamos nos aprofundar nos recursos e em como usá-los.
Como as regras são aplicadas
Para ativar o recurso, coloque um arquivo HTTPRules.json na pasta Sources do seu projeto.
Como alternativa, você pode definir as regras programaticamente, definindo as regras no atributo settings. rules e passando o objeto de configurações para a função Web server. start( ). Isto substitui as regras definidas em qualquer ficheiro existente.
O conteúdo do ficheiro ou do atributo settings. rules é uma coleção de regras.
Cada regra é um objeto e é definida por um padrão de expressão regular (regexPattern) que corresponde ao URI do pedido.
As acções de uma regra são definidas pelo seu atributo:
- setHeaders: para modificar os cabeçalhos da resposta HTTP.
- addHeadersAdicionar cabeçalhos à resposta HTTP.
- removeHeaders: para remover cabeçalhos da resposta HTTP.
- denyAccess: negar ou permitir o acesso a um recurso.
- redirectRedirecionar o pedido HTTP.
- statusDefinindo um estado de resposta HTTP personalizado.
Quando o servidor HTTP é iniciado com regras, as regras tidas em conta podem ser obtidas no atributo Web server.rules.
Note-se que as regras são avaliadas sequencialmente e que podem ser aplicadas várias regras a um único pedido.
ACÇÕES DESCRIÇÃO
Definir cabeçalhos personalizados
Pode atualizar os cabeçalhos existentes da resposta HTTP e criá-los se não existirem.
Esta ação é definida pelo atributo setHeaders. Trata-se de um objeto que contém os pares de cabeçalhos de valor-chave a definir na resposta HTTP.
Exemplo:
{
"regexPattern": "/(.*)",
"setHeaders": {
"X-Frame-Options": "SAMEORIGIN",
"Content-Security-Policy": "default-src 'self'"
}
}
Com essa regra, todas as respostas HTTP vão conter cabeçalhos X-Frame-Options e Content-Security-Policycom seus valores definidos, além dos definidos pelo servidor HTTP 4D.
Adicionar cabeçalhos personalizados
Pode adicionar cabeçalhos personalizados na resposta HTTP. É particularmente útil para cabeçalhos que podem ter várias instâncias, como cookies.
Essa ação é definida pelo atributo addHeaders. Trata-se de um objeto que contém os pares de cabeçalhos chave-valor a adicionar à resposta HTTP.
Exemplo:
{
"regexPattern": "/(.*)",
"addHeaders": {
"Set-Cookie": "myCookie=123456; Max-Age=14400"
}
}
Com essa regra, todas as respostas HTTP vão conter outro cabeçalho Set-Cookie com seu valor definido, em adição aos definidos pelo servidor HTTP 4D, ou pelo seu próprio.
Remover Cabeçalhos
É possível remover cabeçalhos indesejados da resposta, como Server, que expõe a versão 4D.
Essa ação é definida pelo atributo removeHeaders. É uma coleção de chaves de cabeçalho para remover da resposta HTTP.
Exemplo:
{
"regexPattern": "/(.*)",
"removeHeaders": ["Server", "X-Frame-Options"]
}
Com esta regra, os cabeçalhos Server e X-Frame-Options serão removidos de todos os cabeçalhos de resposta HTTP.
⚠️ Alguns cabeçalhos não podem ser actualizados, adicionados ou removidos, tais como Date e Content-Length.
Negar/Permitir acesso a recursos
É possível bloquear o acesso a URIs específicos devolvendo um estado 403 Forbidden por predefinição.
Esta ação é definida pelo atributo denyAccess. Trata-se de um booleano: verdadeiro para negar o acesso e falso para o permitir.
Exemplo:
{
"regexPattern": "/private/(.*)",
"denyAccess": true,
}
Com esta regra, todos os recursos da pasta /private/ e das subpastas não serão entregues.
Também é possível permitir explicitamente o acesso a subpastas:
Exemplo:
{
"regexPattern": "/private/allowed/(.*)",
"denyAccess": false
}
Com esta regra, todos os recursos da pasta /private/allowed/ e das subpastas estão acessíveis, mesmo que a regra anterior que nega o acesso à pasta principal /private/ esteja definida.
Redirecionar pedidos
É possível redirecionar os pedidos para outro URL. Pode especificar o código de estado (301 para permanente, 302 para temporário por predefinição).
Esta ação é definida pelo atributo redirect. Trata-se de um texto que contém o URL de redireccionamento de base.
Exemplo:
{
"regexPattern": "^/images/(.*)",
"redirect": "https://cdn.example.com/images/",
"status": 301
}
Com esta regra, todos os recursos da subpasta de imagens serão redireccionados para a CDN definida.
Observe que o “^” no início do padrão regex é importante no caso do redirecionamento, para evitar que URIs incorretos sejam retornados.
Definir códigos de status personalizados
É possível substituir o código de status padrão para uma resposta HTTP.
Esta ação é definida pelo atributo status. Trata-se de um número devolvido como código de estado pela resposta HTTP.
Exemplo:
{
"regexPattern": "^/maintenance.html",
"status": 503
}
Com esta regra, quando a página maintenance.html é solicitada, o código de estado devolvido será 503.
⚠️ Certifique-se de que o estado definido por si é consistente com a resposta enviada pelo servidor HTTP!
Combinar acções e regras
Várias acções podem ser combinadas numa regra se partilharem o mesmo regexPattern.
Exemplo:
{
"regexPattern": "/docs/(.*).html",
"addedHeaders": {
"Cache-Control": "max-age=3600"
},
"removedHeaders": ["X-Powered-By"]
}
Esta regra aplica-se a todos os ficheiros HTML colocados na subpasta docs.
As regras também podem ser combinadas numa ordem lógica para configurar completamente as respostas do servidor HTTP.
Exemplo de uma coleção de regras completa:
[
{
"comment": "Todos os pedidos: permitir método GET para, remover cabeçalho 'Server' e definir cabeçalhos de segurança",
"regexPattern": "/(.*)",
"setHeaders": {
"Allow": "GET",
"X-Frame-Options": "SAMEORIGIN",
"Content-Security-Policy": "default-src 'self'"
},
"removeHeaders": [
"Server"
]
},
{
"comment": "Pedidos REST: permitir método POST",
"regexPattern": "/rest/(.*)",
"addHeaders": {
"Allow": "POST"
}
},
{
"comment": "Ficheiros HTML na pasta 'doc': definir controlo de cache",
"regexPattern": "/docs/(.*).html",
"setHeaders": {
"Cache-Control": "Max-Age=3600"
},
"removeHeaders": [
"X-Powered-By"
]
},
{
comment": "Status 503 na página 'manutenção'",
"regexPattern": "^/maintenance.html",
"status": 503
},
{
"comment": "Redirecionar ficheiros CSS e JS",
"regexPattern": "^(.*\\\\.(css|js))",
"redirect": "https://cdn.example.com/"
},
{
"comment": "Redirecionar imagens com código de estado permanente",
"regexPattern": "^(.*\\\\.(jpg|jpeg|png|gif))",
"redirect": "https://cdn.example.com/images/",
"status": 301
},
{
"comment": "Negar o acesso a todos os recursos colocados na pasta 'private'",
"regexPattern": "/private/(.*)",
"denyAccess": true
},
{
"comment": "Permitir o acesso a todos os recursos colocados na pasta 'private/allowed'",
"regexPattern": "/private/allowed/(.*)",
"denyAccess": false
}
]
Resumo
Com HTTPRules.json, 4D se torna um servidor HTTP mais poderoso e flexível. Agora você pode:
- Adicionar, modificar ou remover cabeçalhos
- Bloquear ou permitir acessos
- Redirecionar pedidos
- Definir códigos de status personalizados
Não há necessidade de lógica de filtragem complexa por código, basta configurar no arquivo HTTPRules.json e pronto!
E se as suas aplicações precisarem de ter regras personalizadas (por exemplo, regras de segurança) dependendo dos ambientes implementados ou dos clientes, é muito fácil fazê-lo com o comando Web server comando!
Pronto para simplificar sua implantação na Web? Comece a usar regras hoje mesmo.