zoukankan      html  css  js  c++  java
  • session和cookie的区别

    二个都用来存放私密的东西,也有有效期

     session是存在服务器上的,是否过期取决于服务器的设定,cookie是存在客户端的,是否过期是可以在生成cookie的时候设置的。

    区别:

    1、cookie数据存放在客户端的浏览器上

       session是存在服务器上

    2、cookie不安全,别人可惜分析存放在本地的cookie进行cookie欺诈

      考虑安全应该使用session

    3、session会在一定时间内保存在服务器上,当访问增多的时候,会比较占用服务器的性能

          考虑性能方面应该使用cookie

    4、单个cookie在客户端的显示是3K,很多站点默认最多保存20个cookie。

    5、将登陆信息存放再session中

      其他的保留信息存放在cookie中

    6、cookie的内容主要包括:名字、值、过期时间、路径和域(构成cookie的作用范围),若不设置过期时间,表示这个cookie的生命周期是浏览器的会话期间,关闭浏览器cookie就会消失;若设置了过期时间,浏览器就会把cookie保存在硬盘上,关闭浏览器再次打开这些cookie依然有效;存在硬盘上的cookie可以在不同的浏览器进程之间共享,存在内存的cookie,不同的浏览器有不同的处理方式;

       session的生成期是会话结束后就消失,若和数据库配合使用,可以使Session数据长期保持,并得到很好的安全性.

       当程序需要为客户端的请求创建一个session时。服务器首先检查这个客户端请求里面是否已经包含一个session标识(称为sessionID),如果已经包含,说明以前创建过了,服务器就按照这个sessionID来试验;如果没有,则会为客户端创建一个session并且生成一个与此session相关联的sessionID,这个sessionID会在本次响应中返回给刻画段保存。保存这个sessionID的方式可以采用cookie,然后瞎猜浏览器和服务器交互的时候把这个sessionID发给服务器;

    传统的session认证

      我们知道,http协议本身是一种无状态的协议,而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证,那么下一次请求时,用户还要再一次进行用户认证才行,因为根据http协议,我们并不能知道是哪个用户发出的请求,所以为了让我们的应用能识别是哪个用户发出的请求,我们只能在服务器存储一份用户登录的信息,这份登录信息会在响应时传递给浏览器,告诉其保存为cookie,以便下次请求时发送给我们的应用,这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。

    但是这种基于session的认证使应用本身很难得到扩展,随着不同客户端用户的增加,独立的服务器已无法承载更多的用户,而这时候基于session认证应用的问题就会暴露出来.

    基于session认证所显露的问题

    Session: 每个用户经过我们的应用认证之后,我们的应用都要在服务端做一次记录,以方便用户下次请求的鉴别,通常而言session都是保存在内存中,而随着认证用户的增多,服务端的开销会明显增大。

    扩展性: 用户认证之后,服务端做认证记录,如果认证的记录被保存在内存中的话,这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源,这样在分布式的应用上,相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。

    CSRF: 因为是基于cookie来进行用户识别的, cookie如果被截获,用户就会很容易受到跨站请求伪造的攻击。

    基于token的鉴权机制

    基于token的鉴权机制类似于http协议也是无状态的,它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了,这就为应用的扩展提供了便利。

    流程上是这样的:

    • 用户使用用户名密码来请求服务器
    • 服务器进行验证用户的信息
    • 服务器通过验证发送给用户一个token
    • 客户端存储token,并在每次请求时附送上这个token值
    • 服务端验证token值,并返回数据

    这个token必须要在每次请求时传递给服务端,它应该保存在请求头里, 另外,服务端要支持CORS(跨来源资源共享)策略,一般我们在服务端这么做就可以了Access-Control-Allow-Origin: *

    那么我们现在回到JWT的主题上。

    JWT长什么样?

    JWT是由三段信息构成的,将这三段信息文本用.链接一起就构成了Jwt字符串。就像这样:

    eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

    JWT的构成

    第一部分我们称它为头部(header),第二部分我们称其为载荷(payload, 类似于飞机上承载的物品),第三部分是签证(signature).

    header

    jwt的头部承载两部分信息:

    • 声明类型,这里是jwt
    • 声明加密的算法 通常直接使用 HMAC SHA256

    如何应用

    一般是在请求头里加入Authorization,并加上Bearer标注:

    fetch('api/user/1', {
      headers: {
        'Authorization': 'Bearer ' + token
      }
    })

    服务端会验证token,如果验证通过就会返回相应的资源。

     

     

  • 相关阅读:
    Codeforces 963E Alternating Sum 等比数列+逆元
    poj 3255 次短路
    hdu 3183 rmq+鸽巢原理
    poj 2505 乘法博弈论
    欧拉函数模板
    java中的进制转换以及字符串类和数值类的相互转化
    java 大数运算,高精度模板
    线段树模板
    [OI笔记]每周刷题记录
    HDU4388-Stone Game II-Nim变形
  • 原文地址:https://www.cnblogs.com/bell1991/p/7243396.html
Copyright © 2011-2022 走看看