登录验证记录

1.cookie和session的登录验证

HTTP协议

要弄明白下面说的东西，就得先了解一下HTTP协议，繁琐的概念就不多赘述了，这里主要注意一点，_HTTP协议是无状态的_ ，什么叫无状态？我们从一个故事讲起：

你去一家水果店买水果，你看到他们的桃子很鲜美，于是你大赞了老板的桃子后并买了一斤。你回家尝了桃子后觉得非常好吃，你决定第二天继续购买。当你第二天开开心心的过来找老板，跟他说“你家的水果真的很好吃，再来一斤我昨天买的那个水果”，但是发现老板并不知道你昨天买过什么，于是你非常生气，跟老板说“我昨天还夸了很久你的水果，你怎么就不记得了？”一顿理论后你发现老板始终不记得你昨天干过什么事，最后你只好跟老板表明要买一斤桃子，交易后灰溜溜地离开。

这个故事中的老板就是无状态的，对他来说，他只知道某个人要买什么东西，给了多少钱，要买什么水果，要找多少钱，对于过程中的其它信息如是“谁”来买，他不会记得，他只会针对买卖本身进行处理。

HTTP为什么无状态？

• 首先什么是无状态？

无状态就意味着每个请求之间的不会直接地相互影响，对于每个请求，同样的请求参数就会得到同样的结果。

• 回到HTTP协议中：

最初的需求是请求HTML界面显示出静态网站，并不如现在那么复杂丰富，用户A点击某个网址浏览到的页面和用户B点击同样网址浏览到的页面是完全一模一样的，也就是服务器并不会对每个不同的人有特殊处理，服务器只对请求负责，不对发起请求的人负责。因此在HTTP设计中，每个请求都是独立的，每个请求中都包含了请求的所有数据，服务器只对请求和请求中携带的信息进行处理后返回特定结果。就如上面的那个水果店，老板只根据要买什么水果，水果多少钱，给了多少钱，进行处理，如果你跟他说你昨天与他交谈如何，他无动于衷，因为他完全不会记得这些事情，他完全不记得你曾来过。

HTTP如何保存登录状态？

前面说到，HTTP是无状态的，每个请求之间的不会直接地相互影响。

当我第一次调用用户名密码验证接口的时候，我需要输入账号、密码，服务器收到请求之后，就会根据账号去数据库取你的密码和你输入的密码进行比对，然后返回一个“密码正确”或“密码错误”。而问题在于当我第二次访问这个接口的时候，服务器依旧会执行他的职能：收到我发送的账号和密码，然后去数据库取数据进行比对后返回比对结果，对于服务器来说，每个请求不过是做了类似1+1是否等于2的判断然后返回结果而已。

我想要服务器能够记住我已经调用过一次登录接口并且以及成功了这个状态，应该怎么办？

我们可以很自然的想到，服务器不知道我们登录过的原因是因为没有记下来，要保持登录状态，只要让服务器记下来就可以了。我们可以在服务器专门设置一个存储，每次只要我验证账号和密码成功，就在这个存储里面存下“JabinGP登录成功”（这个JabinGP是用户名），这样我们服务器就记得JabinGP登录过了。

现在服务器已经知道JabinGP登录过了，但是这就够了吗？不够，因为HTTP请求并不会自动标明“这是JabinGP发起的请求”，所以我们还要做点工作让服务器能知道“这是JabinGP发起的请求”，然后服务器才好去存储下来的登录状态里面找“JabinGP登录成功”这个标志。怎么做？我们可以在调用请求的时候把自己的用户名加进请求的参数中，比如Get请求的URl参数、Post请求的请求Body中，这样服务器就可以根据我们的用户名判断我们有没有登录过了。

这样我们就初步的把登录状态保存了下来，其实这样的验证非常粗糙，所以基于这个思想，产生了下面的技术。

什么是Cookie？

有很多品牌的Cookie，比如说蓝罐，广州酒家......什么？哦哦不好意思我搞错了，这个才是Cookie：Cookie就是存储在客户端的一小段数据，它可以存在硬盘中（永久Cookie），也可以存在内存中（临时Cookie）

什么是Session？

Session是指服务器为某个会话开启的一段独特的存储空间（会话是指一个终端用户与交互系统进行通讯的过程，比如说我先登录，再查看我的邮箱内容，这个过程就是一个会话），一个Session用唯一的SessionId对应一段存储空间。

Cookie和Session是怎么用的？

首先从概念上，Cookie和Session都是用来存东西的，问题在于它们都用来存什么，以及它们都做了什么？
结合前面分析：

