A reescrita do URL refere-se ao processo de modificação de um URL a fim de torná-lo mais fácil e mais acessível aos usuários da Internet. Tipicamente, essa modificação ocorre para tornar o URL mais curto e mais consistente. Dessa maneira, os usuários se lembrarão disso e não terão dificuldade para lê-lo ou escrevê-lo, se necessário.

Atualmente, os internautas sabem que existem enormes riscos na Internet. E quando nos deparamos com uma URL longa, composta de números e letras, temos a tendência de desconfiar dela.

É por isso que é importante assegurar a confiança dos visitantes quando eles se depararem pela primeira vez com o seu URL, tornando-o curto e significativo.

Se o senhor ainda não consegue entender o conceito de reescrita do URL, convido-o a ler cuidadosamente este artigo.

Capítulo 1: O que é a reescrita do URL?

Neste capítulo, tentaremos esclarecer os tópicos essenciais para dar-lhe uma idéia clara do que se entende por reescrita do URL.

1.1. Definição de reescrita de URL

Quase todos os servidores, sejam Apache, Nginx, Microsoft IIS ou outros, têm a capacidade de modificar os URLs antes de serem visíveis aos pesquisadores.

Essa modificação geralmente ocorre quando um documento solicitado é localizado em outro lugar e o visitante deve, em vez disso, ser redirecionado para o novo local.

Além dessas reescritas externas onde um visitante solicita um URL e o servidor verifica certos redirecionamentos que se aplicam ao URL solicitado, há também reescritas internas.

Os servidores podem reconhecer rapidamente o documento ou recurso que precisa ser disponibilizado em um URL, independentemente de onde ele esteja armazenado na estrutura interna da pasta.

Quando tomamos o caso do WordPress, por exemplo, cada post do blog é armazenado em um banco de dados e recebe um identificador. As páginas individuais podem sempre ser solicitadas através deste documento de identidade.

1.2) Como funciona a reescrita do URL?

A função de reescrever o URL simplesmente coloca uma camada sobre o endereço original e o transforma em algo que é fácil de encontrar e faz sentido.

Do ponto de vista do usuário, após a reescrita, o URL do site permanece o mesmo no navegador, mas mais consistente

Mas, nos bastidores, o navegador reescreve o URL nessa complicada confusão e envia um pedido aos servidores.

As reescritas de URL também são extremamente úteis quando a estrutura do servidor é alterada e os recursos são movidos de uma pasta para outra

Nessa situação, um administrador de sistema simplesmente escreverá a parte para a qual a URL amigável aponta

Basicamente, como o recurso foi movido, ele terá uma localização diferente. Portanto, uma reescrita é necessária para apontar o URL reescrito para a nova localização do recurso

Isso não deve ser confundido com as funções de redirecionamento que ocorrem quando um recurso é substituído por um recurso diferente.

1.3. Qual é a importância de se reescrever um URL?

É extremamente importante que as URLs façam sentido e dêem uma idéia da página a que se referem, ao mesmo tempo em que são fáceis de serem compreendidas pelos motores de busca.

A reescrita do URL não mostra ao usuário o funcionamento interno e as estatísticas por trás de um endereço do site, impedindo que ele veja as cadeias de consulta, o que não é benéfico para o site.

Esse processo não só é útil para quem o vê ou lê, mas também contribui para o aspecto de segurança do site, impedindo em grande medida o hacking ou o acesso por usuários maliciosos

O objetivo é criar um URL rico em palavras-chave, o que significa incluir a palavra-chave no texto do URL, o que ajudará efetivamente o processo de SEO

Isso assegura que o site em desenvolvimento já esteja em certa medida otimizado antes mesmo de ser lançado.

Os URLs criados também tendem a esconder os links, que na maioria das vezes parecem continuar e continuar.

Além disso, o mesmo URL pode continuar a ser usado, mesmo que haja uma mudança no link original.

O processo de reescrita do URL pode ser feito em qualquer tipo de site ou sistema de gerenciamento de conteúdo da web, seja um site desenvolvido pela asp.net ou aqueles criados usando tecnologia PHP

O processo de reescrita do URL é feito de acordo com os idiomas e necessidades dos websites

Isso parece ser possível com a tecnologia ASP.NET de uma maneira eficiente, pois é semelhante ao Internet Information Server (IIS). Na verdade, o ASP.NET é um mecanismo de scripting do lado do servidor (IIS) que produz páginas interativas na Internet.

A reescrita de URL também é possível com o PHP com o módulo mod reescrita para o servidor Apache, entre outros.

Além disso, eles também parecem ser de fácil utilização através da interface. Também é útil se um usuário quiser remover uma seção do URL para navegar para o próximo nível, o que é muito benéfico para ele.

Digamos que um usuário aterrissa no site example.com/seo/recritture-url page e quer voltar à home page. Eles podem simplesmente manter o exemplo.com e apagar as outras partes.

1.4. Por que a reescrita do URL é boa para SEO?

Há várias vantagens em usar a reescrita do URL. Em primeiro lugar, a reescrita do URL ajuda na acessibilidade e na melhoria da experiência do usuário

Simplificando, quando um usuário olha um URL em um resultado de um motor de busca, não precisa tentar descobrir do que se trata aquela página ou artigo.

Além disso, URLs confusos não encorajam as pessoas a clicar neles, o que pode levar a uma taxa de cliques mais baixa. Isso geralmente é ruim para o desempenho da SEO e do site.

Por outro lado, os URLs amigáveis ajudam a otimizar o conteúdo para SEO

Um URL que inclua o título do artigo e a palavra-chave principal ajudará com sua indexação no Google e com a percepção dos bots sobre seu artigo ou página da web

Como resultado, URLs otimizadas para SEO através da reescrita de URLs levam a uma melhor visibilidade, mais credibilidade com seus usuários e naturalmente maior volume de tráfego.

Além disso, o uso de reescritos de URL também ajuda a manter consistência no caminho de URL e na estrutura do nome da página

Finalmente, as reescritas também contribuem para o desempenho por meio do cache em modo de usuário e da resolução de problemas, já que cuidam do acompanhamento de pedidos falhos.

1.5. Reescrita do URL vs. redirecionamento

Ao contrário dos reescritos de URL, um redirecionamento é uma ação do lado do cliente, não uma ação do lado do servidor.

Basicamente, uma reescrita ocorre quando o endereço do recurso muda, ou precisamos de uma camada mais simples, mais fácil de usar

Isso acontece nos bastidores e o usuário não está ciente disso. Em comparação, um redirecionamento ocorre quando o recurso não existe mais.

Redirecionamentos também podem ocorrer quando prevemos como um usuário tentará acessar um recurso e configurar funções de redirecionamento para assegurar que ele acesse o recurso corretamente.

Por exemplo, a resolução WWW é uma ação de redirecionamento pela qual, independentemente de como o usuário procure a página inicial de Twaino, ele usará a WWW antes do nome do domínio ou não, sempre pousará em Twaino.com.

Capítulo 2: Por que é importante fazer uma reescrita do URL?

Este capítulo se concentra no motivo pelo qual os webmasters devem fazer uma reescrita.

2.1. As aplicações precisam ser seguras

É importante que os webmasters protejam seus websites de todos os tipos de ataques. De fato, um indivíduo não deve ser capaz de prejudicar seu site alterando um URL que aponte para suas solicitações

Para garantir a segurança de seu site, verifique todas as variáveis GET de seus visitantes.

Por exemplo, digamos que temos um roteiro simples que mostra todos os produtos de uma categoria. Normalmente é assim que se parece:

• myapp.php?target=showproducts&categoryid=123

Mas quando um ScriptKiddie(tm) digita em sua barra de navegação myapp.php?target=showproducts&categoryid=youarebeinghed, muitos sites exibirão mensagens de erro reclamando sobre o uso da consulta SQL errada, uma identificação de recurso MySQL inválida, etc. Isso simplesmente mostra que esses sites não são tão bons quanto poderiam ser

Isso mostra simplesmente que esses sites não são de modo algum seguros ou muito seguros.

2.2. As solicitações devem ser amigáveis aos motores de busca

Não é do conhecimento geral, mas muitos mecanismos de busca não indexarão seu site a fundo se ele contiver links para páginas dinâmicas como a mencionada acima

Eles simplesmente tomam a parte do “nome” do URL. Ou seja, tudo antes do ponto de interrogação, que contém os parâmetros necessários para que a maioria dos roteiros funcione, e depois tentar recuperar o conteúdo da página

Para que fique claro, aqui estão alguns links de nossa página fictícia:

• myapp.php?target=showproducts&categoryid=123 ;
• myapp.php?target=showproducts&categoryid=124 ;
• myapp.php?target=showproducts&categoryid=125.

