难点理解&面试题问答
1.蓝图
以包的形式去创建蓝图的时候更加的灵活,我们需要创建一个包,然后发现文件夹下自动的多出了一个__init__文件,这个文件是用来进行初始化的,在导入的时候会自动将这个文件执行一遍,会初始化变量或者对象.如果是将包比做一个类的话,那么这个文件就相当于它的初始化方法.(我们在这个文件中创建蓝图对象)
视图函数在未来使用的时候可能会有很多,因此我们在创建的包中,单独创建一个管理视图函数的文件,将所有的视图函数写到这个文件中,这样的话,方便维护管理.(在这个文件用蓝图装饰视图函数)
我们单独建一个文件(这个文件需要有app对象),将蓝图注册到app中.
最后为了将视图函数添加到app的url_map中,我们需要在__init__文件中导入一下视图函数的文件.
要想访问一个视图函数,只有视图函数和路由被映射到app身上的时候(添加到url_map),才可以访问视图函数
url_map返回的是app装饰的所有的路由和路径之间的映射关系
2.CSRFToken
csrf_token校验实现的操作步骤:
1.后端生成csrf_token的值,在前端请求登录或者注册界面的时候,将值传给前端,传给前端的方式:
1.1在form表单中添加隐藏字段<input type="hidden" name="csrf_token" value="{{ csrf_token() }}">
1.2将csrf_token使用cookie的方式传给前端response.set_cookie("csrf_token", csrf_token)
2.在前端发起请求的时候,在表单或者请求头中带上指定的csrf_token
$.ajax({
url:"/passport/register",
type: "post",
headers: {
"X-CSRFToken": getCookie("csrf_token")
}
3.后端在接收到请求之后,就将前端发过来的csrf_token和第一步生成的csrf_token进行校验,如果是一致的,那么校验通过,代表是正常的请求,否则可能是伪造的请求,不予通过
3.获取用户对评论的赞
1.先找到用户点赞过的评论编号,也就是用户对哪些评论都点过赞,我们将对应的评论编号找到.如果写成查询语句的话,我们需要分两步进行:
1.1先查询点赞评论表里面的用户id和当前登录用户的id一致的结果.返回的是一个一个的对象列表(评论的id和用户的id)
1.2我们先设定一个空的列表,用来接收用户点赞过的所有的评论编号,然后我们遍历这个对象列表,根据这个对象取出评论id,然后逐个添加到我们新建的列表中即可.
2.然后根据前端传过来的评论的编号,看是否在上面的评论编号里.
3.面试问题集锦
3.1说出request里面几个常用的属性
a)查询参数 args：url地址上最后面传给服务器的参数
b)请求数据data：就是客户端发送给服务器的原始数据（raw原始数据）
c)上传的文件 files：前端上传给后台发送的文件是什么
d)表单 form： 就是表单数据
e)Cookie：浏览器状态保持的一种
联想回答：
request是什么?request是请求的意思，请求方式常用的有get和post，get请求，get请求向后台取，post向后台传,post安全，请求信息不像get请求那样暴露在url地址上，比较安全，http协议默认post请求是安全的，所以需要csrf验证（讲到这可以说什么是csrf验证，如何解决，解决的原理是什么），同时request也是flask请求上下文的一种，什么是上下文？就是一个保存了前端和后台连接状态的容器，他里面存放了什么呢，回归正题，就是上面的几个属性（绕一圈子，再回来，第一面试官觉得你能侃，能聊，知识面不错，印象加分）
3.2说出HTTP状态保持的原理
a)在用户登录之后，服务器返回响应的时候会在响应中添加上cookie
b)浏览器接收到cookie之后会自动保存
c)当用户再次请求其他网页的时候，浏览器会自动带上之前保存的cookie
d)服务器接收到请求之后可以到 request 对象中取到cookie 判断当前用户是否登录
联想回答：
HTTP是无状态的，就是连接时数据互通，关闭后就是永别，永久性失忆，为啥是无状态的呢?因为浏览器和服务器之间用的是socket通信的啊，一旦关闭浏览器，四次挥手之后就销毁所有交互信息（谈谈tcp三次握手，四次挥手）那么让浏览器跟服务器之间保持状态的方法是什么呢，cookie和session区别：cookie保 存在浏览器，每次访问网站都会将本地保存cookies值（用户个人信息）发送到网站，不安全，每个域名下的cookie独立存在，互不干扰。seesion依赖cookie存在，但它保存在服务器上，比cookie更安全，细节：session存的数字不会转成字符串，而cookie存值会转为字符串
3.3说出CSRF 攻击的原理和防范措施
a)攻击原理：
i.用户C访问正常网站A时进行登录，浏览器保存A的cookie
ii.用户C再访问攻击网站B，网站B上有某个隐藏的链接或者图片标签会自动请求网站A的URL地址,例如表单提交，传指定的参数
iii.而攻击网站B在访问网站A的时候，浏览器会自动带上网站A的cookie
iv.所以网站A在接收到请求之后可判断当前用户是登录状态，所以根据用户的权限做具体的操作逻辑，造成网站攻击成功
b)防范措施：
i.在指定表单或者请求头的里面添加一个随机值做为参数
ii.在响应的cookie里面也设置该随机值
iii.那么用户C在正常提交表单的时候会默认带上表单中的随机值，浏览器会自动带上cookie里面的随机值，那么服务器下次接受到请求之后就可以取出两个值进行校验
iv.而对于网站B来说网站B在提交表单的时候不知道该随机值是什么，所以就形成不了攻击
联想回答:
什么是csrf攻击？简单来说就是: 你访问了信任网站A,然后A会用保存你的个人信息并返回给你的浏览器一个cookie，然后呢，在cookie的过期时间之内，你去访问了恶意网站B，它给你返回一些恶意请求代码，要求你去访问网站A，而你的浏览器在收到这个恶意请求之后，在你不知情的情况下，会带上保存在本地浏览器的cookie信息去访问网站A，然后网站A误以为是用户本身的操作，导致来自恶意网站C的攻击代码会被执：发邮件，发消息，修改你的密码，购物，转账，偷窥你的个人信息，导致私人信息泄漏和账户财产安全收到威胁
如何解决？在psot请求时，form表单或ajax里添加csrf_token（实际项目代码里就是如此简单）
解决原理：添加csrf_token值后，web框架会在响应中自动帮我们生成cookie信息，返回给浏览器，同时在前端代码会生成一个csrf_token值，然后当你post提交信息时，web框架会自动比对cookie里和前端form表单或ajax提交上来的csrf_token值，两者一致，说明是当前浏览器发起的正常请求并处理业务逻辑返回响应，那么第三方网站拿到你的cookie值为什么不能验证通过呢?因为他没你前端的那个随机生成的token值啊，他总不能跑到你电脑面前查看你的浏览器前端页面自动随机生成的token值吧
注意：你打开浏览器访问某个url（页面），默认是get请求，也就是说，你只要访问了url，对应的视图函数里只要不是if xx == post的逻辑就会执行，所以你打开页面，他会先生成cookie（token）值，返回给浏览器， 然后你提交表单，或者发ajax请求时，会将浏览器的cookie信息（token值）发送给服务器进行token比对，这个过程相对于你发起了两次请求，第一次是get，第二次才是post，搞清楚这个，你才能明白csrf怎么比对的
3.4说出Flask-SQLAlchemy中 ORM 一对多的模型关系定义步骤
a)首先定义两个模型，比如Role和User，Role与User的对应关系是一对多
b)在多的一方添加一的一方的id作为外键，形成关联关系
c)如果想要通过一的一方访问多的一方，那么在Role中定义属性users = db.relationship(多的一方模型名)
d)如果想要通过多的一方访问一的一方，那么在上一步中添加backre
e)简单的说就是一方添加关系属性,多方添加外键
联想回答：
实际项目里，一对多的事物关系特别多，比如一个作者可以有多本书，那本书只能是一个作者，那么这个人和书就是一对多的关系，其实搞什么一对多，多对多模型，本质就是减少数据库表的创建，方便数据查询，设置外键建立关系后，你人可以访问书的所有属性，书也能取到人这个表（对象）里所有的属性，根据不同的业务逻辑去数据库里拿到数据，返回给前端，浏览器渲染显示就行了
3.5说出数据库迁移的步骤
a)生成迁移文件夹 python xxx.py db init
b)生成当前版本迁移文件 python xxx.py migrate -m 注释
c)执行迁移 python xxx.py upgrade
联想回答：
数据库迁移听着名字高大上，本质就是同步项目中数据表到数据库，项目没有智能到你这边添加，修改表对象，你数据库那边就立马更新了数据表，需要你手动写sql语句commit提交给数据它才能更新表吧，web框架为了简化操作，封装了一套操作工具叫migrate，终端几个简单的操作命令就能实现数据表同步，简单就三步，生成迁移文件夹，项目中更改表后执行生成迁移文件，执行迁移（Django中只需要2步更简单，生成迁移文件，执行迁移文件就行）
优质文章推荐: