Shulou(Shulou.com)05/31 Report--

Most people do not understand the knowledge of this article "how to deploy Django", so the editor summarizes the following content, detailed content, clear steps, and has a certain reference value. I hope you can gain something after reading this article. Let's take a look at this "how to deploy Django" article.

PART 1. The best time to fix vulnerabilities first is when you develop them. 1.1 CSRF TOKEN

CSRF TOKEN is a very important security measure in Django security system. But in many cases, some students who have just come into contact with Django will find that the form they finally wrote was wrong in POST. After some search, they found that it was CSRF TOKEN's problem, and then according to the online method, all the CSRF TOKEN configuration in settings.py was removed, and the code ran normally. I do not know that this operation will greatly affect the security of the website, and increase the cost of repairing vulnerabilities in the later stage, while eliminating security problems in the development stage is the lowest time.

With regard to the relevant content of CSRF TOKEN, there is a very detailed description in the official documentation, and the specific usage will not be discussed here. A more convenient usage is recommended here, which is less aware of the developers at the time of development, and there is no need to pay special attention to whether the Token has been sent successfully.

Add {% csrf_token%} to the overall parent template page and make the following settings in the section:

In this way, all non-GET | HEAD | OPTIONS | TRACE requests initiated through AJAX in JQuery will automatically contain CSRF TOKEN (some of the codes for obtaining CSRF TOKEN are not listed). If you are using other HTTP libraries or Fetch, you can set them accordingly.

1.2 API Security Design

In some cases, our Web service will also provide some API services for other system calls. For these API interfaces, CSRF must be turned off, otherwise it will not work at all. In addition, we should also take some other security measures to prevent API interface from being abused. In addition to the normal passing parameters, we should ensure that these parameters are not tampered with by the middleman, and only those who have permission are allowed to call the corresponding interfaces. For this reason, we need to introduce several additional passed parameters: timestamp, sign, access_key, access_token.

Access_key and access_token, which are a pair of parameters. Access_key is the equivalent of identifying who the caller is, and access_token is the secret key of the caller. Access_token content should not be simply predicted, while access_key can choose simpler strings for easy memory. It is only when the two parameters match that the call to API is considered legal.

Timestamp timestamp, which can be accurate to seconds or milliseconds according to your business situation. The timestamp is added mainly to prevent the replay attack of this call. The server should verify whether the timestamp passed by the client is within a time range, and the timeout timestamp should be considered an illegal request. However, the timestamp still has the risk of being tampered with when it is replayed, so the next parameter sign needs to be introduced to ensure the authenticity of the parameters.

Sign is the signature value of all parameters, which is generated by all parameter values participating in hash calculation. Sign needs to be regenerated every time the parameter changes, so as to ensure the authenticity of the parameters. A commonly used algorithm is to sort the parameter key according to the alphabetical order of the parameter value, and connect all the parameters with a specific separator, then calculate the hash and pass the sign parameters to the server. For example, the existing parameter ak=2222&at=1111&timestamp=3333&key1=aaa, sorted in alphabetical order, is 22221111aaa3333, and after adding the delimiter (|), it is 2222 (|) 1111 (|) aaa (|) 3333, and then the string is calculated as sha1 to generate a sign value. Writing in Python code is relatively simple:

1.3 some miscellaneous

In addition to the above two more important points, there are some areas that need extra attention.

Turn off DEBUG mode in a production environment

Do not add settings.py to version management and protect SECRET_KEY

Set up ALLOWED_HOSTS

Use the ORM provided by Django as much as possible to avoid executing SQL statements directly through .raw () and other methods. If it is unavoidable, you must escape the parameters correctly to avoid SQL injection vulnerabilities.

Disable Django Admin as much as possible. If necessary, please modify the default Admin URL.

PART 2. How to deploy pull-down code from git, install project dependencies using pip, and run services through manage.py all look great, but are you really going to do this in a production environment? 2.1 isolated environment

In general, there is only one Python environment on our server, and when deploying, we usually install the dependencies needed by the project through pip, and these packages are installed in the global site-packages directory.

