O arquivo .htaccess

Arquivos .htaccess, também conhecidos como arquivos de configuração distribuída, oferecem meios para modificar as configurações de diretórios. O .htaccess é usado com frequência para bloquear acessos não autorizados, bloquear IPs, impedir listagens de diretórios, criar redirecionamentos e evitar o chamado "hot-linking".

Introdução

O .htaccess é um arquivo de configuração usado exclusivamente pelo servidor web Apache. Como o Apache domina amplamente o ambiente web, vale a pena conhecer este arquivo e seu imenso potencial. Um arquivo deste tipo, contendo uma ou mais diretrizes de configuração, pode ser colocado num diretório em particular para que suas diretrizes sejam aplicadas no diretório que contém o arquivo, assim como em todos os seu subdiretórios.

Se você hospeda seu site num servidor Linux com webserver Apache, existe uma boa probabilidade do seu hospedeiro ter disponibilizado seu acesso a arquivos .htaccess. Se você optou por um servidor Windows, pode esquecer... nunca vi um servidor Windows usando o webserver Apache

Bem, partindo do pressuposto que a dupla dinâmica Linux+Apache esteja à sua disposição, a primeira coisa é descobrir se você tem permissão para usar o .htaccess. Geralmente o serviço de hospedagem informa explicitamente esta permissão ou dá indicações indiretas do tipo "páginas de erro 404 personalizadas" ou "proteção de diretórios com senha". Se você tiver dúvidas, peça informações ao seu hospedeiro ou então crie seu próprio arquivo .htaccess, transfira-o para um diretório do seu site e teste-o: funcionou, está liberado

O nome deste arquivo é um pouco estranho. Aliás, parece que não tem nome - parece ser identificado apenas como uma extensão. Na verdade, o nome do arquivo é htaccess e o ponto antes do nome serve para indicar ao sistema Linux que se trata de um arquivo oculto (hidden). Portanto, se você criar seu .htaccess particular, não invente. Chamá-lo de arquivo.htaccess ou alguma página.htaccess não vai funcionar! O motivo é o seguinte: existe um arquivo de configuração do servidor Apache no qual o nome dos arquivos de configuração distribuída são definidos. Neste arquivo de configuração existe uma diretiva que diz AccessFileName .htaccess e os serviços de hospedagem mantêm este nome padrão para não dar nó na cabeça dos seus clientes. É claro que o "dono" do servidor web pode mudar esta diretiva para, por exemplo, AccessFileName .config. Neste caso você precisa desta informação para criar arquivos de configuração distribuída no seu site: ao invés de .htaccess, o nome destes arquivos teria que ser .config.

Criando arquivos .htaccess

O .htaccess é um arquivo ASCII. Use seu editor de texto preferido certificando-se de que esteja com o rearranjo de linhas (word wrap) desativado para evitar a inclusão de caracteres de quebra de linha, geralmente não visíveis, que poderão gerar erros. Se você usar o Bloco de Notas do Windows, cuidado quando for salvar seu arquivo: como padrão, este editor de texto adiciona a extensão .txt e um arquivo com o nome .htaccess.txt não vai ser reconhecido pelo Apache.

Leia com atenção as diretrizes do Apache, em especial as do .htaccess, de preferência na fonte (nas Fontes de Referência desta página você encontra um link para o site oficial do Apache). Coloque cada uma das diretrizes em UMA LINHA própria. Confira cuidadosamente a sintaxe - atenção especial para aspas e caminhos (path).

De início, implemente uma diretriz por vez: crie o arquivo, faça o upload e teste. Deu caca? Neste caso, ou há erros de sintaxe ou seu servidor não permite o uso da diretriz em questão (ela pode estar bloqueada no arquivo de configuração principal do Apache). Volte para a versão anterior e continue seu trabalho. No início é penoso, mas este procedimento permite estabelecer as limitações impostas pelo seu servidor e faz com que você se familiarize com o funcionamento dos arquivos de configuração distribuída.

O upload de arquivos .htaccess precisa ser no modo ASCII, não no modo BINARY. Após o upload, verifique se a permissão é 644 (RW-R--R--). Isto faz com que o arquivo possa ser usado pelo servidor mas evita que seja lido pelo browser (o que comprometeria seriamente a segurança).

