2020/03/05 03-查询表达式、Session-Cookie机制、JWT

模型操作也就是model类提供的操作能力，一般操作数据无非就是增删改查，CRUD，要学会在django中如何操作，提供了一个orm，这个orm提供了操作的东西，叫管理器对象，管理器对象是一个很特别的类，这个类不能直接调用，这个实例是捆绑在控件的model对象上的。
自己创建可以替换，也可以多替换几个

orm的操作就是将增删改查所有的方法操作换成sql语句，这个语句是交给orm来做的，orm更在乎对象和关系，，比如用外键描述关系。比如一对一，多对多。
对象是指面向对象的对象，用类和实例的方式描述大千世界，数据库是用关系模型来描述世界.
类对应表，类属性对应表字段。一行行记录对应一个个实例

操作和sqlalchemy很像，都是懒惰的方式，如果不使用就不查，减轻对数据库的负担，这样就让数据库的更多时间给别人使用。查询完会缓存，缓存在数据集里。
也可以使用第三方，把有意义的数据存放到里面进行缓存，redis可以设定缓存多长时间，或者到什么时候清除


切片也很懒惰，不用也不查，切片跟limit和offset语句是对应起来的，但是之间有个计算关系

过滤器，就是all，filter，一般很少用all，查询 了objects.filter用的更多，后面再做切片，用filter的时候小于大于成了问题，不能用了，所以提供了新的语法lookup表达式。
使用主键的时候可以使用PK这个值。

提供了一些查询单个值的方式，get只能得到1个对象，没有或者返回多条都会抛出异常。
first，last，exist用的相对较少


字段查询表达式，一般放在get，条件，filter，或者排除，排除相当于filter取反，这里都需要一个条件

一般属性名和字段名一致，省的出现问题，一般字段名不用下划线什么，不推荐拼音缩写，除非是国标（有些国家标准字段只能是拼音首字母），否则不要这么做

严格等于，转换出来就是哪个字段等于什么

字符串谁包含了谁，相当于like ‘%xx%’，字段__contains=

左前缀匹配，后缀匹配

是不是为null，

i是ignore忽略大小写匹配

in什么就写一个列表，告诉他必须是这么个东西

大于等于gt，gte，小于等于lt，lte
可以将日期类型的提取出一部分来比较，帮你把年份提取出来做相应处理

在and条件下，现在‘’或‘’没办法写

把id=1或者id=2的拿到
这里不认or，就只能借助q对象了，and or都用q对象来解决你放入的参数，并列，and，or，取反

Q对象在models下

user也在models下

试试这种方式行不行

好像没有达到想要的目的

这里的or并不是给数据库真正用的，有前面可以先短路了，这是python直接取or了，该短路短路了

引入了|号，在sqlalchemy可以直接拿来用


这样就ok了，这里的or是python的逻辑表达式，不是django 的orm的表示式，要使用就用运算符重载|

&代表and


这样就成功了

这样其实比filter好，借助Q对象，和& 和|符号，结合起来写非常复杂的逻辑表达式，这样会更好点

~代表not

一个表达式可以不要Q对象

写这样试试


就出问题了

写成这样



取反

可以使用&|和Q对象来构造复杂的逻辑表达式，可以用在filter，get，
过滤器可以使用一个或多个Q对象，过滤器函数就是filter，get
如果混用关键字参数和Q对象，那么Q对象必须位于关键字参数的前面。所有参数都将and在一起，一般不要混写，直接上去先写Q对象。
简单的用lookup表达式，复杂的用Q对象&and|或者~取反

注册接口设计完善

http协议是无状态的（同样客户端连接两次服务器，服务器依然以为是两个人，无法区分），为了让服务器知道你是同一个，cookie会在浏览器发起请求的时候request header里带有cookie，这个cookie内部又写了个值，谁等于谁
、
cookie定义了好几个键值对，谁等于谁；冒号 谁等于谁，等于字典套字典
这个值是来自于setcookie,服务器要给浏览器端发，第一次请求来的时候，服务器跟你商量放一个cookie值，在你请求响应的时候把cookie带过来

