Redirecionar para o parâmetro de URL codificado em% usando mod_rewrite em .htaccess

Question

Há algumas coisas que estou tentando entender em relação a um RewriteRule .

A regra de trabalho em um URL retira uma consulta para um redirecionamento, por exemplo, o URL:

https://www.example.com/application?user=543&AppLink=https://www.example.net/register/reg.aspx?EnquiryID=12345

O código .htaccess de trabalho:

RewriteCond %{REQUEST_URI}  ^/application$
RewriteCond %{QUERY_STRING} .*AppLink=(.*)
RewriteRule ^(.*)$ %1 [R=302,L]

Resulta em (corretamente) o URL de redirecionamento:

https://www.example.net/register/reg.aspx?EnquiryID=12345

Tudo bem até que eu queira introduzir a codificação de URL no link da consulta, por exemplo:

https://www.example.com/application?user=543&AppLink=https%3A%2F%2Fwww.example.net%2Fregister%2Freg.aspx?EnquiryID=12345

Primeiro, a introdução da codificação quebra o trabalho RewriteRule , resultando no nome http_host de volta - não entendo por que isso acontece:

https://www.example.com/https%3A%2F%2Fwww.example.net%2Fregister%2Freg.aspx?EnquiryID=12345

Portanto, estou tentando descobrir a melhor maneira de "decodificar" / remover o (por exemplo) %3A%2F%2F de volta em dois-pontos e barras antes de ele puxar a consulta como uma URL válida para a função de redirecionamento.

Estou supondo que, de certo modo, eu preciso criar um RewriteRule de "looping" para arrumar a codificação (regex), redirecionando-a para o mesmo host, removendo a URL válida e enviando-a para o host redirecionado! / p>

Sujo e sobrecarga, sim.

Alguém tem uma sugestão ou pensamentos sobre a melhor maneira de atacar isso?

    

Answer 1

...the best way to attack this?

Esta é realmente uma tarefa para sua aplicação web (por exemplo, PHP, Python, etc.), não para o Apache ( .htaccess ).

Se este script for "público", então ... "Redirecionar" scripts desta natureza são frequentemente abusados por golpistas ( por exemplo , então você precisa listar em branco os possíveis destinos de redirecionamento (e, opcionalmente, autenticar o remetente). Isso pode ser difícil de implementar em .htaccess e provavelmente é mais adequado para o seu próprio aplicativo.

https://www.example.com/application?user=543&AppLink=https%3A%2F%2Fwww.domain2.com%2Fregister%2Freg.aspx?EnquiryID=12345

Os caracteres : e / não precisam ser codificados por URL quando aparecerem na parte da string de consulta do URL. Mas se você codificasse corretamente o URL do valor do parâmetro AppLink URL, você também codificaria%% do ? e = (parte do URL de destino).

First up, the introduction of the encode breaks the working RewriteRule, resulting in this with the http_host name back in - I don't follow why it does that:

A variável do servidor QUERY_STRING não é% -decoded. Então, a string resultante substituição é:

https%3A%2F%2Fwww.example.net%2Fregister%2Freg.aspx?EnquiryID=12345

Apache / mod_rewrite vê isso como uma URL relativa , porque ela não inicia com uma barra ou esquema válido (por exemplo, https:// ). No caso de uma URL relativa, mod_rewrite usa o esquema e o nome do host (e prefixo de diretório ou valor da diretiva RewriteBase ) da solicitação atual (por padrão), para construir uma URL absoluta para o external redirecionar , daí o redirecionamento malformado que você está vendo.

Solução

Como mencionado acima, eu recomendaria fazer isso em seu aplicativo, não em .htaccess . Mas de qualquer forma, para responder a sua pergunta específica, você poderia fazer algo como o seguinte, em vez de suas diretivas atuais. No entanto, isso requer o Apache 2.4+ e o acesso ao seu server-config (já que AllowEncodedSlashes não é permitido em um diretório / .htaccess context):

Os itens a seguir precisam estar em seu server-config (ou virtualhost):

# Allow %2F to be used in the URL-path part of the URL
# Otherwise Apache will trigger a system generated 404 (security feature)
AllowEncodedSlashes On

Então, em .htaccess :

# Convert URL param value to path-info (via URL rewrite)
# This essentially %-decodes the URL parameter value
RewriteCond %{QUERY_STRING} AppLink=(.+)
RewriteRule ^application$ /application/%1 [QSD]

# Issue redirect using the %-decoded URL-path
RewriteRule ^application/(https?:/)(.+) $1/$2 [R,L]

Notas:

• Quando possível, é mais eficiente verificar o caminho da URL usando o padrão RewriteRule em vez de usar uma condição adicional que verifica o servidor REQUEST_URI variável.
• O sinalizador QSD (Query String Discard) é necessário para descartar o parâmetro de URL AppLink (e qualquer outro) da solicitação inicial.
• A primeira reescrita de URL é passada para a próxima diretiva que aciona o redirecionamento real. As diretivas RewriteRule naturalmente se encaixam juntas, a saída de uma é usada como entrada da próxima e assim por diante.
• O caminho do URL com o qual o padrão RewriteRule é correspondido é% -decoded. (Considerando que a variável de servidor QUERY_STRING permanece% -codificada.) No entanto, as barras contíguas no caminho da URL são reduzidas a barras únicas. Daí a verificação de apenas https:/ (não https:// ) no padrão RewriteRule e da barra adicional que é adicionada na substituição .

Isso também pressupõe que informações adicionais de nome de caminho são permitidas em sua configuração. Talvez seja necessário definir explicitamente AcceptPathInfo On em .htaccess (ou server-config), se não. Se não, então você também terá um sistema gerado 404.