python web框架django面试题

#1.Django是走大而全的方向，它最出名的是其全自动化的管理后台：只需要使用起ORM，做简单的对象定义，它就能自动生成数据库结构、以及全功能的管理后台。
#2.Django内置的ORM跟框架内的其他模块耦合程度高。
#应用程序必须使用Django内置的ORM，否则就不能享受到框架内提供的种种基于其ORM的便利；
#理论上可以切换掉其ORM模块，但这就相当于要把装修完毕的房子拆除重新装修，倒不如一开始就去毛胚房做全新的装修。
#3.Django的卖点是超高的开发效率，其性能扩展有限；采用Django的项目，在流量达到一定规模后，都需要对其进行重构，才能满足性能的要求。
#4.Django适用的是中小型的网站，或者是作为大型网站快速实现产品雏形的工具。
#5.Django模板的设计哲学是彻底的将代码、样式分离； Django从根本上杜绝在模板中进行编码、处理数据的可能。

#1.Django走的是大而全的方向,开发效率高。它的MTV框架,自带的ORM,admin后台管理,自带的sqlite数据库和开发测试用的服务器
#给开发者提高了超高的开发效率
#2.Flask是轻量级的框架,自由,灵活,可扩展性很强,核心基于Werkzeug WSGI工具和jinja2模板引擎
#3.Tornado走的是少而精的方向,性能优越。它最出名的是异步非阻塞的设计方式
#Tornado的两大核心模块：
# 1.iostraem：对非阻塞式的socket进行简单的封装
# 2.ioloop：对I/O多路复用的封装，它实现了一个单例

#WSGI:
# web服务器网关接口,是一套协议。用于接收用户请求并将请求进行初次封装，然后将请求交给web框架
# 实现wsgi协议的模块：
# 1.wsgiref,本质上就是编写一个socket服务端，用于接收用户请求(django)
# 2.werkzeug,本质上就是编写一个socket服务端，用于接收用户请求(flask)
#uwsgi:
# 与WSGI一样是一种通信协议，它是uWSGI服务器的独占协议,用于定义传输信息的类型
#uWSGI:
# 是一个web服务器,实现了WSGI协议,uWSGI协议,http协议,

#1.wsgi,请求封装后交给web框架 （Flask、Django） 
#2.中间件，对请求进行校验或在请求对象中添加其他相关数据，例如：csrf、request.session - 
#3.路由匹配 根据浏览器发送的不同url去匹配不同的视图函数 
#4.视图函数，在视图函数中进行业务逻辑的处理，可能涉及到：orm、templates => 渲染 - 
#5.中间件，对响应的数据进行处理。 
#6.wsgi,将响应的内容发送给浏览器。

#FBV和CBV本质是一样的
#基于函数的视图叫做FBV，基于类的视图叫做CBV
#在python中使用CBV的优点：
#1.提高了代码的复用性，可以使用面向对象的技术，比如Mixin（多继承）
#2.可以用不同的函数针对不同的HTTP方法处理，而不是通过很多if判断，提高代码可读性

#引入method_decorator模块
#1.直接在类上加装饰器
#@method_decorator(test,name='dispatch')
#class Loginview(View):
# pass
#2.直接在处理的函数前加装饰器
#@method_decorator(test)
# def post(self,request,*args,**kwargs):pass

#MVC软件系统分为三个基本部分：模型(Model)、视图(View)和控制器(Controller)
#Model：负责业务对象与数据库的映射(ORM)
#View：负责与用户的交互
#Control：接受用户的输入调用模型和视图完成用户的请求
#Django框架的MTV设计模式借鉴了MVC框架的思想,三部分为：Model、Template和View
#Model(模型)：负责业务对象与数据库的对象(ORM)
#Template(模版)：负责如何把页面展示给用户
#View(视图)：负责业务逻辑，并在适当的时候调用Model和Template
#此外,Django还有一个urls分发器,
#它将一个个URL的页面请求分发给不同的view处理,view再调用相应的Model和Template

#用于反向解析路由,相当于给url取个别名，只要这个名字不变,即使对应的url改变
#通过该名字也能找到该条url

#1.Admin是对model中对应的数据表进行增删改查提供的组件
#2.model组件：负责操作数据库
#3.form组件：1.生成HTML代码2.数据有效性校验3校验信息返回并展示
#4.ModelForm组件即用于数据库操作,也可用于用户请求的验证

#中间件是介于request与response处理之间的一道处理过程,用于在全局范围内改变Django的输入和输出。
#简单的来说中间件是帮助我们在视图函数执行之前和执行之后都可以做一些额外的操作
#例如：
#1.Django项目中默认启用了csrf保护,每次请求时通过CSRF中间件检查请求中是否有正确#token值
#2.当用户在页面上发送请求时，通过自定义的认证中间件，判断用户是否已经登陆，未登陆就去登陆。
#3.当有用户请求过来时，判断用户是否在白名单或者在黑名单里

#1.process_request : 请求进来时,权限认证
#2.process_view : 路由匹配之后,能够得到视图函数
#3.process_exception : 异常时执行
#4.process_template_responseprocess : 模板渲染时执行
#5.process_response : 请求有响应时执行

