Pôs o Django online e aparecem três erros que quase todos encontram: DisallowedHost, CSRF verification failed e a página sem estilos (os ficheiros estáticos dão 404). Têm uma coisa em comum: no seu computador funcionava porque o DEBUG estava ligado e o endereço era localhost. A resposta curta: são três definições do settings.py que têm de conhecer o domínio verdadeiro. Para pôr o Django a correr, veja primeiro o artigo base.
Os três erros, uma linha cada
| Erro |
Causa |
Solução no settings.py |
DisallowedHost: Invalid HTTP_HOST header |
O domínio com que abriu o site não está na lista de anfitriões permitidos. |
ALLOWED_HOSTS = ["asuaempresa.co.mz", "www.asuaempresa.co.mz"]. Inclua todos os nomes com que o site se abre. |
CSRF verification failed (403) ao enviar um formulário |
Por trás de HTTPS, o Django não confia na origem do formulário. |
CSRF_TRUSTED_ORIGINS = ["https://asuaempresa.co.mz", "https://www.asuaempresa.co.mz"]. Desde o Django 4.0 tem de levar o protocolo. |
Página sem estilos; ficheiros em /static/ dão 404 |
Com DEBUG = False o Django deixa de servir os estáticos. |
Defina STATIC_ROOT, corra python manage.py collectstatic e sirva essa pasta pelo servidor web (veja abaixo). |
Os estáticos, passo a passo
| 1 |
Defina as duas linhas no settings.py:STATIC_URL = "/static/"
STATIC_ROOT = BASE_DIR / "staticfiles"
|
|
| 2 |
Junte tudo numa só pasta, dentro do ambiente da aplicação: python manage.py collectstaticRepita depois de cada actualização que mexa em ficheiros estáticos.
|
|
| 3 |
Faça o servidor web servir essa pasta. No cPanel, a forma simples é copiar (ou ligar) o conteúdo da staticfiles para uma pasta dentro da pasta pública do domínio, no caminho que o STATIC_URL indica. Num VPS, o nginx serve-a com um bloco location /static/ e um alias.
|
|
| 4 |
Reinicie a aplicação e recarregue sem cache (Ctrl+F5).
|
|
Há uma alternativa que dispensa o passo 3: o pacote whitenoise, que deixa o próprio Django servir os estáticos com eficiência. Segue-se a documentação dele: instala-se com o pip e acrescenta-se ao MIDDLEWARE.
Não resolva deixando o DEBUG = True. Com ele ligado, qualquer erro mostra a quem visita os seus caminhos, as definições e, por vezes, credenciais. O Django exige ALLOWED_HOSTS precisamente quando o DEBUG está desligado. Também nunca use ALLOWED_HOSTS = ["*"] em produção.
|
Atrás de um proxy com HTTPS (nginx num VPS), diga ao Django que o pedido original era seguro, ou o CSRF e os redireccionamentos falham: SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https"), e só se o proxy enviar esse cabeçalho e o apagar nos pedidos que vêm de fora. Veja gunicorn e systemd num VPS. Para as senhas e a chave secreta: variáveis de ambiente e segredos.
|
|
Ajustou o settings.py e o erro continua? Envie-nos o domínio e as últimas linhas do registo da aplicação.
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 321,75 MT/mês (plano de 3 anos, com cupão) Ver planos |
Português
English
