Pergunta

Eu estou tentando proteger o diretório ~/public_html/dev usando http autenticação básica, mas para fazer que garantir que eu quero para executá-lo através de SSL.

A seção do meio do arquivo abaixo .htaccess muda para https se o pedido URI começa com /dev e obras.

A última seção do arquivo funciona bem, mas não funciona corretamente com o https redirecionamento.

Basicamente, eu quero ser capaz de escrever http://www.example.com/dev/some_sub_dir/ e ser redirecionado para https://www.example.com/dev/some_sub_dir/ e solicitado o http auth nome de usuário e senha.

O que acontece actualmente é que se eu ir para http://www.example.com/dev/some_sub_dir/ eu me for solicitado um nome de usuário e senha através da porta 80, e logo em seguida se solicitado novamente pela porta 443. Então minhas credenciais estão sendo enviadas duas vezes, uma em claro, e uma vez criptografado . Tornando todo o https URL reescrever um pouco sem sentido.

A razão para fazer isso é para que eu não será capaz de enviar acidentalmente meu usuário / passar sobre http; https será sempre usado para acessar o diretório /dev.

O .htaccess está no diretório ~/public_html/dev.

# Rewrite Rules for example.com
RewriteEngine On
RewriteBase /

# force /dev over https
RewriteCond %{HTTPS} !on
RewriteCond %{REQUEST_URI} ^/dev
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

# do auth
AuthType Basic
AuthName "dev"
AuthUserFile /home/matt/public_html/dev/.htpasswd
Require valid-user
Foi útil?

Solução

Há um corte relativamente popular para forçar HTTPS antes de fazer autenticação básica. A primeira vez que vi isso aqui:

http://blog.jozjan.net/2008/02 /htaccess-redirect-to-ssl-https-before.html

Ele envolve o uso de um documento de erro personalizada para lidar com o que acontece após a verificação de HTTPS falhar.

Por exemplo, eu tenho uma única página que preciso para forçar HTTPS, então eu fiz isso em um arquivo .htaccess:

<FilesMatch "secure-page.php">
    SSLRequireSSL
    ErrorDocument 403 https://www.example.com/secure-page.php
    AuthType Basic
    AuthName "Secure Page"
    AuthUserFile /var/www/whatever/.htpasswdFile
    Require valid-user
</FilesMatch>

que se traduz em:

Se a página solicitada é 'seguro-page.php' - se não HTTPS, em seguida, redirecionar para um costume 'página de erro' - a 'página de erro' é realmente apenas a versão HTTPS da página - no segundo pedido, desde o HTTPS Verificar agora passa, execute Auth básica:)

Você pode estender este conceito a um diretório ou outro uso casos - o seu costume 'página de erro' poderia ser uma página php que redireciona para a correta HTTPS URL, ou um script CGI como no link acima ...

Outras dicas

Eu corri para o mesmo problema e, finalmente, encontrou uma solução feio, mas funciona. Coloque a regra de reescrita numa directiva Directory no httpd.conf ou um dos seus arquivos conf.d (ou seja, na configuração do servidor "principal"). Em seguida, coloque o Auth * e exigem linhas numa directiva Diretório dentro o recipiente <VirtualHost _default_:443> em ssl.conf (ou onde quer que o seu SSL VirtualHost é definido).

Para mim, isso significa criar um /etc/httpd/conf.d/test.conf arquivo com:

<Directory "/var/www/html/test">
        #
        # force HTTPS
        #
        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</Directory>

... e, em seguida, adicionar o seguinte dentro /etc/httpd/conf.d/ssl.conf logo acima da tag </VirtualHost>:

<Directory "/var/www/html/test">
        #
        # require authentication
        #
        AuthType Basic
        AuthName "Please Log In"
        AuthUserFile /var/www/auth/passwords
        Require valid-user
</Directory>

Isso faz Apache aplicar o RewriteRule a todos os pedidos, e os requisitos de autenticação apenas aos pedidos do 443 VirtualHost.

Com base na resposta de siliconrockstar, estou adicionando um script php que iria trabalhar no caso onde você quer SSL vigor em todas os arquivos, não apenas o caso de um arquivo mostradas por siliconrockstar. Aqui, novamente, ele funciona em conjunto com o arquivo .htaccess.

O htaccess para proteger a diretório inteiro:

    SSLRequireSSL
    ErrorDocument 403 /yourphp.php
    AuthType Basic
    AuthName "Secure Page"
    AuthUserFile /some_path_above_the_html_root/.htpasswdFile
    Require valid-user

O php chamado pelo htaccess (o caminho dado para o php nesta htaccess amostra é a raiz do seu site), que forças https na URL que você chamado:

<?php
$path = "https://".$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'];
if ( $_SERVER['SERVER_PORT'] == 80) {
    header("Status: 302 Moved\n");
    header("Location: ".$path."\n\n");
}
else {
    header( "Content-type: text/html\n\n");
    echo "How did you get here???";
}
?>

Se o seu site não tem um certificado SSL, você terá que instalar um. Se este é o seu uso apenas para ele, você pode instalar um certificado auto-assinado. Em um VPS cPanel com o seu site em um IP dedicado, que tem momentos que fazer: no WHM, visita