#class WSGIHandler(base.BaseHandler):
# request = self.request_class(environ)
#请求走到WSGIHandler类的时候，执行__cell__方法，将environ封装成了request

#1.使用HttpResponseRedirect
#from django.http import HttpResponseRedirect 
#2.使用redirect和reverse
#状态码：301和302
#301和302的区别：
#相同点：都表示重定向，浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址
#不同点：
#301比较常用的场景是使用域名跳转。比如，我们访问 http://www.baidu.com 会跳转到 https://www.baidu.com
#表示旧地址A的资源已经被永久地移除了
#302用来做临时跳转，比如未登陆的用户访问用户中心重定向到登录页面。表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B

#-- XSS攻击是向网页中注入恶意脚本，用在用户浏览网页时，在用户浏览器中执行恶意脚本的攻击。
# -- XSS分类，反射型xss ，存储型xss
# -- 反射型xss又称为非持久型xss，攻击者通过电子邮件等方式将包含注入脚本的链接发送给受害者，
# 受害者通过点击链接，执行注入脚本，达到攻击目的。
# -- 持久型xss跟反射型的最大不同是攻击脚本将被永久的存放在目标服务器的数据库和文件中，多见于论坛
# 攻击脚本连同正常信息一同注入到帖子内容当中，当浏览这个被注入恶意脚本的帖子的时候，恶意脚本会被执行
# -- 防范措施 1 输入过滤 2 输出编码 3 cookie防盗
# 1，输入过滤 用户输入进行检测 不允许带有js代码
# 2，输出编码 就是把我们的脚本代码变成字符串形式输出出来
# 3，cookie加密
 
 
 
#向页面注入恶意的代码,这些代码被浏览器执行
#XSS攻击能做些什么：
# 1.窃取cookies
# 2.读取用户未公开的资料，如果：邮件列表或者内容、系统的客户资料，联系人列表
#解决方法:
# 1.客户度端：表单提交之前或者url传递之前,对需要的参数进行过滤
# 2.服务器端：检查用户输入的内容是否有非法内容

#第一步：django第一次响应来自某个客户端的请求时,后端随机产生一个token值，把这个token保存在SESSION状态中;同时,后端把这个token放到cookie中交给前端页面；
#第二步：下次前端需要发起请求（比如发帖）的时候把这个token值加入到请求数据或者头信息中,一起传给后端；Cookies:{csrftoken:xxxxx}
#第三步：后端校验前端请求带过来的token和SESSION里的token是否一致；

#1.后端将csrftoken传到前端，发送post请求时携带这个值发送
data: {
 csrfmiddlewaretoken: '{{ csrf_token }}'
 },
#2.获取form中隐藏标签的csrftoken值，加入到请求数据中传给后端
 data: {
 csrfmiddlewaretoken:$('[name="csrfmiddlewaretoken"]').val()
 },
#3.cookie中存在csrftoken,将csrftoken值放到请求头中
headers:{ "X-CSRFtoken":$.cookie("csrftoken")}，

#1.runserver方法是调试 Django 时经常用到的运行方式，它使用Django自带的
#WSGI Server 运行，主要在测试和开发中使用，并且 runserver 开启的方式也是单进程 。
#2.uWSGI是一个Web服务器，它实现了WSGI协议、uwsgi、http 等协议。注意uwsgi是一种通信协议，而uWSGI是实现uwsgi协议和WSGI协议的 Web 服务器。
#uWSGI具有超快的性能、低内存占用和多app管理等优点，并且搭配着Nginx就是一个生产环境了，能够将用户访问请求与应用 app 隔离开，实现真正的部署 。
#相比来讲，支持的并发量更高，方便管理多进程，发挥多核的优势，提升性能。

#1.cookie:
# cookie是保存在浏览器端的键值对,可以用来做用户认证
#2.session：
# 将用户的会话信息保存在服务端,key值是随机产生的自符串,value值时session的内容
# 依赖于cookie将每个用户的随机字符串保存到用户浏览器上
#Django中session默认保存在数据库中：django_session表
#flask,session默认将加密的数据写在用户的cookie中

#<1> all(): 查询所有结果 
#<2> filter(**kwargs): 它包含了与所给筛选条件相匹配的对象。获取不到返回None
#<3> get(**kwargs): 返回与所给筛选条件相匹配的对象，返回结果有且只有一个。获取不到会抱胸
#如果符合筛选条件的对象超过一个或者没有都会抛出错误。
#<4> exclude(**kwargs): 它包含了与所给筛选条件不匹配的对象
#<5> order_by(*field): 对查询结果排序
#<6> reverse(): 对查询结果反向排序 
#<8> count(): 返回数据库中匹配查询(QuerySet)的对象数量。 
#<9> first(): 返回第一条记录 
#<10> last(): 返回最后一条记录 
#<11> exists(): 如果QuerySet包含数据，就返回True，否则返回False
#<12> values(*field): 返回一个ValueQuerySet——一个特殊的QuerySet，运行后得到的并不是一系 model的实例化对象，而是一个可迭代的字典序列
#<13> values_list(*field): 它与values()非常相似，它返回的是一个元组序列，values返回的是一个字典序列
#<14> distinct(): 从返回结果中剔除重复纪录

#only:从数据库中只取指定字段的内容
#defer：指定字段的内容不被检索