服务器在response header头里放了set-cookie，这个cookie值可以不止一个值

把这些cookie都注入到了浏览器端，当浏览器再对这个域名发起请求的时候，如果cookie还没过期，浏览器就不清理，cookie还可以使用，当你对这个域名再次发起请求的时候，就会把这个cookie带上

就会把这个cookie，塞到请求报文的cookie部分

有一个特殊的cookie叫sessionid，这个cookie比较特殊，指的是跟服务器建立连接后，往往动态服务器会专门给这次会话生成一个session对象，这个session里如何区分session对象，就靠这个id，每一个建立的会话都要分配一个session，这个session都有一个唯一的id，这个id就是sessionid，当你第一次与服务器建立连接后，服务器就会response，除了给你set-cookie，还会塞入sessionid。
将sessionid发给你，这个sessionid是解决动态服务器之间交互的，不允许客户端随意进行修改，这个sessionid也是cookie，当我们的客户端发起请求的时候，就会将这个cookie里的sessionid和其他set-cookie里的发过来的cookie一并带入请求头的cookie部分，然后将这些值全部发给服务器，服务器就可以获得这个cookie。

在观察request对象的时候，内部看到几个值，get，post，cookie，和meta，get是用来放查询字符串的，post是把表单传回去，body传的数据都在body里，cookie里就是拿到的cookie值，在请求头中发送的cookie值，这个cookie是用来解决无状态的问题。

实际上仅仅靠cookie还不能知道你是谁，发一个csrftoken是解决安全的问题的，但还不知道你是谁。如何确定你是谁，链接之后，服务器会为每一个链接创建一个session对象，就是会话，也就是浏览器和服务器建立了一个会话链接，注意这个会话链接有可能断开了。
会话是会话，但是有可能tcp链接已经断开了，因为是短连接，会话和链接并不能一一对应，再次请求服务器相当于再搭了一个tcp桥，但是在服务器端有一个session对象，如何知道建立的链接就是上次的人，就要看浏览器的cookie里带不带sessionid，如果带了sessionid，就查一下自己的表，发现sessionid存在，就继续。

当你第一次去访问服务器的时候，服务器就蹦出框来，访问需要登录，登录失败，网站不理你，登录成功就会往你session里加东西，session里塞的东西就可以标识你是谁，这个session实际上是一个数据结构，里面有个属性其实就是id，id唯一，代表这一次和某个浏览器的会话，这个浏览器再次访问过来的时候，服务器就会查sessionid

等于建立一个关系，动态网页技术往往在server端有session管理机制，session管理会为每个浏览器访问的时候，发一个唯一id，称为sessionid，为了下一次能带过来sessionid辨识身份，就使用了cookie，实际上这个sessionid颁发回去的时候，必须在第一次访问完要写有一个set-cookie，这个浏览器收到响应后，在cookie里就有sessionid了。
浏览器过了一会给同一台server发请求，如果cookie没过期就会带上，cookie是跟域名相关的，发往这个服务器，这个服务器会在它的session大表里去找，找这个sessionid在不在，假设sessionid还在，说明 就是上次访问的人，就把无状态的问题解决掉了。
用cookie加上session就可以完成无状态的确认，不用sessionid也可以，自己写个特殊的cookie也可以，但是session本来就是这个机制，没必要自己去实现一套了，当你去访问服务器，服务器会创建会话，给这个会话发一个唯一 sessionid，将sessionid会通过cookie的方式，response给你，下回通过cookie，带上这个sessionid才能确认身份。
session和cookie机制用来解决无状态的

session是和域名相关的，通过域名访问同一个网站的时候就会将这个域名带上，发往服务器端，浏览器会自动清楚过期cookie。

浏览器现在第一次访问网站，浏览之后，会把sessionid带上，还有其他cookie值。但是这个人（浏览器都有清除cookie和历史记录），清除了，再访问网站的时候，server就不认识你了。sessionid没了就没法判断。
server会认为你是新的链接重新发一个sessionid

