--- title: "Lista de verificação para distribuição" version: 6.0 locale: pt-br source: https://docs.djangoproject.com/pt-br/6.0/howto/deployment/checklist/ canonical: https://djangodocs.dev/pt-br/6.0/howto/deployment/checklist/ --- # Lista de verificação para distribuição A internet é um ambiente hostil. Antes de publicar seu projeto Django, você deve tirar um tempo para rever suas configurações, tendo em mente segurança, performance e operações. O Django inclui muitos [security features](/pt-br/6.0/topics/security/). Agumas são embutidas e sempre habilitadas. Outras são opcionais porque nem sempre são apropriadas, ou porque são inconvenientes para desenvolvimento. Por exemplo, forçar HTTPS talvez não seja bom para todos os websites e não prático para desenvolvimento local. Otimização de desempenho são outra categoria de “perde-ganha” com a conveniência. Por exemplo, “cache” é útil em produção, mas não em desenvolvimento. Necessidades de relatórios de erros também são amplamente diferentes. As seguinte lista de verificação inclui configurações que: - devem ser configuradas propriamente para que o Django forneça o nível esperado de segurança. - espera-se que sejam diferentes em cada ambiente. - habilitam características de segurança opcionais; - habilitam otimização de desempenho. - fornece relatório de erro. Muitas destas configurações são sensíveis e devem ser tratadas confidencialmente. Se você está publicando o código fonte do seu projeto, uma prática comum é publicar configurações adequadas para desenvolvimento, e usar o módulo de configuração para produção. ## Execute `manage.py check --deploy` Algumas das verificações descritas abaixo podem ser automatizadas usando a opção [`check --deploy`](/pt-br/6.0/ref/django-admin/#cmdoption-check-deploy). Assegure-se de executá-lo com o arquivo de configuração como descrito na documentação de configuração. ## Switch away from `manage.py runserver` The [`runserver`](/pt-br/6.0/ref/django-admin/#django-admin-runserver) command is not designed for a production setting. Be sure to switch to a production-ready WSGI or ASGI server. For a few common options, see [WSGI servers](/pt-br/6.0/howto/deployment/wsgi/) or [ASGI servers](/pt-br/6.0/howto/deployment/asgi/). ## Configurações críticas. ### [`SECRET_KEY`](/pt-br/6.0/ref/settings/#std-setting-SECRET_KEY) **A chave secreta deve ser um valor randômico e longo e deve ser mantido em segredo** Tenha ceteza que a chave usada em produção não é usada em nenhum outro local e evite “commitar” isso no código fonte. Isso reduz o número de vetores dos quais um atacante possa acessar a chave. Ao invés de “hardecodear” a chave secreta no módulo de configuração, considere carrega-lo de uma variável de ambiente: ``` import os SECRET_KEY = os.environ["SECRET_KEY"] ``` ou de um arquivo: ``` with open("/etc/secret_key.txt") as f: SECRET_KEY = f.read().strip() ``` If rotating secret keys, you may use [`SECRET_KEY_FALLBACKS`](/pt-br/6.0/ref/settings/#std-setting-SECRET_KEY_FALLBACKS): ``` import os SECRET_KEY = os.environ["CURRENT_SECRET_KEY"] SECRET_KEY_FALLBACKS = [ os.environ["OLD_SECRET_KEY"], ] ``` Certifique-se de que as chaves secretas antigas sejam removidas de `SECRET_KEY_FALLBACKS` em tempo hábil. ### [`DEBUG`](/pt-br/6.0/ref/settings/#std-setting-DEBUG) **Nunca habilite o debug em produção** Certamente você desenvolvimento seu projeto com [`DEBUG = True`](/pt-br/6.0/ref/settings/#std-setting-DEBUG), já que isso habilita características convenientes como “tracebakcs” no seu browser. Para o ambiente de produção, embora, isso é realmente uma má idéia, porque ele abre uma série de informações sobre seu projeto: dicas de seu código fonte, variáveis locais, configurações, bibliotecas usadas, etc. ## Configurações específicas de configurações ### [`ALLOWED_HOSTS`](/pt-br/6.0/ref/settings/#std-setting-ALLOWED_HOSTS) Quando [`DEBUG = False`](/pt-br/6.0/ref/settings/#std-setting-DEBUG), o Django não irá funcionar de maneira alguma sem um valor adequado para o [`ALLOWED_HOSTS`](/pt-br/6.0/ref/settings/#std-setting-ALLOWED_HOSTS). Essa configuração é requerida para proteger seu site de ataques CSRF. Se usar um caracter corínga, você deve fazer sua própria validação do cabeçalho HTTP do `Host`, ou de outra maneira tenha certeza que você não está vulnerável a esse tipo de ataque. Você também deve configurar o servidor web que fica na frente do Django para validar o host. Ele deve responder com uma página de erro estática ou ignorar solicitações de hosts incorretos em vez de encaminhar a solicitação para o Django. Desta forma você evitará erros espúrios em seus logs do Django (ou e-mails se você tiver o relatório de erros configurado dessa forma). Por exemplo, no nginx você pode configurar um servidor padrão para retornar “444 No Response” em um host não reconhecido: ```nginx server { listen 80 default_server; return 444; } ``` ### [`CACHES`](/pt-br/6.0/ref/settings/#std-setting-CACHES) Se você estiver usando um “cache”, os parâmetros de conexão do embiente de desenvolvimento talvez sejam diferentes dos parâmetros de produção. O padrão do Django é “per-processo” [local-memory caching](/pt-br/6.0/topics/cache/#local-memory-caching) o qual talvez não seja o desejável. Servidores de “cache” tem em geral uma autenticação fraca. Assegure-se que somente aceite conexões de seus servidores de aplicações. ### [`DATABASES`](/pt-br/6.0/ref/settings/#std-setting-DATABASES) Parâmetros de conexões de bancos de dados são provavelmente diferentes em desenvolvimento e em produção. Senhas de bancos de dados são muito sensíveis. Você deve protegê-las tal como o [`SECRET_KEY`](/pt-br/6.0/ref/settings/#std-setting-SECRET_KEY). Para máxima segurança, certifique que os servidores de bancos de dados somente aceitem conexões de seus servidores de aplicação. Se não configurou backup para seu banco de dados, faça isso já! ### [`EMAIL_BACKEND`](/pt-br/6.0/ref/settings/#std-setting-EMAIL_BACKEND) e configurações relacionadas Se seu site envia e-mails, estes valores precisam ser definidos corretamente. By default, Django sends email from `webmaster@localhost` and `root@localhost`. However, some mail providers reject email from these addresses. To use different sender addresses, modify the [`DEFAULT_FROM_EMAIL`](/pt-br/6.0/ref/settings/#std-setting-DEFAULT_FROM_EMAIL) and [`SERVER_EMAIL`](/pt-br/6.0/ref/settings/#std-setting-SERVER_EMAIL) settings. ### [`STATIC_ROOT`](/pt-br/6.0/ref/settings/#std-setting-STATIC_ROOT) e [`STATIC_URL`](/pt-br/6.0/ref/settings/#std-setting-STATIC_URL) Arquivos estáticos são automaticamente servidos pelo servidor de desenvolvimento. Em produção, você deve definir o diretório [`STATIC_ROOT`](/pt-br/6.0/ref/settings/#std-setting-STATIC_ROOT) onde o [`collectstatic`](/pt-br/6.0/ref/contrib/staticfiles/#django-admin-collectstatic) irá copiá-los. Veja [How to manage static files (e.g. images, JavaScript, CSS)](/pt-br/6.0/howto/static-files/) para mais informações. ### [`MEDIA_ROOT`](/pt-br/6.0/ref/settings/#std-setting-MEDIA_ROOT) e [`MEDIA_URL`](/pt-br/6.0/ref/settings/#std-setting-MEDIA_URL) Arquivos de media são enviados por usuários. Eles não são confiáveis! Assegure-se que seu servidor web nunca tente interpretá-los. Por exemplo, se um usuário enviar um arquivo `.php`, o servidor web não deve executá-lo. Agora é uma boa hora para verificar sua estratégia de backup para estes arquivos. ## HTTPS Qualquer website que possibilita autenticação de usuários deveria exigir HTTPS em todo o site para evitar a transmissão de tokens planos. No Djano, os tokes de acesso incluem o login/senha, a “cookie” da sessão e o token de reset de senha. (Não é possível fazer muito para proteger bem os tokens de reset de senha se são enviados via email). Proteger áreas sensíveis como a conta do usuário e o admin não são sificientes, porque o mesmo “cookie” de sessão é usado para HTTP e HTTPS. Seu servidor WEB deve redirecionar todas as requisições HTTP para HTTPS, e somente transmitir requests HTTPS para o Django. Uma vez que tenha configurado HTTPS, habilite as seguintes configurações. ### [`CSRF_COOKIE_SECURE`](/pt-br/6.0/ref/settings/#std-setting-CSRF_COOKIE_SECURE) Defina este como `True` para evitar transmissão do “cookie” de CSRF através de HTTP acidentalmente. ### [`SESSION_COOKIE_SECURE`](/pt-br/6.0/ref/settings/#std-setting-SESSION_COOKIE_SECURE) Defina este como `True` para evitar transmissão do “cookie” da sessão através de HTTP acidentalmente. ## Otimizações de desempenho. A Configuração [`DEBUG = False`](/pt-br/6.0/ref/settings/#std-setting-DEBUG) desabilita muitas características que são úteis somente em desenvolvimento. Além disso, você pode ajustar as seguintes configurações. ### Sessões Consider using [cached sessions](/pt-br/6.0/topics/http/sessions/#cached-sessions-backend) to improve performance. If using database-backed sessions, regularly [clear old sessions](/pt-br/6.0/topics/http/sessions/#clearing-the-session-store) to avoid storing unnecessary data. ### [`CONN_MAX_AGE`](/pt-br/6.0/ref/settings/#std-setting-CONN_MAX_AGE) Habilitando [persistent database connections](/pt-br/6.0/ref/databases/#persistent-database-connections) pode resultar em um bom aumento de velocidade no tempo de processamento de requisições quando se conecta a contas do banco de dados. Isso ajuda muito em Hosts virtualizados com desempenho de rede limitado. ### [`TEMPLATES`](/pt-br/6.0/ref/settings/#std-setting-TEMPLATES) Enabling the cached template loader often improves performance drastically, as it avoids compiling each template every time it needs to be rendered. When [`DEBUG = False`](/pt-br/6.0/ref/settings/#std-setting-DEBUG), the cached template loader is enabled automatically. See [`django.template.loaders.cached.Loader`](/pt-br/6.0/ref/templates/api/#django.template.loaders.cached.Loader) for more information. ## Relatório de erro Na hora em que o código é enviado para produção, espera-se robustez, mas não podemos ter erros inexperados. Menos mal, o Django pode capturar estes erros e noticá-los de acordo. ### [`LOGGING`](/pt-br/6.0/ref/settings/#std-setting-LOGGING) Reveja a sua configuração de log antes de colocar seu website em produção, e verifique se este está funcionando como esperado tão logo receba algum tráfego. Veja [Logging](/pt-br/6.0/topics/logging/) para detalhes de log. ### [`ADMINS`](/pt-br/6.0/ref/settings/#std-setting-ADMINS) e [`MANAGERS`](/pt-br/6.0/ref/settings/#std-setting-MANAGERS) [`ADMINS`](/pt-br/6.0/ref/settings/#std-setting-ADMINS) será notificado de erros do tipo 500 por email. [`MANAGERS`](/pt-br/6.0/ref/settings/#std-setting-MANAGERS) serão notificados de erros do tipo 404. [`IGNORABLE_404_URLS`](/pt-br/6.0/ref/settings/#std-setting-IGNORABLE_404_URLS) pode ajudar a filtrar erros ilegítimos. Veja [How to manage error reporting](/pt-br/6.0/howto/error-reporting/) para detalhes sobre relatórios de erros por email. > **Relatórios de erros por email não escalam muito bem.** > > Considere usar um sistema de monitoramento de erros tal como o [Sentry](https://docs.sentry.io/) antes que sua caixa postal seja cheia de relatórios. O Sentry pode também agregar logs. ### Customize as views de erro padrão Django includes default views and templates for several HTTP error codes. You may want to override the default templates by creating the following templates in your root template directory: `404.html`, `500.html`, `403.html`, and `400.html`. The [default error views](/pt-br/6.0/ref/views/#error-views) that use these templates should suffice for 99% of web applications, but you can [customize them](/pt-br/6.0/topics/http/views/#customizing-error-views) as well.