Comment déployer Django

PARTIE 1. La sécurité avant tout

Le meilleur moment pour corriger les vulnérabilités est pendant le développement.

1.1 CSRF TOKEN

Dans le cadre de sécurité de Django, CSRF TOKEN est une stratégie de sécurité cruciale. Cependant, dans de nombreux cas, certains étudiants qui viennent d'entrer en contact avec Django constateront que le formulaire qu'ils ont finalement écrit signalera une erreur lors du POST. Après quelques recherches, ils découvrent qu'il s'agit d'un problème de CSRF TOKEN, puis suivent la ligne. méthode pour diviser le formulaire par trois, cinq et deux. Toutes les configurations CSRF TOKEN dans settings.py ont été supprimées et le code s'est exécuté normalement. Vous ne savez pas que ce type d'opération affectera grandement la sécurité du site Web et augmentera le coût de la correction ultérieure des vulnérabilités ; éliminer les problèmes de sécurité pendant la phase de développement est le coût le plus bas.

Étant donné que la documentation officielle a expliqué en détail le contenu pertinent du CSRF TOKEN, l'utilisation spécifique ne sera pas décrite ici. Ici, nous recommandons une utilisation plus pratique, moins sensible aux développeurs pendant le développement et qui n'a pas à se soucier de savoir si le jeton a été envoyé avec succès.

Ajoutez {% csrf_token %} à la page totale du modèle parent et définissez les éléments suivants dans la section <script> : </script>