最传统的验证,当你第一次访问，会发一个sessionid，表示你两会话比不过期就可以一直用，如果你登录成功，在session可以再放一个id，比如login：用户id。当你登录成功发现session是一样的，确认无误刚才登录过，还会查当前session大集合里还有什么属性，还有login=true或者userid，这时候就可以不让你登录了，直接跳到用户操作界面
、
session还有一种机制，过期机制。
sessionid是非常特殊的cookie，不会长久保存，一般浏览器关了就清除掉了，sessionid丢了，对方就不认你了，但是这么操作，服务器端会有很多废掉的 session。session可以理解是个大字典，里面k有放很多的值，是个很大的集合。如果有一百万人这么操作 ，内存耗费是很大的。session有时间过期机制，但是这样就有了攻击方法，大批机器攻击，就有可能内存资源耗尽。
**
其实通过域名 访问是可以访问到很多服务器的，一般时刻，只能访问同一台，就算同一个ip也会引导的不同机器上去的，假定是同一台机器。session默认情况下是和server服务相关，server1启动了一个服务进程，单独维护了内存里的session，server2也是单独维护自己进程里的session。
第一次访问server1，但是后来dns变了，第二次访问server2去了，这时候就会有一种现象，用着用着就让你重新登录
**
dns解析是udp53端口，，解析回来的数据会在本地缓存一段时间，就要看后台的调度了，或者后面session共享存储

session是当你和服务器建立会话的时候，由服务器单独为你生成一次会话，这次会话会单独为你分配一个session，这个session至少有一个键值对，键就是id，值就是sessionid，这个sessionid会发给浏览器端，浏览器只要不清除不过期不关闭浏览器，这个sessionid就会随着下一次请求提交给服务器，服务器通过查表，判断这个人是否联系过。
但是浏览器端可以关闭session，session时效，大多数服务器端session过期也需要10分钟左右，在这个10分钟其实等着你去链接的，过了这个时间，服务器就把sessionid清理掉了，再连接也不认识你。
**
作为程序员来讲，session不是越多越好，对每个客户建立session，对内存消耗很大，session跨节点也很难。s1
和s2各维护着session，客户端1第一次访问s1，但是后来调度到s2了，就导致重新登录。
以前很多购物车的实现都是session实现的，把商品id数量都放在里面，结果你准备付账，把你引导到s2了，购物车就没了这是非常讨厌的 **

还有就是，购物车放满了，出去吃个饭，服务器端session过期了，替你清除了。
我们应该定期的给session数据做一次持久化

session是比较消耗内存，尤其是把购物车放到session里，消耗更大。session是解决了无状态，但是如果把用户相关数据放到session上，会带来非常大问题，1.内存耗尽，2.session丢失 的问题，如果进程崩了，这个session也就没了

所以以前用户登录了，定期给它持久化一次，不登录，没法持久化，只能放在cookie里，现在浏览器一关js和cookie，基本上没有网站可以访问。
session的采取清除是LRU最近最少使用，就清除了

对于动态网页技术来讲 ，更需要session和cookie这样的机制，当浏览器第一次访问网站的时候，通过response会写回去一个sessionid这样的cookie，浏览器会暂存这个cookie，用户在连续对服务器发送请求的时候，每一次请求都会将cookie带回来，cookie里有sessionid就继续带回来，服务器端将通过带回来的sessionid，对sessionid进行检查，如果在自己的session集合中，发现了有sessionid，是这个id，表示确实是上次通讯的。
如果在现在的session集合里没找到sessionid，就给用户重新发一个sessionid，session在服务器端是比较耗费资源的。浏览器有些关闭或者关闭标签页也相当于关闭浏览器，sessionid就清除了

和服务器tcp链接通讯的时候，tcp这个链接有可能断掉，所以不带sessionid根本不知道你是谁

**大网站后面都是集群，为了让用户访问任何服务器都有一样的session，让两台的session保持一致，但是比较浪费，数据充分，好处是可以冗余。
**

还有一种，session放在redis里，以前放memacached比较多，统一管理

开发必须了解session，要看怎么放才是安全的，这是传统的方式用session和cookie解决无状态的问题