Não saia na louca pondo arquivos .htaccess em tudo que for diretório. Vá com calma. Analise inicialmente sua real necessidade e sua melhor localização, implemente um arquivo por vez e TESTE tudo antes de continuar. Lembre-se que arquivos .htaccess atuam sobre o diretório onde estão localizados e sobre todos os respectivos subdiretórios. Isto significa que, colocando um .htaccess no diretório raiz, todos os diretórios do site serão afetados. Digamos que exista um .htaccess no diretório raiz atuando sobre todos os outros diretórios e que você quer definir propriedades diferentes para o diretório raiz/texto/escondido/. Neste caso, crie o arquivo desejado e coloque-o no diretório /escondido. Este último tomará o lugar do que está no diretório raiz.

É necessário um cuidado especial quando se usa múltiplos arquivos .htaccess. A coisa mais fácil é criar loops infinitos, que "penduram" o servidor. Por exemplo, você redireciona uma página para outra que esteja num diretório que redireciona a referida página novamente para a página original... já viu, né?

Nos tópicos seguintes você encontra alguns exemplos de uso de arquivos de configuração distribuída. Talvez isto facilite um pouco as coisas, mas não encare os exemplos como "prato pronto" porque, a não ser que você possa "pilotar" seu servidor, tem aquela história da configuração central do Apache.

Mudar a página default

