Ponha as palavras-passe e as chaves num ficheiro de configuração fora da pasta pública, com permissão de leitura só para a sua conta, e deixe o código ler esse ficheiro. Assim uma palavra-passe nunca fica num ficheiro que o navegador consiga abrir, nunca vai para um repositório, e muda-se num só sítio.
Montar, passo a passo
| 1 |
No File Manager, crie uma pasta ao lado de public_html (não dentro), por exemplo /home/SUACONTA/config.
|
|
| 2 |
Nela crie um ficheiro, por exemplo app.env, com uma linha por segredo, no formato NOME=valor.
|
|
| 3 |
Dê ao ficheiro a permissão 600 (Change Permissions, no File Manager): só o dono lê e escreve. O PHP da sua conta corre como a própria conta, por isso consegue lê-lo.
|
|
| 4 |
No código, leia o ficheiro em vez de escrever a palavra-passe lá dentro.
|
|
| 5 |
Confirme que o ficheiro não está acessível: tente abri-lo no navegador, a partir do endereço do seu site. Tem de dar 403 ou 404.
|
|
O ficheiro:
DB_HOST=localhost
DB_NAME=conta_basedados
DB_USER=conta_utilizador
DB_PASS=a-palavra-passe
E a leitura, sem instalar nada:
<?php
$cfg = parse_ini_file('/home/SUACONTA/config/app.env', false, INI_SCANNER_RAW);
$pass = $cfg['DB_PASS'];
Se o projecto usa o Composer, a biblioteca vlucas/phpdotenv lê ficheiros .env e é o que as frameworks costumam trazer. Veja o Composer na hospedagem partilhada.
Se o .env tem de ficar dentro do site
Algumas aplicações esperam o .env na raiz do projecto. Aí, o que protege é a estrutura: a pasta pública deve ser só a public da aplicação, como se descreve em pôr uma aplicação Laravel a correr. E acrescente o bloco que bloqueia ficheiros que começam por ponto, descrito em .htaccess para projectos PHP.
Duas boas práticas a juntar. Use valores diferentes para o site de testes e para o site a sério, para um engano num não afectar o outro. E dê a cada serviço a sua palavra-passe: se uma se perder, só se muda uma.
|
Um .env em public_html é público. Qualquer pessoa que escreva o endereço descarrega as suas palavras-passe, e há robôs que procuram precisamente esses nomes de ficheiro. Se isso aconteceu, mude já as palavras-passe (a da base de dados, no cPanel, e as chaves de qualquer serviço externo), em vez de só apagar o ficheiro.
|
|
Não envie o .env para um repositório. Ponha-o no .gitignore. Um segredo que passou pelo Git fica no histórico mesmo depois de apagado. Veja o Git no cPanel.
|
|
Isto não cifra nada. Quem tem acesso aos ficheiros da conta lê o ficheiro, e as nossas cópias diárias contêm-no, tal como as que descarregar. Guarde as suas cópias com cuidado. Dê à base de dados um utilizador só com os privilégios de que a aplicação precisa: criar um utilizador e dar-lhe os privilégios certos.
|
|
Não sabe se algum ficheiro com segredos está acessível pelo navegador? Diga-nos o domínio e verificamos consigo.
Abrir um pedido de suporte
|
PRODUTO RECOMENDADO Alojamento de sites com cPanel Domínio e SSL incluídos, cópias diárias e o painel que já conhece. desde 5.940,00 Kz/mês (plano de 3 anos, com cupão) Ver planos |
Português
English