看看不用session的方案，session相当于把压力给了服务器端，服务器需要维护一个数据结果，里面把所有sessionid和其他值维护起来。
但是如果让浏览器来管，我们不可信，加一种算法，只要你改数据就发现的了，比如保险的用https，ssl证书加密，安全性就比较高，它是非对称加密，本来就比对称加密难破解。
对称加密，就是rar，zip有时候加个密，1234，别人也用1234解开，这就是对称加密，同一个密钥。
非对称加密，有公钥私钥，公钥.pub，私钥是不带pub，别人用你的公钥加密，你用私钥去解开。非对称是比较难解开的。
单项散列值加密MD5，加了密解不回来了

**这里也需要一种加密算法，不用session了，直接将信息发往服务器端，服务器端带过来就认为可以 了，类似cookie，但是原始的cookie是明文的，而且改了也不知道，所以需要一种防篡改机制，利用这种机制，防止别人篡改，一旦别人修改一个字节或者一个位，这里就能验证出来，从而不相信你。
**
session和cookie用来确认身份，实际上就是用sessionid来让无状态变成有状态。我们可以想办法替换这个sessionid，将这个id有一个id发给客户端，但是一定要确定，发送给客户端的东西不得修改，修改就出问题 了。
我们就要使用某种方法对数据进行签名，但凡修改了一个位，在服务器用密钥重新验算一遍就知道改过了。签名算法必须难破解，密钥足够的强

这就是密钥

也有缺点，就是将数据提交到服务器后，服务器端就需要去解密验证，就有加密和解密的过程，浪费了服务器cpu计算时间。但是解决了session不同步，消耗内存的事情，这种方案非常节约计算机内存资源。
这个是自己玩的，浏览器不认识，就要想办法自己清除它，这就是JWT技术

JWT在做单点登录的身份验证的时候比较多，如果服务器比较多，用JWT是比较好的方案，传统的方式是session的方式，登录完了，在session里加个值，然后可以解决session问题，服务器多起来，就非常复杂了。大的网站，不同频道其实访问的是不同服务器，怎么知道你的session再另外的服务器上有，就做起来很难，这时候就往往需要用到单点登录，在一个上面登录过，在其他服务器上只需要做验证就可以了，比如JWT技术就可以搞定

JWT（json web token）token令牌，你的身份是谁就交出token，用json来传输数据是比较好的方案，要安装一个库，PyJWT

jwt是一个开源的工业标准

把右边的数据编码成左边的样子

它是把数据变成三部分，对应左边三部分，第一部分header密文头

最左边是base64

这里是数据，负载

这个头宣传是jwt，用什么加密方式
这一部分是签名

签名部分

中间部分是数据，负载，要传的数据

几乎所有的语言都支持

安装很简单，安装完了就这么用

写一个测试文件
**基本用法，导入库，虽然库名字叫pyjwt，但是导入还是JWT，
**

jwt做编码，对负载进行编码，使用什么密码，采用什么算法

得到的结果可以打印。用点号分成三段

，每一段对应不同的东西，第一段header，第二段payload，第三段signature签名。
客户端没有办法解密，除非知道密码是什么，浏览器是不能看到这个密码的

这里就是解开了

跑一下

密码错误直接告诉你签名无效，这就叫篡改，篡改一位都不行

这里就等于修改了加密以后的值，告诉头信息错误，因为每一部分都会验证

首先把jwt分成三部分，header，payload负载，signature签名

用base64解开一下

就是header部分，告诉jwt的类型，和算法 HS256

说明这里面每部分都是base64编码的

查看payload这一块

查看singature，就报错，报的错是补丁不对

base64发现缺了最多补两个==等号，或者补一个，或者不补，就这三种情况，最笨的方法就这么写

这两个可能正好有不合适，也需要补等号

*准备写一个函数，bytes要加等号，base64编码完之后，长度一定要凑齐，凑齐了是4的倍数。
首先把长度拿到，和4取模，告诉我们余下的，就返回b’='4-余数，余几个减掉才能补