Infelizmente, há uma boa chance de alguns motores de busca tentarem baixar a página myapp.php.

Na maioria dos casos, chamar um roteiro como este causará um erro ou não mostrará o conteúdo apropriado para o qual o link estava apontando

Basta tentar essa busca no google.com:

o senhor tem um erro em sua sintaxe sql” .php -forum

O senhor notará que há erros enormes e ameaças de segurança nos scripts listados

2.3. As solicitações devem ser de fácil utilização

Se seu website usa um aplicativo como

quehttp://www.downloadsite.com?category=34769845698752354, então a maioria de seus visitantes terá dificuldade de voltar à sua categoria favorita cada vez que sair da página principal de seu site

É ainda mais fácil para o usuário encontrar a URL na lista suspensa de navegadores quando ele digita no campo “Localização”, embora, é claro, isso só funcione se o usuário já a visitou antes.

Capítulo 3: Quais são as regras para a reescrita do URL?

É óbvio que a reescrita do URL é uma oportunidade para que os sites tornem seus URLs de fácil utilização. Contudo, essa prática deve seguir certas regras para ser eficaz e produzir os efeitos desejados.

Neste capítulo, discutiremos as regras que devem ser seguidas a fim de reescrever adequadamente os URLs de um site.

3.1) Como reescrever um URL com o IIS

Para reescrever um URL com o IIS, o senhor deve primeiro instalar o software que pode ser baixado da plataforma Microsoft.

Uma vez instalado, o senhor verá um novo ícone “Url Rewrite” no console de administração do IIS.

Passo 1: O console de administração do IIS com reescrita do URL foi acrescentado

O senhor pode administrar a reescrita do URL no nível do servidor ou para sites individuais, como julgar conveniente

Com o módulo de reescrita do URL, o senhor verá os “modelos” usados. Os modelos estão em uma das três modalidades

• Combinação exacta
• Selvagens; e
• E as expressões regulares ECMAScript, que são expressões regulares compatíveis com o Perl.

Há dois tipos de regras: a de entrada e a de saída

As regras de entrada examinam os URLs dos pedidos e os modificam. Enquanto as regras de saída inspecionam o tráfego enviado, procurem os URLs que ele contém e reescrevam-nos, se necessário;

Isso é ainda mais interessante quando o conteúdo pode usar uma URL absoluta que não é aquela que o usuário deve receber;

Uma das vantagens da reescrita do URL é que ela suporta uma série de regras embutidas diferentes que facilitam a vida quando o senhor quer fazer uma reescrita comum

A lista completa das regras incorporadas é :

• Regra com reescrita do mapa: permite ao senhor definir um conjunto de caminhos e suas substituições como uma simples lista;
• Bloqueio de consultas: Proibir o acesso a um caminho;
• URL de fácil utilização: crie rapidamente regras para mapear segmentos de trajeto para consultar cadeias de caracteres;
• Reverse Proxy: Permite que o servidor atual reverta o proxy de outro;
• Forçar URLs em minúsculas: Força o cliente a usar sempre URLs em minúsculas através de um redirecionamento HTTP “Permanente” 301;
• Nome de Domínio Canônico: Usa um redirecionamento HTTP “Permanente” 301 para assegurar que os clientes sempre usem o nome de domínio especificado;
• Adicionar ou remover o símbolo da barra móvel: Isso sempre adicionará ou removerá a barra móvel em um caminho de URL usando um redirecionamento de status HTTP 301 “Permanente”.

Passo 2: A criação de uma regra permite ao senhor escolher uma regra integrada para começar de

Regras embutidas são ótimas porque, embora venham com um assistente personalizado, se necessário, elas geram regras padrão que o senhor poderá ajustar ou modificar conforme necessário.

A regra da URL amigável é bastante popular para aqueles que não têm um sistema que faça isso automaticamente

O senhor começa entrando com um exemplo do URL “feio” que o site realmente precisa

Passo 3: Criação de uma regra de URL amigável

Outra das regras embutidas que mais se usa é a regra da procuração inversa

Mais uma vez, o sistema o conduz através de uma configuração padrão competente no que poderia ser uma tarefa muito complexa

Ela contém opções embutidas e editáveis, tais como:

• Se as respostas HTTPS devem ou não ser sempre procuradas em relação ao HTTP padrão;
• Se o senhor deseja ou não usar uma regra de saída para ocultar o nome do servidor interno

As pessoas costumam usar isso para poder montar um servidor central com hosts virtuais no mesmo endereço IP para tratar de pedidos recebidos que precisam ser enviados a diferentes servidores internos.

Figura D: Criação de uma procuração inversa

A última regra que discutiremos é reescrever mapas

Isso permite ao senhor criar uma lista de URLs e traduzi-las em URLs substitutas

Por si só, um mapa reescrito é desnecessário, ele deve ser usado como parte de uma regra maior em vez de ou em conjunto com padrões de substituição

Esses são particularmente úteis ao projetar ou reorganizar um site que usa URLs não previsíveis

Ao combinar um redirecionamento usando o status HTTP 301 “Permanente” com um mapa reescrito, o senhor pode personalizar suas traduções em situações em que as regras não funcionam bem.

Uma vez que o senhor tenha estabelecido a regra básica, poderá modificá-la conforme necessário. O editor de regras divide as coisas muito bem

O senhor começa com um nome de regra e o modelo de URL a ser correspondido

A partir daí, o senhor pode acrescentar várias condições, como, por exemplo

• A busca de uma determinada cadeia em um parâmetro URL
• Uma variável de ambiente de servidor
• E assim por diante

O senhor pode dizer-lhe que se enquadra em todas ou algumas das condições. Se as condições não forem satisfeitas, a regra não executará a reescrita

O senhor também pode fazer substituições nas variáveis do servidor, o que é ideal para impor certos comportamentos

As variáveis do servidor abrangem uma lista muito grande de itens com os quais trabalhar, inclusive os mapas reescritos que o senhor criou

Então o senhor define o que a regra deve realmente fazer, que é realizar uma reescrita ou redirecionamento que realmente enviará um código de status HTTP redirecionado para o cliente para consultar o novo URL

Em seguida, o senhor define o modelo para a reescrita propriamente dita. Finalmente, o senhor tem algumas opções:

• Acrescentando a seqüência do pedido;
• Guarde o pedido;
• Não aplique mais regras depois que estiver terminado.

3.2 Como reescrevo um URL com Apache?

Aqui estão alguns passos sobre como o senhor pode definir regras de reescrita de URL com o Apache:

Passo 1: Instalação do servidor web Apache

Antes de começar, certifique-se de ter instalado em seu sistema o pacote do servidor web Apache. Se não for instalado, o senhor pode instalá-lo com o seguinte comando: “apt-get install apache2 -y”

Uma vez instalado o pacote, inicie o serviço Apache com o seguinte comando: ”systemctl start apache2”.

Em seguida, abra seu web browser e digite o URL http://your-server-ip para verificar o servidor web Apache

Passo 2: Habilitar mod_rewrite

Por padrão, o módulo mod_rewrite é instalado com o pacote Apache, mas está desativado. Portanto, o senhor precisará habilitá-lo primeiro.

O senhor pode habilitá-lo com o seguinte comando: “a2enmod reescrever”.

Em seguida, reinicie o serviço Apache para aplicar as mudanças e verifique o módulo Apache mod_rewrite com o seguinte comando: apache2ctl -M | grep rewrite_module.

Você deve obter a seguinte saída: rewrite_module (shared)

Passo 3: Habilitar arquivos .htaccess

O senhor pode estabelecer regras de reescrita diretamente no arquivo principal de configuração do Apache. No entanto, recomenda-se que o senhor escreva regras no arquivo .htaccess dentro de cada website.

Por padrão, o Apache não permite que o arquivo .htaccess seja usado. O senhor precisará habilitar o arquivo .htaccess no seu arquivo de configuração padrão do host virtual.

Para fazer isso, editar o arquivo de configuração de host virtual padrão do Apache: nano /etc/apache2/sites-available/000-default.conf.

Acrescente as seguintes linhas antes da linha

Índice de opções FollowSymLinks MultiViews

Permitir a anulação de tudo

Exigir que todos sejam concedidos

Certifique-se de salvar e fechar o arquivo, depois reinicie o serviço Apache para aplicar as mudanças: systemctl reinicia o apache2.

Passo 4: Configuração da reescrita do URL

Para entender como funciona a reescrita do URL, vamos criar uma página home.html no diretório raiz do documento Apache