Um. Gerar um certificado SSL e Solicitação de Assinatura

então

Dois. Instalar um certificado SSL em um domínio

Protegendo o conteúdo com autenticação básica nunca vai funcionar de forma segura através de HTTP.

Uma vez que o usuário inseriu seu nome de usuário e senha, ele é enviado sem criptografia para cada exibição de página para esse site -. Não é apenas enviada a vez que o usuário se solicitado

Você tem que solicitações de tratar mais de HTTP como un-autenticados, e não todas logado coisas através de HTTPS.

Um monte de sites têm utilizado HTTPS para o login - usando formas e biscoitos, em vez de autenticação básica - e depois ir para HTTP depois. Isso significa que o seu 'você está conectado em' bolinho é enviada sem criptografia. Cada alvo valioso foi cortado por causa disso, e gmail está agora a mudança para full HTTPS e outros se seguirão.

Você não tem os mesmos problemas de escala que outros tiveram que manteve-los longe da computacionalmente mais caro HTTPS. Se sua página inicial suportes acesso HTTPS, usá-lo por toda parte.

Se você colocar a reescrever as regras na configuração principal, fora de qualquer ou ou similar, reescrevendo será feito antes da autenticação.

Rewrite tecnologia

Será que funciona para colocar a sua seção de autenticação em um <Location> ou <LocationMatch> tag usando o protocolo como o termo?

Eu contorná-la dessa maneira. Apenas permitir que não-SSL, uma vez que será redirecionado, então, exigir auth uma vez em SSL ...

SetEnvIf %{SERVER_PORT} ^80$ IS_NON_SSL

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

AuthUserFile /.htpasswd
AuthName "Enter your Username and Password:"
AuthType Basic
require valid-user
Allow from env=IS_NON_SSL

Eu sei que isto é uma questão de idade, mas eu tive problemas com um simples redirecionamento ht.access. Após muitos outros problemas e respostas eu finalmente juntos este htaccess que funciona como pretendido.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

AuthName "Private Server"
AuthUserFile /var/www/.htpassword
AuthType Basic
require valid-user
Order allow,deny
Allow from env=!HTTPS
Satisfy Any

Para anotar o

Order allow,deny

que é o que estava faltando em muitas outras respostas que tenho visto, uma vez que permitiria que as pessoas nos diretamente ao usar https. A outra seção que estava faltando meus testes foi o seguinte:

Satisfy Any

Este trecho a seguir é o que permite que os clientes não SSL com para o redirecionamento. O var HTTPS env é definido a partir do mod_ssl para clientes de SSL.

Allow from env=!HTTPS

Eu tenho duas respostas para a pergunta, um com uma mentalidade de 2010, e um com uma mentalidade pós-2012.

Para responder a esta pergunta como se fosse 2010, quando foi perguntado:. Uso duas configurações VirtualHost diferentes

Esta solução é um pouco fora do âmbito da questão como a implicação é "Eu só tenho acesso para modificar .htaccess!" mas uma solução viável em muitos casos é solicitar o administrador du jour simplesmente configuração duas configurações VirtualHost diferentes.

  • O não-SSL VirtualHost não está configurado para acessar qualquer coisa no sistema de arquivos, e só retorna 301 redirecionamentos para locais https://... para todas as solicitações.

  • O SSL ouvir VirtualHost é livre para implementar autenticação básica sem se preocupar que o ouvinte HTTP padrão vai doar as mercadorias.

No entanto, com o meu chapéu pós-2018, e observando que esta pergunta foi feita antes Apache 2.4 (início de 2012?), O tempo é para uma atualização. Apache 2.4 introduziu <If condition> cheques, o que torna isso muito mais fácil e mais direto:

  • Em primeiro lugar, não IfModule o RewriteEngine. Como Apache está escutando tanto a porta 80 e 443 (na configuração padrão), e queremos impor SSL, queremos que o servidor para quebrar se o módulo Rewrite é outra forma desengatada.

    RewriteEngine On 
    
  • Em segundo lugar, simplesmente suficiente, realizar uma (301) redirecionamento imediato e permanente, se o pedido não é seguro. Observe a R (edirect) e L (AST), que trabalham em conjunto para garantir que os pedidos não criptografados são redirecionados e não pode ser utilizado para ganhar acesso não autenticado. (Para o OCD, não copiar e colar mente, observe o falta de espaço entre != e on. Isso é intencional.)

    RewriteCond %{HTTPS} !=on 
    RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,QSA,L,NC]
    
  • Finalmente, usar essa mesma variável com uma verificação <If-condition> para garantir que apenas exigem a senha para o pedido TLS.

    <If "%{HTTPS} == 'on'">
            AuthName "Password please!" 
            AuthType Basic 
            AuthUserFile /path/to/htpasswdfile
            AuthGroupFile /dev/null 
            require valid-user
    </If>
    

E por completo:

# .htaccess

RewriteEngine On

RewriteCond %{HTTPS} !=on
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,QSA,L,NC]

<If "%{HTTPS} == 'on'">
        AuthName "Password please!"
        AuthType Basic
        AuthUserFile /path/to/htpasswdfile
        AuthGroupFile /dev/null
        require valid-user
</If>
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top