现在就一点问题都没有

这就是签名，签完之后是二进制的

encode编码过程，这里是负载

看一些怎么给我们处理的

这个负载先进来payload是个字典
key 密码
algorithm算法
header头都是缺省值

将payload给json化了

这样就拿到了一个json payload，拿到key和algorithm算法交给父类的encode，这一步完成了字典到json的转换

然后再进行进一步的转换，这里拿到的是json payload

头部就凑齐了

将这个头校验之后放在这里，现在有了json payload和json 头

用base64编码，将json头也就是字符串，将字符串进程base64编码，将payload，进行json字符串编码，在segments出现了两个元素了。
一个是头base64编码，一个是payloadjson做了base64编码

将前面两个值直接用.点号链接
就是前面两个部分

现在要做签名，你的算法，和payload，都是signing_Input数据

传进来一个算法后，就找到这个算法，用 这个算法将key密码拿到，然后用算法预处理下key

然后通过签名算法，将input数据和key开始签名了

可以理解这句话意思，虽然是签名，其实就是用你提供的key在做加密，加密的时候得到一个签名。
如果这个签名不出错
就是把这个前面依然base64编码了一下，编码之后加到segments的尾部去了

最后输出给你的是，将这三段base64，header,payload,signature签名，用点号链接就返回给你

我们要自己去写该怎么写，现在第一部分值和第二部分值都有，也就是这两个分别要json，用base64编一下即可，编完之后拿到的值就可以签名了

先注释掉

将第一段和第二段截取出来

jwt是将这个拼在一起得到它
导入看看缺省的是什么

从jwt下面，找算法函数】

这是一个kv集合，正好有key，返回字典给我们

这里预处理了key

现在得到一个算法，get_defaul得到一个字典，问字典有没有这个key，有这个key，有就拿到算法了，也得到了newkey

现在用alg.sign签名，签名就是消息，是之前的sign_input，第二个是newkwey，处理过的 key，然后就把signature拿到了

做一下base64，encode

**解密的过程下面就有，解密的过程其实是一个反过来的过程，把值拿进来，断开很多部分 **

这里有一个校验签名的过程，首先要想办法将你提交的数据断开，如果不断开，它也不知道什么header，也不知道什么是payload，虽然算法正确，因为key是在服务器端验证

只要payload和header发生改变，算出来 的签名一定不一样

JWT三部分，修改任何一个，只要重新算一遍，一定不会得到同一个签名

这个payload数据现在是不加密的，所以使用的时候要注意，JWT并没有解决加密的问题，也是将payload是用明文发送的，只不过需要base64转一下，并没有加密，唯一加密的是签名。三部分任何部分进行修改，都验证失败，所以叫防篡改。不是对数据进行加密。

密码很重要需要管理好


jwt原理

base64只是做了一个编码，直接拿编码解开，其实就发现这个东西就是明文传输的，所以它是防篡改的，大多数数据签名都是来做防篡改的，签名这种技术一般是防篡改，不允许你修改，但凡你修改了就丢弃，这个不可信。
验算算法就是再算一遍看看是否一致，不一致就是验算失败

不要把敏感数据放到jwt，jwt是明文传输

jwt最常使用场景就是单点登录的问题，一旦用户成功就会给用户发jwt，用户下一次请求的时候，就会像cookie一样把jwt带上，服务器就检验jwt，检验合格就是身份确认，跟sessionid的确认方式一样，只不过在数据结构里并没有这样的东西。
他把userid通过jwt带过来，用算法解开，发现没篡改过，这个userid就确保是上一个人，还要把这个userid到数据库里验证一下，有没有这个userid，有了才确认。
这个数据可以在很多地方使用，甚至跨域访问，比如搜狐到新浪，自己的服务器做单点登录是可以认的。还可以通过公钥私钥确保请求消息发送者都是可信的‘

jwt使用了一些算法将我们发送给客户端 的信息做了签名，这个签名是防篡改的，并不对数据做任何的加密处理，也就是在浏览器端通过base64解码看到数据原文，不是做数据加密的，不要把敏感信息放里面