flask login

文件总览

如下图所示，Flask-login的工作目录主要是login_manager、mixins、signals、sutils，其中login_manager是主要处理功能，mixins创建了两种用户模型（登录用户和匿名用户）并定义了各自相应的属性，signals主要是基于订阅者模式开发的一种扩展，用户可以充分的扩展其原本的功能，实现系统和业务的解耦，sutils则提供了一套公共处理函数。

login_manager

init_app

首先来看将app注册到login_manager.init_app之后添加了什么功能：

app.login_manager = self
app.after_request(self._update_remember_cookie)
self._login_disabled =  app.config.get('LOGIN_DISABLED', False)
if add_context_processor:
    app.context_processor(_user_context_processor)

+ login_manager本身附加在了app中
* 给after_request添加了一个处理函数，如果用户使用了remember功能，第一次登录会生成cookie[rember_me]（与正常的cookie[session]有何区别：将采用rember_me的配置，）
* 将current_user添加到模板环境中

可知，cookie中保存了整个session（看val的取值），当没有用户没有登录时刷新登录页面，我们来看看其中的session的值：

当用户登录后，在来看其中的session的值：

其中多余的字段全是Flask_Login添加上去的

其实除了这个cookie[session]，Flask_login在用户使用remember_me功能的时候还会产生另一个cookie[remember_token]，下面用一张图片表示整个Flask_login的两个cookie产生的流程：

读懂这张图片需要事前了解Flask一次request请求的内部流程，之前博客Flask流程中专门讲了这一块的内容，针对这张图片需要说明的是：
* 当用户勾选rember_me功能并进行登录操作时，第三步和第四步会产生两个cookie发给浏览器。
* 当用户的session过期，服务器会丢弃当前session并从cookie[remember_token]中恢复一个不新鲜的session。

下图可以看到两个cookie的具体产生：

可以看到，cookie[remember_token]只保存了session的user_id，而cookie[session]把整个session都保存就去了，

新鲜问题

当用户的cookie[session]销毁并通过cookie[rember_me]中登录时该用户会被标记为不新鲜，这有什么用呢？login_required并不会管用户是否新鲜，但是你自己在涉及敏感信息的URL之前再加上@fresh_login_required来进一步提高登录的要求，并且通过@needs_fresh_hander可以自定义不新鲜之后的操作。

会话保护问题

用户的cookie虽然通过一系列的加密，但是当别人通过监听报文获取到cookie的密文，那么就可以通过原封不动的发送这个cookie密文从而登录上别人的账号，为了防止这种事情，你可以启用一个会话保护的功能，它会它生成一个用户电脑的标识（基本上是 IP 地址和 User Agent 的 MD5 hash 值），保存在session中的_id之中，每次在检查_load_user的时候都要对比这个值是否相等来判断这个session是不是被别人偷了。

再次总结Flask_Login的流程

图中需要注意的点有：
* 我们可以设置如果我们设置了session.permanent = true，并且配置了PERMANENT_SESSION_LIFETIME选项，在save_session中cookie的expires会有设置，过期的话浏览器根本不会发过来，如果没有设置permanent参数，默认是false，这样浏览器会一直不断的发送session，但是入栈提取cookie中的session的时候，open_session会验证PERMANENT_SESSION_LIFETIME时间戳，过期依旧会丢弃这个session。

• 安全会话功能，采用login_user()方式登录生成的cookie[‘session’]通过验证没有问题，但是一旦cookie过期，session是默认的生成的，if 判断为空，所以可以绕过安全会话，此时cookie[‘remember_token’]会恢复session，在下一次请求的时候，恢复的session由于丢失了_id关键字，如果设置保护强度为strong那么会导致安全会话pop掉session而变成匿名用户？这其中岂不是有很大的问题， 换句话说cookie[‘remember_token’]一定可以绕过安全会话，而保护强度为strong则恢复的session毫无用处。cookie为何不将_id保存在remember_token中并去掉判断为空这一条件，毕竟这个判断是为匿名用户准备的，并没有什么卵用。

• 如果使用了Flask_Wtf，并且把WTF_CSRF_TIME_LIMIT的时间设置的比PERMANENT_SESSION_LIFETIME的时间还要长（csrf_token有效期比session有效期还要长），那就会出现一个很有意思的事情，当cookie已经过期了，而csrf_token还没有过期的时候，由于session会默认生成一个，默认生成的session中并没有csrf_token，但验证csrf_token会去验证session中的csrf_token与网页携带的是否相等，这一下就会跳到csrf验证失败的处理页面，包括由remember_me恢复的session中也没有这个token，会出现同样的问题(其中csrf_token的验证发生在Preprocess_request，新的csrf_token的产生在context_processor产生，即dispatch_request渲染模板的时候)。所以Flask_Wtf的csrf_token是依附在session中，其有效期的设置最好比session的有效期要小。