Django知识点

Django处理顺序

  1. wsgi
    socket请求处理

  2. 控制器(django框架本身)
    控制用户输入,url匹配,通过映射列表将一个请求发送到一个合适的视图

  3. views
    向模型和模板发送(或获取)数据

  4. 模型绑定
    数据库存取数据

  5. 模板引擎
    用于将内容与展现分离,描述了数据如何展现(如网页模板)

  6. 模式渲染
    将模板和数据整合,形成最终网页

  7. 控制器(django框架本身)
    返回用户展示

MVC与MTV

MVC即模型-视图-控制器模式,就是为那些需要为同样的数据提供多个视图的应用程序而设计的。它很好地实现了数据层与表示层的分离,特别适用于开发与用户图形界面有关的应用程序。控制器用来处理用户命令以及程序事件;模型维护数据并提供数据访问方法;视图用于数据的显示。

MTV即模型 - 模版 - 视图模式,其标准名称是有争议的。在MVC的解释中,视图描述了展现给用户的数据,是指所看到的数据,而不是如何看见它。在python中视图是指对某一特定URL的回调函数,因为回调函数描述了所要展现的数据。模版用于将内容与展现分离。在Django中,视图描述了要展现的数据,而视图一般转交给模版。模版描述了数据如何展现。控制器则是指django框架本身,通过URL配置,系统将一个请求发送到一个合适的视图。

uwsgi与nginx

nginx 接收到浏览器发送过来的http请求,将包进行解析,分析url:

如果是静态文件请求就直接访问用户给nginx配置的静态文件目录,直接返回用户请求的静态文件;

如果不是静态文件,而是一个动态的请求,那么nginx就将请求转发给uwsgi,uwsgi接收到请求之后将包进行处理,处理成wsgi可以接受的格式,并发给wsgi,wsgi根据请求调用应用程序的某个文件,某个文件的某个函数,最后处理完将返回值再次交给wsgi,wsgi将返回值进行打包,打包成uwsgi能够接收的格式,uwsgi接收wsgi 发送的请求,并转发给nginx,nginx最终将返回值返回给浏览器。

第一级的nginx并不是必须的,uwsgi完全可以完成整个的和浏览器交互的流程,但是要考虑到某些情况:

  1. 安全问题,程序不能直接被浏览器访问到,而是通过nginx,nginx只开放某个接口,uwsgi本身是内网接口,这样运维人员在nginx上加上安全性的限制,可以达到保护程序的作用。
  2. 负载均衡问题,一个uwsgi很可能不够用,即使开了多个work也是不行,毕竟一台机器的cpu和内存都是有限的,有了nginx做代理,一个nginx可以代理多台uwsgi完成uwsgi的负载均衡。
  3. 静态文件问题,用django或是uwsgi这种东西来负责静态文件的处理是很浪费的行为,而且他们本身对文件的处理也不如nginx好,所以整个静态文件的处理都直接由nginx完成,静态文件的访问完全不去经过uwsgi以及其后面的东西。

Django中间件

自己理解是类似于Scrapy中间件,在请求和响应的过程中做一些另外的操作,比如拦截、识别、代理等功能操作。

Django的CSRF防护

CSRF, Cross Site Request Forgery, 跨站点伪造请求。举例来讲,某个恶意的网站上有一个指向你的网站的链接,如果某个用户已经登录到你的网站上了,那么当这个用户点击这个恶意网站上的那个链接时,就会向你的网站发来一个请求,你的网站会以为这个请求是用户自己发来的,其实呢,这个请求是那个恶意网站伪造的。

Django 提供的 CSRF 防护机制

Django 第一次响应来自某个客户端的请求时,会在服务器端随机生成一个 token,把这个 token 放在 cookie 里。然后每次 POST 请求都会带上这个 token,这样就能避免被 CSRF 攻击。

Django的CSS防护

  1. 对单一变量进行转义过滤。可以使用escape过滤器,无需转义时使用safe过滤器
  2. 利用django的HTML自动转义,无需autoescape标签,django中的HTML文档会自动转义。
一分一毛也是心意