But when we deploy multiple projects, this way of installing dependencies is prone to dependency conflicts. To take a simple example, we now have two projects: Project-An and Project-B. Both An and B rely on different versions of the third-party package third-A. When we go through pip install-r requirements-a.txt, the dependent third-An is installed into the global Python environment. When we install pip install-r requirements-b.txt again, we will also install third-An again. At this time, if the two projects depend on different versions For example, if project A needs version 1.0 and project B requires version 2.0, there will be dependency conflicts, which will cause the installation of dependencies to fail.

So how to solve this problem? It is easy to think that if we have multiple isolated environments, each project deployed in a separate environment, then the problem will be easily solved. Virtualenv was born to solve this problem by creating a separate runtime environment for each project to avoid dependency conflicts.

2.2 version Management

Previously we knew how to create an isolated environment and deploy different projects in different environments, but there is a problem here, all environments use the same version of Python. If you happen to need to deploy several different versions of Python projects, such as Python2.7 (I know this version is about to be dismaintained, but I'll give an example here), Python3.6 and Jython projects, one installation seems a bit complicated, and even when compiling and installing, accidentally missing a compilation parameter and recompiling, all increase the deployment effort to some extent.

We can use pyenv to manage the problem of multiple Python versions, and further through the plug-in pyenv-virtualenv of pyenv to manage the problem of multi-Python version and multi-virtual environment.

2.3 Gateway Interface

When we've solved the problems of various environments, it's time to think about how to get the project up and running, and if you're thinking about python manage.py runserver 0.0.0.0 80, it's a little too easy.

A simple WSGI implementation has been built into Django for us to start Web services in the above way, and if you just want to debug or provide services to Mini Program for a few people, that's an option, although it doesn't look so elegant.

If you really want to deploy the application to a real production environment, you also need a high-performance WSGI Server, not the simple WSGI Server provided by django. Gunicorn and uWSGI are both mainstream WSGI Server, so just choose one of them according to the actual deployment environment.

However, I personally prefer Gunicorn, although uWSGI has the upper hand in many performance tests, the reason for choosing Gunicorn is that it is very simple compared with uWSGI, there are no very complex functions rarely used, and some functions in uWSGI have been gradually supported by Nginx, and Gunicorn configuration is also relatively simple and convenient. By the way, if you deploy on Windows, you may need to use Apache+mod_wsgi.

2.4 reverse proxy

When our WSGI Server is ready to start, we need to consider the problem of reverse proxy. There are several reasons why we block another layer of Nginx to reverse proxy:

Nginx is required to handle static resources. If you set the DEBUG mode of Django to False, you will find that many static resources such as CSS and JS cannot be loaded. This is because Django does not take the initiative to process these requests, which requires the help of Nginx.

Load balancing of multiple backend through Nginx. If your service is deployed on multiple servers, or if you deploy one master and one backup, you can do this by simply setting up your service on Nginx

There are some security risks in exposing uWSGI or Gunicorn directly, and it is more convenient to use Nginx to deal with HTTP problems.

In addition, there are some reasons not listed here, or the above sentence, if your service is very simple, only a few people visit, there is no need to make such a complex setting.

2.5 process daemon

So far, our service has been successfully deployed and can begin to provide normal services. But we think a little less, if our Django unfortunately exits for some unknown reason, then our Web service will become 502. In order to ensure the stability of the service, we need to guard the Django process, and when it exits abnormally due to unknown problems, we need to automatically pull up the required process.

We can use supervisor to guard the Django process to ensure its stable survival. One thing to note, however, is to be careful not to have a vulnerability in Supervisord's remote command execution, which can lead to a bigger accident.

PART 3. back-up services

Generally speaking, celery is a versatile choice if you want to start the background service, but very often we don't want to introduce such heavy dependency, so we need to find a way to start the background service ourselves.

A simple way is to make the command of manage.py, start our background service through. / manage.py runcommand, and control the start and stop of the service by writing shell scripts, or manage it through supervisor.

If you want the background process to start and stop at the same time as the Web service, it is a good choice to put it in wsgi.py. Initialize the relevant background service in wsgi.py and start it. However, this approach is not flexible enough, when you need to update the Web service or background service separately, you need to restart both, and in the first case, you can update one of the services separately.

The above is the content of this article on "how to deploy Django". I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.