• Cookie的出现，代替了手动设置标识的步骤，因为我们可以把标识设置在Cookie里面，设置了Cookie后，Cookie就存在了，下次请求Cookie就会自动发送给服务器，这样我们就不用给每个请求都很麻烦地手动设置一个标识（比如前面分析中的用户名）。
• Session其实就是代替了在服务器存储状态的步骤，SessionId可以对应一段存储空间，这段空间对每个会话都是唯一的（比如我登录后，就产生了一个会话，也产生了一段存储空间，这段存储空间只被我当前的登录状态下的活动所使用，别人是用不到的），这样就可以确保每个登录状态都有对应的一小段存储空间来写入一些中间过程的数据。

Cookie和Session的关系？

看了上面的Cookie和Session的解释，以及Cookie和Session的使用，就可以发现它们两个其实完全不冲突，甚至这两者是需要相互配合的，因为Cookie是在客户端的存储，Session是在服务端的存储，Session的存储需要SessionId来一一对应，这样才不会出现xxx获得了JabinGP的登录状态然后用JabinGP的钱买东西这样的情况，SessionId则需要通过Cookie保存在用户客户端中，客户端通过保存在Cookie的SessionId来标识自己，表明“我就是JabinGP”。

以上转载于https://segmentfault.com/a/1190000019065025

SessionID被抓包截取怎么办？

1）服务端验证sessionID+ip的组合方式等等

2）使用https ----请求内容都是ssl加密的；

如果你去网吧登录，忘记关浏览器，登录状态还在，这就办法了，这个时候只能靠session过期时间，或者别人的善心，怪你自己粗心大意；

基于session认证所显露的问题

1、Session：每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大2、扩展性：用户认证之后，服务端做认证记录，如果认证的记录被保存在内存的话，这意味着用户下次请求还必须要请求在这台服务器上，这样才能拿到授权的资源，这样在分布式的应用上，响应的限制了负载均衡器的能力，也意味着限制了应用的扩展性3、CSRF：因为是基于cookie来进行用户识别的，cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击

 

2.Json web token（JWT）使用

百度看jwt原理；这有一篇可参考https://blog.csdn.net/qq_28165595/article/details/80214994

使用jwt和用随机字符串生成的token有啥区别？

1）使用普通token，服务端效验需要查数据库是否存在这个token，查库看看是否过期等；

2）使用jwt生成的token，直接验证签名就行了，不需要查数据库；就算要查库在payload存了个用户id，拿id去查肯定比你拿token字符串去查快；

3）比如说你判断用户是否是vip； 在jwt的payload里面添加字段isVip就行了；不需要查库去判断是不是，普通的token就要查库判断了；

 

3.RSA非对称加密算法

1）非对称加密指的是：加密和解密使用不同的秘钥，一把作为公开的公钥，另一把作为私钥。公钥加密的信息，只有私钥才能解密。私钥加密的信息，只有公钥才能解密。 私钥只能由一方安全保管，不能外泄，而公钥则可以发给任何请求它的人。非对称加密使用这对密钥中的一个进行加密，而解密则需要另一个密钥。

我们常见的数字证书、加密狗即是采用非对称加密来完成安全验证的。

优点：安全性更高，公钥是公开的，秘钥是自己保存的，不需要将私钥给别人。

缺点：加密和解密花费时间长、速度慢，只适合对少量数据进行加密。

使用：比如用户POST提交账号密码的时候用公钥加密，就算中间人截获到信息也解密不了；因为只有私钥可以解密；

2）对称加密指的就是加密和解密使用同一个秘钥，所以叫做对称加密。对称加密只有一个秘钥，作为私钥。

具体算法有：DES，3DES，TDEA，Blowfish，RC5，IDEA。常见的有：DES，AES，3DES等等。

优点：算法公开、计算量小、加密速度快、加密效率高。

缺点：秘钥的管理和分发非常困难，不够安全。在数据传送前，发送方和接收方必须商定好秘钥，然后双方都必须要保存好秘钥，如果一方的秘钥被泄露，那么加密信息也就不安全了。另外，每对用户每次使用对称加密算法时，都需要使用其他人不知道的唯一秘钥，这会使得收、发双方所拥有的钥匙数量巨大，密钥管理成为双方的负担。

3）两者的区别

对称加密算法相比非对称加密算法来说，加解密的效率要高得多。但是缺陷在于对于秘钥的管理上，以及在非安全信道中通讯时，密钥交换的安全性不能保障。所以在实际的网络环境中，会将两者混合使用.