Em seguida, configuraremos uma reescrita básica do URL que acessará a página http://your-server-ip/home e a converterá para o atual caminho da página http://your-server-ip/home.html.

Vamos começar criando uma página home.html:

nano /var/wwww/html/home.html

Acrescente o seguinte conteúdo:

Home

Página inicial

Aqui está minha página inicial

Guarde e feche o processo quando terminar.

Em seguida, criar um arquivo .htaccess no diretório raiz do documento padrão do site para testar mod_rewrite.

nano /var/wwww/html/.htaccess

Primeiro, acrescente a seguinte linha para permitir a reescrita do motor: RewriteEngine habilitado.

Em seguida, acrescente a seguinte regra de reescrita que redireciona os visitantes para casa.html se eles solicitarem a página http://your-server-ip/home: RewriteRule ^home$ home.html [NC].

Guarde e feche o processo quando estiver terminado.

Uma breve explicação sobre a sintaxe das regras de reescrita é dada a seguir:

• ^: Isso corresponderá a qualquer texto após o endereço IP do servidor;
• $: Isso indica o fim do URL.
• home: Isso corresponde ao que está acontecendo em casa;
• home.html: Isso define o arquivo real que o visitante está acessando;
• [Isso torna o caso de regra insensível.

O senhor pode agora visitar a home page http://your-server-ip/home em seu web browser. O Apache vai redirecionar para a página home.html.

3.3. Como fazer uma reescrita com nginx

Em nginx, a diretiva de reescrita pode ser especificada em um dos três contextos: servidor, localização, se.

3.3.1. Nginx reescreve o exemplo usando $1, $2, .

Eis um exemplo de uma diretiva de reescrita Nginx: reescrever ^(/data/.*)/geek/(\w+)^(/data/.*)*$1/linux/$2.html por último.

Por exemplo :

Url/data/distro/geek/test.php serão reescritos como url/data/distro/linux/test.html.

Neste exemplo, quando o usuário chamar o URL original com test.php do navegador, ele será reescrito de acordo com a regra de reescrita acima e servirá a página test.html de /data/distro/linux/

Na regra de reescrita acima:

• $1 e $2 capturam as cordas apropriadas da URL original que não muda;
• um dólar na corda substituta corresponderá a qualquer coisa dentro do primeiro parênteses ( ) no reg-ex. Em nosso exemplo, $1 é /dados/ ;
• Do mesmo modo, 2 dólares correspondem a tudo o que está dentro do segundo parênteses ( ) no reg-ex. Portanto, $2 é (\w+), que é qualquer palavra que vem depois do /geek/ no URL original;
• Em nosso exemplo, 2 dólares é um último teste. Essa bandeira vai garantir que não haverá mais procura pela diretiva de reescrita no local ou bloco atual e usar o URL modificado e procurar um novo local para qualquer outra diretiva de reescrita que corresponda;
• *$: Isso indica a extensão na URL original. Note que aqui a extensão do URL original será substituída por .html no URL reescrito. Portanto, mesmo que o senhor ligue para .php no URL original, ele só servirá para o arquivo .html no URL reescrito.

Embora as regras de reescrita do Nginx sejam semelhantes às do Apache, ainda há muitas diferenças na maneira como o senhor escreve uma regra de reescrita no Nginx.

3.3.2. Criação de um arquivo de controlador usando Nginx Rewrite

Usando reescrita, o senhor pode encaminhar muitas URLs de origem recebidas para um modelo de controlador principal que atenderá a esses pedidos.

O seguinte exemplo reescrito explica isso:

• reescrever ^/linux/(.*)$ /linux.php?distro=$1 último ;

Nesse exemplo, quando o senhor chamar o URL thegeekstuff.com/linux/centos, ele será reescrito usando a regra acima e servirá à página com esse URL reescrito

• thegeekstuff.com/linux.php?distro=centos

Como o senhor pode ver acima, qualquer URL que corresponda ao padrão aqui /linux/ no URL será servido pelo linux.php, mas a última parte do URL original de entrada será usada como valor para o argumento de distribuição no controlador do linux.php.

Portanto, a regra de reescrita acima transformará a URL de entrada da seguinte maneira:

• linux/centos torna-se linux.php?distro=centos ;
• linux/debian torna-se linux.php?distro=debian ;
• linux/redhat torna-se linux.php?distro=redhat ;
• etc.

Como no exemplo anterior, usamos um dólar no fio substituto para capturar tudo dentro do primeiro parênteses ( ) no reg-ex. Nesse caso, é a última parte do URL original que chega.

Também usamos aqui a última bandeira para dizer ao nginx que pare de procurar outras diretrizes reescritas no bloco atual e se mude para o próximo local correspondente para uma nova busca.

3.3.3. Reescrever o indicador de quebra no contexto do local

Neste exemplo, colocamos a condição de reescrita na diretriz de localização.

Neste exemplo, a diretiva de localização é /dados/, que também corresponde ao dólar na seqüência de substituição dada abaixo.

dados de localização/ {

reescrever ^(/data/.*)/geek/(\w+)*$1/linux/$2.html break ;

retornar 403 ;

}

Eis o que teria acontecido se o senhor tivesse usado a “última” bandeira acima:

• Portanto, se o senhor tivesse “último” como bandeira, após a reescrita inicial do URL, a Nginx normalmente procurará a próxima diretiva de reescrita para o novo URL;
• Nesse caso, a Nginx continuará a redirecionar para os mesmos dados de localização e continuará a processar a mesma regra de reescrita até 10 vezes, e finalmente devolverá o código de erro 500.

3.3.4. Acrescentar um ponto de interrogação à cadeia de substituição Nginx Rewrite

Se uma cadeia de substituição inclui as novas palavras-chave de consulta, as palavras-chave de consulta anterior são acrescentadas depois delas

Se o senhor não quiser fazer isso, coloque um ponto de interrogação no final de um fio substituto para evitar acrescentá-los.

No exemplo a seguir, na parte do fio substituto, não há nenhum ponto de interrogação no final. Isto é, sem dúvida alguma, depois de um dólar:

reescrever ^/linux/(.*)$ /linux.php?distro=$1 último ;

No exemplo acima, quando a cadeia de substituição inclui os argumentos do pedido entrante, os argumentos do pedido anterior foram acrescentados depois deles.

Quando o senhor não quiser que esse acréscimo aconteça de fato, pode ter um resultado alternativo.

No exemplo a seguir, na parte de substituição do Nginx reescrita, o senhor pode acrescentar (?) no final, ou seja, há um ponto de interrogação depois de $1

reescrever ^/linux/(.*)$ /linux.php?distro=$1? último;

No exemplo acima, a seqüência de substituição inclui os argumentos do pedido recebido, e depois os argumentos do pedido anterior não são acrescentados depois deles.

3.3.5 ”se” O contexto e reescrever a diretriz

Os poucos exemplos a seguir ilustram que podemos usar a reescrita dentro da diretiva if.

O senhor pode fazer uma reescrita condicional com base numa comparação de se condições usando variáveis como $scheme, $http_host, $http_user_agent, etc., como mostra a seguir:

se ($scheme = “http”) {

reescrever ^ https://www.thegeekstuff.com$uri permanente ;

}

se ($http_host = thegeekstuff.com) {

reescrever (.*) https://www.thegeekstuff.com$1 ;

}

se ($http_user_agent = MSIE) {

reescrever ^(.*)$ /pdf/$1 pausa ;

}

Observe também que há melhores maneiras de se alcançar o resultado final dos exemplos acima

Os exemplos acima são dados apenas para mostrar que podemos acrescentar uma diretiva de reescrita dentro da declaração “se” no arquivo de configuração nginx.

Queira observar que o senhor também pode definir o valor dos dois parâmetros a seguir para on ou off em seu arquivo de configuração nginx:

server_name_in_redirect on

port_in_redirect incapacitado

3.3.6. Capturar Nginx reescreve os acertos no arquivo de registro de erros

Por padrão, sempre que o Nginx faz uma reescrita bem sucedida, ele não a registra no arquivo error.log.

Inicialmente, ao escrever regras complexas de reescrita, o senhor precisa realmente se certificar de que o Nginx faça a reescrita conforme necessário.

Para isso, o senhor precisa habilitar o registro de reescrita, que escreverá um registro cada vez que o nginx fizer uma reescrita bem sucedida, usando uma das diretrizes de reescrita do arquivo de configuração.

Para fazer isso,

• Usar a diretriz reescrita_log e colocá-la em vigor;
• Acrescente as duas linhas seguintes ao seu nginx default.conf:

notice error_log /var/log/nginx/error.log ;

reescrever_log para ;

A primeira linha indica a localização do arquivo error_log onde devem ser escritas as mensagens de reescrita

Queira notar que uma mensagem reescrita é de tipo aviso. Portanto, o senhor deve acrescentar “nota” ao final desta linha, como já foi dito acima.

3.4. Qual é o verdadeiro problema com as regras de reescrita do URL?

Os desenvolvedores de aplicações web usam regras de reescrita de URL para esconder parâmetros na estrutura do caminho do URL

Isso facilita aos motores de busca a indexação de todas as páginas de um website, enquanto os navegadores recebem a URL em um formato que entendem e que é fácil de lembrar para os usuários.

É importante assegurar que esses pedidos sejam aceitos pela aplicação da web e que todos os parâmetros da URL sejam corretamente analisados

O seguinte resume os problemas que podem ocorrer quando um software automatizado de varredura de vulnerabilidade da web tenta varrer websites que usam tecnologia e regras de reescrita de URL:

3.4.1. Os parâmetros nos URLs não são escaneados

Um problema comum encontrado pelos scanners de vulnerabilidade da web ao escanear aplicações da web que usam tecnologia de reescrita de URLs é que os scanners não conseguem identificar parâmetros em URLs

Os scanners assumem que os URLs são diretórios e não nomes ou valores de parâmetros, e os deixam por digitalizar.

3.4.2. Varreduras de vulnerabilidade prolongadas

Esse problema pode levar a varreduras prolongadas e resultados de varredura incorretos

Por exemplo, se o scanner de vulnerabilidade da web escaneia um banco de dados de ferramentas que contém 100.000 ferramentas, já que o scanner não consegue identificar que existe um parâmetro e um valor no URL, ele pensaria que são páginas diferentes. Por isso, tentará rastejar e escanear todos eles.

Se problemas de memória e outras exceções não forem resolvidos corretamente por seu scanner, isso também pode fazer com que seu software comece a falhar e deixar o senhor sem resultados.

3.4.3. A criação de regras de reescrita de URL é um processo difícil

Como a tecnologia de reescrita de URL se tornou muito popular em aplicações web, muitos scanners comerciais de vulnerabilidade web permitem que os usuários configurem o scanner. Isso lhes permite identificar parâmetros em URLs e digitalizá-los.

Mas mesmo que os scanners de vulnerabilidade da web possam ser configurados para varrer websites usando regras de reescrita de URL, os usuários podem encontrar vários outros problemas, tais como

• É muito difícil configurar o apoio às regras de reescrita de URLs;
• O usuário deve saber escrever expressões regulares;
• O usuário deve ter acesso aos arquivos de configuração do servidor web.

Portanto, se o senhor não é o desenvolvedor da aplicação web em si ou se não tem conhecimento profundo da aplicação web, é impossível configurar regras de reescrita de URL no scanner

E, mesmo que o senhor saiba como fazer isso, configurar regras de reescrita é uma tarefa muito difícil e demorada.

3.4.4. As aplicações da Web não são devidamente escaneadas em busca de vulnerabilidades

Supondo que o senhor consiga configurar regras de reescrita de URL em seu scanner de vulnerabilidade da web, há outros problemas.

Há uma série de limitações na maneira como os scanners examinam a aplicação web. Como medida de segurança, as aplicações web não aceitam pedidos HTTP que já estão “traduzidos”

Por padrão, as aplicações .NET da web não aceitam solicitações HTTP

O problema se torna ainda mais importante quando se analisa as aplicações web MVC, já que essas aplicações usam uma abordagem diferente para a reescrita de URLs.

Uma vez que o senhor tenha configurado as regras de reescrita do URL em seu scanner, ele envia um tipo de pedido HTTP chamado pedido traduzido

Mesmo que o scanner de segurança da aplicação web informe que o scanner foi bem sucedido, a maioria dos pedidos HTTP são recusados e os parâmetros do URL não são escaneados, o que lhe dá uma falsa sensação de segurança.

Conclusão

Observamos que a reescrita do URL às vezes é essencial para assegurar que seu endereço não dê um mau pressentimento aos usuários da Internet.

É um processo que oferece muitos benefícios de uma perspectiva de credibilidade da SEO e do website.

Nesse conteúdo, esclarecemos o conceito de reescrita de URL e o acompanhamos com as melhores maneiras de reescrever suas URLs.

Convidamos o senhor a compartilhar conosco suas opiniões e outros recursos sobre o conceito de reescrita de URL.