De cette façon, tous les non-GET|HEAD|OPTIONS| initiés via AJAX dans Les requêtes JQuery TRACE incluront automatiquement CSRF TOKEN (une partie du code pour obtenir CSRF TOKEN n'est pas répertoriée). Si vous utilisez d'autres bibliothèques HTTP ou Fetch, effectuez simplement les paramètres correspondants.

1.2 Conception de la sécurité des API

Dans certains cas, notre service Web fournira également certains services API au monde extérieur pour les appels provenant d'autres systèmes. Pour ces interfaces API, CSRF doit être désactivé, sinon ils ne pourront pas l'être. utilisé normalement. Nous devrions également prendre d’autres mesures de sécurité pour empêcher toute utilisation abusive des interfaces API. En plus des paramètres de passage normaux, nous devons nous assurer que ces paramètres ne sont pas falsifiés par des intermédiaires et permettre uniquement aux personnes autorisées d'appeler l'interface correspondante. Pour cette raison, nous devons introduire plusieurs paramètres de passage supplémentaires : horodatage, signe, access_key, access_token.

Cette paire de paramètres comprend access_key et access_token. access_key équivaut à identifier l'appelant, et access_token équivaut à la clé secrète de l'appelant. Le contenu de access_token ne doit pas être facilement prédit, et access_key peut choisir une chaîne plus simple pour la commodité de la mémoire. Ce n'est que lorsque les deux paramètres correspondent que l'appel API est considéré comme légal.

Choisissez la précision de l'horodatage en fonction des besoins de l'entreprise, vous pouvez choisir des secondes ou des millisecondes. L'objectif principal de l'ajout d'un horodatage est d'empêcher la réexécution de cet appel. Le serveur doit vérifier si l'horodatage transmis par le client se situe dans une plage horaire. Les horodatages qui expirent doivent être considérés comme des demandes illégales. Afin de garantir l'authenticité des paramètres, un autre signe de paramètre doit être introduit, car même si l'horodatage est relu, il existe toujours un risque de falsification.

sign est la valeur de signature de tous les paramètres. Elle est générée par toutes les valeurs de paramètres participant au calcul de hachage. Chaque fois que les paramètres changent un peu, le signe doit être régénéré pour garantir l'authenticité des paramètres. Un algorithme couramment utilisé est le suivant : trier la valeur du paramètre selon l'ordre alphabétique de la clé du paramètre et utiliser des séparateurs spécifiques pour connecter tous les paramètres, puis effectuer un calcul de hachage et transmettre ensemble le paramètre de signe au serveur. Par exemple, le paramètre existant ak=2222&at=1111&timestamp=3333&key1=aaa, après tri par ordre alphabétique, est 22221111aaa3333, après avoir ajouté le séparateur (|), il est 2222(|)1111(|)aaa(|)3333, puis Cette chaîne calcule sha1 et génère la valeur du signe. Il est relativement simple de l'écrire en code Python :

1.3 Quelques éléments divers

En plus des deux points plus importants ci-dessus, certains endroits nécessitent une attention supplémentaire.

Désactivez le mode DEBUG dans l'environnement de production ;

N'ajoutez pas settings.py à la gestion des versions et protégez SECRET_KEY ;

Définissez ALLOWED_HOSTS ; possible, évitez d'exécuter directement des instructions SQL via des méthodes telles que .raw(), assurez-vous d'échapper correctement les paramètres pour éviter les vulnérabilités d'injection SQL ;

Désactivez Django Admin autant que possible ; utilisez-le, veuillez le modifier. Changez l'URL d'administration par défaut ;

PARTIE 2. Comment déployer

Extrayez le code de git, utilisez pip pour installer les dépendances du projet et exécutez le service via manage.py. , mais comptez-vous vraiment l’utiliser en production ? Est-ce le cas dans l’environnement ?

2.1 Environnement isolé

Dans des circonstances normales, il n'y aura qu'un seul environnement Python sur notre serveur. Lors du déploiement, nous installons généralement les dépendances requises pour le projet via pip. Ces packages seront installés dans les packages de site globaux dans le. annuaire.

Lors du déploiement de plusieurs projets, cette méthode d'installation des dépendances peut facilement conduire à des conflits de dépendances. Pour donner un exemple simple, nous avons maintenant deux projets, Project-A et Project-B. A et B dépendent de différentes versions du package tiers Third-A lorsque nous installons -r Requirements-a.txt via pip. , La dépendance Third-A est installée dans l'environnement Python global. Lorsque nous réinstallerons pip install -r Requirements-b.txt, Third-A sera également réinstallé à ce moment-là, si les versions dont dépendent les deux projets. sont incohérents, par exemple le projet A nécessite la version 1.0 et le projet B nécessite la version 2.0, ce qui entraînera des conflits de dépendances et l'échec de l'installation des dépendances.

Alors comment résoudre ce problème ? Ce à quoi nous pouvons facilement penser, c'est que si nous disposons de plusieurs environnements d'isolation indépendants et que chaque projet est déployé dans un environnement indépendant, alors ce problème sera facilement résolu. Virtualenv est né pour résoudre ce problème. Il peut créer un environnement d'exécution distinct pour chaque projet afin d'éviter les conflits de dépendances.

2.2 Gestion des versions

Nous savions plus tôt comment créer des environnements isolés et déployer différents projets dans différents environnements, mais il y a un problème. La version Python utilisée par tous les environnements est la même. Si vous avez besoin de déployer plusieurs versions différentes de projets Python, tels que Python 2.7 (je sais que cette version ne sera pas maintenue bientôt, mais je vais donner un exemple ici), les projets Python 3.6 et Jython, les installer un par un semble un peu compliqué. Même lors de la compilation et de l'installation, un certain paramètre de compilation est accidentellement manquant et doit être recompilé, ce qui augmente dans une certaine mesure la charge de travail de déploiement.

Nous pouvons utiliser pyenv pour gérer les problèmes de plusieurs versions de Python, et utiliser en outre le plug-in pyenv pyenv-virtualenv pour gérer les problèmes de plusieurs versions de Python et de plusieurs environnements virtuels.

2.3 Interface de passerelle

Après avoir résolu les problèmes dans divers environnements, il est temps de réfléchir à la façon d'exécuter le projet. Si vous pensez à python manage.py runserver 0.0.0.0:80, c'est un peu trop. Simple.

Django a intégré une implémentation WSGI simple pour nous permettre de démarrer le service Web via la méthode ci-dessus. Si vous souhaitez simplement déboguer ou fournir des services à quelques personnes, c'est également une solution facultative. Je n’ai pas l’air très élégant.

Si vous souhaitez vraiment déployer l'application dans un environnement de production réel, vous avez également besoin d'un serveur WSGI hautes performances, et non du simple serveur WSGI fourni par Django. Gunicorn et uWSGI sont tous deux des serveurs WSGI relativement courants, choisissez simplement l'un d'entre eux en fonction de l'environnement de déploiement réel.

Cependant, je préfère personnellement Gunicorn. Bien que uWSGI ait le dessus dans de nombreux tests de performances, la raison pour laquelle j'ai choisi Gunicorn est qu'il est très simple par rapport à uWSGI et n'a pas de fonctions très complexes et rarement utilisées. ses fonctions ont été progressivement prises en charge par Nginx, et Gunicorn est relativement simple et pratique à configurer. Une autre chose à noter est que si vous souhaitez déployer sur Windows, vous devrez peut-être utiliser Apache+mod_wsgi.

2.4 Proxy inverse

Après le démarrage de notre serveur WSGI, nous devons considérer la question du proxy inverse. La raison pour laquelle il existe une autre couche de Nginx pour effectuer le proxy inverse est pour les raisons suivantes :

Nginx est requis pour. gérer les ressources statiques. Si vous définissez le mode DEBUG de Django sur False, vous constaterez que de nombreuses ressources statiques telles que CSS et JS ne peuvent pas être chargées, car Django ne gérera pas activement ces requêtes et Nginx doit aider à les gérer.

Utilisez Nginx ; pour effectuer l'équilibrage de charge de plusieurs backends. Si votre service est déployé sur plusieurs serveurs, ou dispose d'un déploiement principal et d'un déploiement de sauvegarde, ceux-ci peuvent être réalisés via des paramètres simples sur Nginx

Il existe certains problèmes liés à l'exposition directe des risques de sécurité uWSGI ou Gunicorn, il sera plus pratique de le faire. utilisez Nginx pour gérer les problèmes HTTP ;

De plus, il y a certaines raisons qui ne sont pas répertoriées ici Encore une fois, si votre service est très simple et que seules quelques personnes y accèdent, il n'est pas nécessaire d'effectuer des réglages aussi compliqués.

2.5 Process Daemon

À partir de maintenant, nous avons déployé avec succès le service et pouvons commencer à fournir des services normalement. Mais on y pense moins si notre Django s'arrête malheureusement pour une raison inconnue, alors notre service Web deviendra un 502. Afin de garantir la stabilité du service, nous devons protéger le processus Django. Lorsqu'un problème inconnu survient et provoque une sortie anormale, le processus requis doit être automatiquement activé.

L'utilisation du superviseur comme outil de surveillance peut assurer la survie stable du processus Django. Il est important de faire attention à éviter la vulnérabilité d’exécution de commande à distance Supervisord pour éviter des accidents plus graves.

PARTIE 3. Service en arrière-plan

De manière générale, si vous souhaitez démarrer un service en arrière-plan, le céleri est un choix universel, mais souvent, nous ne voulons pas introduire une dépendance aussi lourde, nous devons donc trouver un moyen de démarrer le service d'arrière-plan nous-mêmes.

Une méthode simple consiste à exécuter la commande manage.py, à démarrer notre service en arrière-plan via ./manage.py runcommand et à contrôler le démarrage et l'arrêt du service en écrivant un script shell, ou à le gérer via le superviseur.

Si vous souhaitez que le processus en arrière-plan démarre et s'arrête en même temps que le service Web, alors le mettre dans wsgi.py est un bon choix. Initialisez le service d'arrière-plan concerné dans wsgi.py et démarrez. il. Cependant, cette approche n'est pas assez flexible. Lorsque le service Web ou le service d'arrière-plan doivent être mis à jour séparément, les deux doivent être redémarrés. Cependant, en utilisant la première méthode, l'un des services peut être mis à jour séparément.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!