Gerenciador de URL de vaidade para o Apache Web Server

Question

Estou procurando uma ferramenta que gerencie URLs de vaidade para um único domínio em execução no Apache (ou IHS - IBM HTTP Server).

O que quero dizer com URL de vaidade:

• www.mycompany.com/ProjectA seria redirecionar para %código%
• servera.mycompany.com/whatever seria redirecionar para %código%
• www.mycompany.com/ProjectB seria redirecionar para %código%
• etc etc

A solução atual implementada consiste em milhares de diretórios atualizados manualmente com scripts php que redirecionam o usuário. Isto veio um pesadelo de manutenção. A conversão desta solução em uma solução usando arquivos atualizados manualmente .htaccess não é uma opção *.

Idealmente, essa ferramenta seria:

• trabalhe para um servidor da web apache / IHS
• fornece uma interface da web para usuários e administradores
• permite que os usuários criem, excluam e atualizem URLs personalizadas
• permite que os usuários especifiquem a diferenciação entre maiúsculas e minúsculas ou insensibilidade a maiúsculas e minúsculas para cada URL personalizada
• permite que os usuários especifiquem redirecionamentos como HTTP 301 (permanente) ou HTTP 302 (temporário) para cada URL de cortesia
• permite que os usuários especifiquem cada URL personalizada como permanente (para produtos) ou temporária com uma data de 'retirada' (para campanhas de marketing).
• fornecem aos usuários de fluxo de trabalho para enviar solicitações de URL de vaidade e para outras aprovarem
• (como uma solução possível) escreva um único arquivo .htaccess gerenciado, desde que o arquivo seja validado pela ferramenta antes de empurrá-los para o servidor, para que ele não tenha um impacto negativo no servidor.
• (como uma solução possível) escreva diretórios com arquivos redirecionados / .htaccess, mas também gerencie a criação, atualização e exclusão desses diretórios.
• possivelmente use um back-end de banco de dados ou um back-end de xml.
• forneça uma solução que atenda a esses critérios de uma maneira que não pensei.
• (opcional) fornece relatórios muito simples (número de URLs permanentes, número de URLs temporários, URLs temporárias futuras que estão expirando etc.)

* usando um único arquivo .htaccess editado manualmente é um risco muito grande se um erro for colocado no arquivo, pode afetar todos os URLs. Vários arquivos .htaccess, localizados em diretórios, são o mesmo pesadelo de manutenção que o uso de redirecionamentos php.

    

Answer 1

Eu não sei exatamente o que define um "pesadelo de manutenção" em seu livro, mas você pode tentar usar um mapa de reescrita dinâmico no apache:

RewriteEngine on
RewriteMap    vanity-map       prg:/path/to/vanity.pl
RewriteRule   ^/(.*)/(.*)$  /${vanity-map:$1}/$2

vanity.pl poderia ser um script em perl simples (não se esqueça de definir $| = 1; ) que obtém a primeira parte do URL de solicitação (conforme descrito acima) em STDIN e deve reescrever isso - por exemplo, consultando um banco de dados.

Agora, isso deixa o frontend. Eu sou um inexperiente programador Ruby on Rails (é apenas uma atividade de tempo livre), mas eu acho que, se não precisa ser bonito, até eu poderia escrever um aplicativo que autentica um usuário, permite que ele crie uma reescrita e mostre Que para aprovação de alguns caras de TI / $ WHAVERVER em muito menos de uma semana, então eu não acho que qualquer programador real teria um problema em fazer isso em poucas horas. Dependendo do banco de dados, pode haver até front-ends prontamente disponíveis, que farão o trabalho com apenas um pouco de personalização (php * admin vem à minha mente).

Dessa forma, você obtém toda a flexibilidade de uma abordagem de banco de dados emparelhada com uma fonte central para todos os redirecionamentos. Contanto que o índice do banco de dados na parte da URL se encaixe na memória do seu servidor, você não precisará se preocupar com o desempenho.

    

Answer 2

Eu só vi isso acontecer no verso. Por exemplo, webmail.domain.tld redirecionando para domain.tld/squirrel .

Eu não acho que você pode fazer o que descreve via DNS: depois de passar do domínio para o caminho, você deixou o domínio do DNS alças.

Você está descrevendo um encurtador de URL, como o TinyURL. Mas isso envolveria as mesmas dores de cabeça de manutenção que você já descreveu.