DirectoryIndex é a diretriz que permite especificar qual arquivo deve ser carregado quando chegar uma solicitação de diretório ou URL que não especifique uma página em particular (tipo http://www.numaboa.com/). Normalmente a página default é index.html e a chamada do exemplo é transformada em http://www.numaboa.com/index.html. Se você quiser mudar as regras do jogo, não tem problema:

DirectoryIndex adoropizza.html

Se o seu .htaccess estiver no diretório raiz, esta diretriz faz com que a página default de todos os diretórios do seu site passe a ser adoropizza.html. Tem mais. Se você quiser usar outras páginas (ou até scripts) como default, basta adicionar as referências a gosto:

DirectoryIndex adoropizza.html index.php home.htm index.cgi index.pl

A linha acima, se o arquivo .htaccess estiver no diretório raiz, faz com que a procura da página default siga a lista especificada: adoropizza.html é a primeira a ser procurada; se for encontrada, ela é enviada para o usuário e a procura pára por aí; se não for encontrada, index.php é a próxima... e assim por diante, até index.pl. Caso nenhum dos arquivos relacionados seja encontrado, aí entra o famigerado erro 404.

Lembre-se que todos os diretórios abaixo do diretório raiz obedecem as regras ditadas pelo primeiro .htaccess acima deles, a não ser que o diretório possua seu próprio .htaccess. Se não existirem outros .htaccess em subdiretórios, para todos os diretórios do site vale o .htaccess do diretório raiz - as páginas default serão sempre as mesmas.

Mesmo não personalizando um .htaccess próprio, as páginas default costumam ser index.html, index.htm, default.html, default.htm, etc, porque o pessoal do serviço de hospedagem já fez esta configuração inicial no Apache.

Já usei este expediente para "proteger" alguns diretórios que continham gráficos, midis ou scripts. Como não queria que fossem listados, colocava um .htaccess no diretório alvo indicando uma página inexistente: Tchan! erro 404! Solução pouco elegante, mas eficaz. Eu disse "usei", não uso mais. Hoje utilizo redirecionamentos ou scripts PHP.

Documentos de erro

Provavelmente a aplicação mais conhecida do arquivo .htaccess seja direcionar usuários para páginas de erro personalizadas. Digamos que um usuário solicite uma página inexistente - ele recebe a página padrão do sistema do seu servidor avisando-o do ocorrido. Para personalizar seu site, é possível criar suas próprias páginas de erro e, quando for o caso, direcionar os usuários para elas.

Para criar suas próprias páginas de erro é necessário conhecer os códigos de erro retornados pelo servidor. Nas tabelas abaixo você encontra todos os códigos de erro atualmente padronizados. É claro que não há necessidade de fazer páginas para cada um deles... na verdade, você nem deveria. Um documento de erro para o código 200 causaria um loop infinito cada vez que uma página fosse encontrada - uma nhaca!

Erros de Requisições de Cliente

400 Requisição viciada (Bad Request) 408 Requisição com tempo vencido (Request Timed Out)

401 Requer autorização (Authorization Required) 409 Requisição conflitante (Conflicting Request)

402 Requer pagamento (Payment Required) *ainda não usada 410 Acabou (Gone)

403 IProibido (Forbidden) 411 Requer comprimento do conteúdo (Content Length Required)

404 Não encontrado (Not Found) 412 Falha na precondição (Precondition Failed)

405 Método não permitido (Method Not Allowed) 413 Entidade requerida muito longa (Request Entity Too Long)

406 Não aceitável (codificação) (Not Acceptable (encoding)) 414 URI requerida muito longa (Request URI Too Long)

407 Requer autenticação proxy (Proxy Authentication Required ) 415 Tipo de mídia não suportado (Unsupported Media Type)

Requisições de Cliente bem sucedidas

200 OK

201 Criado (Created)

202 Aceito (Accepted)

203 Informação não autorativa (Non-Authorative Information)

204 Sem conteúdo (No Content)

205 Conteúdo resetado (Reset Content)

206 Conteúdo parcial (Partial Content)

Requisições de Cliente redirecionadas

300 Escolhas múltiplas (Multiple Choices)

301 Mudado permanentemente (Moved Permanently)

302 Mudado temporariamente (Moved Temporarily)

303 Veja outras (See Other)

304 Não modificado (Not Modified)

305 Use Proxy (Use Proxy)

Erros do Servidor

500 Erro interno do servidor (Internal Server Error)

501 Não implementado (Not Implemented)

502 Gateway viciado (Bad Gateway)

503 Serviço não disponível (Service Unavailable)

504 Gateway com tempo vencido (Gateway Timeout)

505 Versão HTTP não suportada (HTTP Version Not Supported)

Geralmente cria-se documentos de erro para os código 404 e 500, para páginas não encontradas e para poder controlar erros internos do servidor em scripts que estejam sendo utilizados. Também é interessante personalizar o erro 401 - Autorização Requerida - quando se tem áreas protegidas e o erro 403 - Proibido - quando se tem arquivos com permissão de uso bloqueada. Outra possibilidade seria tratar o erro 400 - Requisição Viciada - para capturar erros em scripts ou URLs malucas que um usuário possa tentar usar.

Para especificar seus próprios documentos de erro, tudo o que você precisa é adicionar a seguinte diretriz, em UMA LINHA, no seu arquivo .htaccess:

ErrorDocument code /diretorio/nomearquivo.ext

ou

ErrorDocument 404 /erros/naoencontrado.html

e, de forma análoga,

ErrorDocument 500 /erros/errointerno.html

Pode-se usar qualquer nome para os documentos de erro - para facilitar, recomendo que lembrem a função dos mesmos - e colocá-los em qualquer diretório que seja acessível pela web através de uma URL. A primeira barra corresponde ao diretório raiz do site. Pessoalmente prefiro mantê-los num diretório próprio para facilitar a manutenção e para poder controlar spiders indexando estas páginas através de um arquivo ROBOTS.TXT.

Na hipótese de capturar todos os erros acima mencionados e direcionar o usuário para páginas específicas, o arquivo .htaccess teria a seguinte configuração:

ErrorDocument 400 /erros/request.html

ErrorDocument 401 /erros/authreqd.html

ErrorDocument 403 /erros/forbid.html

ErrorDocument 404 /erros/notfound.html

ErrorDocument 500 /erros/serverr.html

Não se esqueça de que cada diretriz precisa estar numa linha única própria. Pode-se também especificar um endereço URL completo, como por exemplo http://seusite.com/erros/notfound.html, apesar de que a forma padrão é o endereçamento relativo como mostrado acima.

Acredite ou não, mas você também pode especificar HTML!

ErrorDocument 401 "body bgcolor=#ffffff>

h1>

Você precisa b>SER/b> um a href=" #">usuário registrado/a>

para ver esta página!

/h1>

Observe que, logo no início do código HTML, existem aspas. Observe também que, no final do código HTML, não há aspas. É assim mesmo que deve ser feito e, lembre-se, tudo numa única linha sem word wrap! Apesar de existir esta opção, você tem muito mais controle sobre páginas de erro quando usadas em conjunto com xSSI, CGI ou ambos. Eu uso, por exemplo, uma página de erro 404 que, além da mensagem para o usuário, contém código PHP que me envia um e-mail com a indicação do documento faltante toda vez que uma página não é encontrada. Este código pode ser ativado/desativado com facilidade, assim posso monitorar o site pelo tempo que quiser.

Bem, para páginas personalizadas de erro isto é tudo. Experimente e divirta-se. É claro que um arquivo .htaccess com estas diretrizes deve ficar preferencialmente no diretório raiz para que possa capturar possíveis erros em qualquer setor do site.

Redirecionamento

Você já passou pelo sufoco de mudar porções significantes do seu site e depois ter que lidar com o problema das pessoas procurando páginas antigas que foram substituídas? Depois do trabalhão que teve para divulgar o site e colocá-lo em mecanismos de busca, será que ficou tudo perdido?

A resposta é não, porque existe o redirecionamento. Existem várias maneiras de redirecionar páginas: através de http-equiv, javascript ou qualquer linguagem server-side como Perl, PHP, etc. Acontece que também é possível fazer redirecionamentos através do arquivo .htaccess, provavelmente o mais eficiente considerando o pouco trabalho requerido.

O .htaccess usa Redirect para controlar qualquer solicitação para uma página específica (ou uma localização não específica que, infelizmente, leva a loops infinitos com certa facilidade). Se encontrar a dita solicitação, ele a redireciona para a página que você especificou:

Redirect /dirAntigo/arqAntigo.html http://seusite.com.br/dirNovo/arqNovo.html

Note que a diretriz possui 3 partes que precisam estar numa mesma linha: o comando Redirect, a localização do arquivo/diretório que você quer redirecionar relativa ao diretório raiz do seu site (/dirAntigo/arqAntigo.html corresponde a seusite.com.br/dirAntigo/arqAntigo.html) e a URL completa para onde a solicitação deve ser redirecionada. Cada uma das 3 partes é separada por UM espaço, mas tudo em uma única linha. Você também pode redirecionar um diretório inteiro usando simplesmente

Redirect /dirAntigo http://seusite.com.br/dirNovo/

Usando este segundo método, você pode redirecionar todo o conteúdo do diretório, independente do que você fizer com a sua estrutura de diretórios. É o método de efeito global mais rápido que existe.

Impedir listagem de diretórios

Se você tem diretórios repletos de gráficos, arquivos zip, mp3, etc e não quer que os usuários possam simplesmente listar estes diretórios, existem várias opções. Se a possibilidade de listar diretórios já não estiver desabilitada pelo seu serviço de hospedagem, você pode criar arquivos index.html, vazios ou não, e colocá-los em cada um dos diretórios que não devem ser listados ou, mais uma vez, fazer uso do .htaccess:

IndexIgnore *

O asterisco é um coringa indicando que todo e qualquer arquivo NÃO deve ser listado. Bingo! Se o arquivo .htaccess for colocado no diretório raiz, nenhum diretório poderá ser listado.

Por outro lado, se você quiser especificar o tipo de arquivo que não deve ser listado, faça o seguinte:

IndexIgnore *.gif *.jpg *.mp3

Neste caso, arquivos como .html, .txt, etc serão listados normalmente. Os .gif, .jpg e .mp3 não serão mostrados.

Agora, na situação oposta: seu servidor não permite a listagem de diretórios mas você quer que o faça. Adicione o seguinte:

Options +Indexes

Se você usar esta opção, cuidado para não colocar qualquer arquivo comprometedor nos diretórios atingidos pelo .htaccess. Você já deve ter percebido: o sinal mais (+) antes de Indexes força a listagem, então, Options -Indexes bloqueia inteiramente a listagem. É como o servidor Apache deveria estar configurado, o que nem sempre é o caso...

Se a listagem for permitida, então você pode mostrar que é um expert no assunto. Crie um arquivo com o nome HEADER, ponha nele a descrição da listagem e coloque no diretório alvo. O texto deste arquivo será mostrado antes da listagem do conteúdo do diretório. Também é possível criar um rodapé, que deve ter o nome de README. O conteúdo deste arquivo, que deve estar no mesmo diretório, é mostrado logo após a listagem do conteúdo.

Bloqueio de IP e domínios

Tem um abelhudo infernizando a sua vida? Bisbilhotando seu site e dando trabalho? Bloqueio nele!

Adicione o seguinte código no seu arquivo .htaccess (logicamente mudando os IPs para os desejados), cada diretriz numa linha própria e tomando cuidado para manter as maiúsculas e as minúsculas:

Order Allow,Deny

Deny from 123.45.6.7

Deny from 012.34.5.

Allow from all

A linha Order Allow,Deny indica a ordem na avaliação das permissões (Allow) e das recusas (Deny). A opção é Allow,Deny e, neste caso, primeiramente todas as recusas são analisadas. Se alguma delas for verdadeira, a solicitação é rejeitada; caso contrário, as permissões passam a ser analisadas.

Pode-se recusar endereços IP ou blocos de endereços IP. O código acima nega acesso ao site se as requisições vierem do endereço IP 123.45.6.7 ou de qualquer subdomínio do bloco IP 012.34.5. (012.34.5.1, 012.34.5.2, 012.34.5.3, etc). Imagine só, com a segunda opção você pode até bloquear acessos vindos de determinado país. Coisa de louco...

É claro que, se quiser, pode bloquear o acesso de todos usando Deny from all ao invés de Allow from all, mas isto não seria muito lógico - a não ser que queira fechar para balanço

Nem só de endereços IP vive o bloqueio. Você também pode usar nomes de domínios, por exemplo, Allow from .numaboa.com ou Deny from www.pentelho.com.br. O primeiro libera www.numaboa.com, sub1.numaboa.com, etc. O segundo bloqueia apenas o que vier de www.pentelho.com.br.

Evitar hot linking

Na comunidade webmaster, "hot linking" é uma expressão amaldiçoada. Também conhecido como "roubo de banda" (bandwidth stealing), refere-se a links apontando diretamente para objetos não-html em servidores que não sejam do proprietário do site. Geralmente são gráficos, arquivos de javascript e de flash referenciados a partir de um site concorrente. O servidor da vítima é espoliado em largura de banda uma vez que o safado se diverte mostrando o conteúdo de uma área que não lhe pertence. O tipo mais comum de roubo de banda é de imagens gráficas.

Com o .htaccess é possível impedir o hot linking de modo que os que tentarem roubar imagens hospedadas no seu site recebam uma "porta" (the door - uma imagem quebrada) ou caiam na "boca do leão" (the lion's mouth - uma imagem à sua escolha, hehehe). Tem apenas um pequeno senão: seu servidor precisa ter o mod_rewrite instalado e habilitado. Consulte seu serviço de hospedagem para confirmar.

Explicado o assunto, veja a seguir como desabilitar o hot linking de imagens no seu site. Simplesmente adicione o código a seguir num arquivo .htaccess e faça o upload para o diretório que desejar:

‘RewriteEngine onRewriteCond %{HTTP_REFERER}

‘!^$RewriteCond %{HTTP_REFERER} !^http://(www\.)?seudominio.com/.*$ ‘[NC]

‘RewriteRule \.(gif
jpg)$ - [F]

Certifique-se de ter trocado "seudominio.com" pelo seu verdadeiro domínio. O código acima faz com que a imagem fornecida apareça quebrada. Se você preferir determinar a imagem que deve substituir a solicitada através de uma hot link, acrescente o seguinte:

‘RewriteEngine onRewriteCond %{HTTP_REFERER}

‘!^$RewriteCond %{HTTP_REFERER} !^http://(www\.)?seudominio.com/.*$ ‘[NC]

‘RewriteRule \.(gif
jpg)$ http://www.seudominio.com/porcaria.gif [R,L]

O efeito do código acima é fornecer a imagem "porcaria.gif" ao invés da solicitada. Do mesmo modo, troque "seudominio.com" pelo nome correto.

Server Side Includes - SSI

SSI vem de Server Side Includes que, traduzido livremente, significa incluir o lado do servidor. Se o seu serviço de hospedagem não tiver ativado o SSI para o seu site e você quiser fazer uso do serviço, é possível ativá-lo através do .htaccess.

AVISO IMPORTANTE: obtenha uma PERMISSÃO do seu hospedeiro antes de ativar o SSI através do .htaccess. Pode ser considerado "hacking" e uma violação do contrato de hospedagem o fato de você fazer a ativação sem a devida autorização. Melhor prevenir do que tentar remediar...

Para ativar o SSI, inclua as seguintes diretrizes no seu arquivo .htaccess:

AddType text/html .shtml

AddHandler server-parsed .shtml

Options Indexes Follow

SymLinks Includes

A primeira linha indica ao servidor que páginas com a extensão .shtml (para HTML analisado pelo servidor) seja válida: AddType text/html .shtml

A segunda linha adiciona um manipulador (handler), na verdade o bit SSI, em todos os arquivos com a extensão .shtml. AddHandler server-parsed .shtml diz para o servidor que todas as páginas com nome .shtml devem ser analisadas para verificar a existência de comandos de servidor e, caso existam, devem ser executados.

A última linha são apenas tranqueiras técnicas, mas que precisam constar para completar a ativação. A diretriz Options diz quais ações do servidor devem ser disponibilizadas. Minha sugestão é que você dê uma espiada no SSI na documentação do Apache - escolha a versão certa do webserver!

Prontinho -- seu SSI deve estar ativado. Mas agora não pense que será necessário mudar o nome de todas as páginas do seu site! Use um expediente mais inteligente... e transforme todas as páginas .html em analisáveis adicionando a linha destacada em negrito:

AddType text/html .shtml

AddHandler server-parsed .html

AddHandler server-parsed .shtml

Options Indexes Follow

SymLinks Includes

Como tudo tem seu preço, aqui vai outro ALERTA: AddHandler server-parsed .html forçará a procura de comandos SSI em TODAS as páginas .html, mesmo as que não possuam comandos de servidor. Se você exagerar no uso de SSI no seu site, é claro que você vai estressar o servidor. O SSI faz com que o servidor fique mais lento porque ele acaba realizando muito mais tarefas para servir uma página analisada. Para os usuários, a diferença é praticamente imperceptível, mas para o servidor...

Por outro lado, há profissionais da área que preferem "esconder" que estejam utilizando SSI e usam o expediente acima. Se as páginas não têm a extensão .shtml, é provável que os hackers não tentem alguma coisa, mesmo porque o SSI é altamente "hackeável".

Se você quiser usar SSI apenas nas páginas com extensão .shtml mas quer, por exemplo, que todas as páginas index.html sejam SSI, basta adicionar a linha destacada em negrito:

AddType text/html .shtml

AddHandler server-parsed .shtml

Options Indexes Follow

SymLinks Includes

DirectoryIndex index.shtml index.html

Isto faz com que páginas index.shtml sejam as primeiras a serem procuradas num diretório (as chamadas páginas default). Caso não seja encontrada uma página com este nome, então a segunda opção passa a ser index.html. Mais adiante veremos mais sobre o DirectoryIndex.

Escondendo o .htaccess

Se você usa o .htaccess para proteger áreas do site com senhas, a informação da localização do arquivo de senhas pode ser facilmente obtida através do arquivo .htaccess. Se as permissões estiverem mal configuradas ou se o servidor não for dos mais seguros, um browser tem a possibilidade de mostrar o conteúdo do arquivo .htaccess através da interface padrão. Neste caso, tanto o seu site, como o servidor, estão comprometidos. Esta é a parte ruim da história. A parte boa é que é possível impedir que o .htaccess possa ser visto:

Order Allow,Deny

Deny from all

A primeira linha especifica que o arquivo chamado .htaccess possui uma regra. As regras ficam por conta da sua criatividade. Neste caso, a regra aplicada é emitir uma ordem de permissão e recusa com Order Allow,Deny e depois indicar que a leitura está bloqueada para todo mundo com Deny for all.

Com esta configuração, na maioria dos servidores, um usuário que tente ver este arquivo recebe um código de erro 403. Também é possível ajustar as permissões para o arquivo .htaccess através de um CHMOD para 644 ou RW-R--R--, uma medida de segurança adicional.