今天完成的事情：
看了一天的概念....了解des,token,cookie的基本概念,但有些觉得无从下手
明天计划的事情：
生成token放在cookie中
遇到的问题：
是不是要再次使用到任务4的项目?但是我那个项目是自己写的,导致没登陆功能和其他属性增删改查,估计还少些别的,暂时没想到.如果是要使用任务4又得写加调试,估计又要一天..
收获：
1:cookie:
会话(session)跟踪是web程序中常用的技术,用来跟踪用户的整个会话.常用的会话跟踪技术是cookie与session
cookie通过在客户端记录信息确定用户身份,session通过服务器端记录信息确定用户身份
cookie机制:
在程序中,会话跟踪是很重要的事情,理论上,一个用户的所有请求操作都应该属于同一个会话,而另一个用户的所有请求操作则属于另一个会话,二者不能混淆.例如,用户A在超市购买的任何商品都应该在A的购物车内,不论用户A是什么时间购买的,这都属于同一个会话的,不能放入用户B或者用户C的购物车内,这不属于同一个会话.
而web应用程序是使用HTTP协议传输数据的,HTTP协议是无状态的协议,一旦数据交换完毕,客户端与服务端的连接就会关闭,再次交换数据需要建立新的链接,这就意味着服务器无法从连接上跟踪会话.即用户A购买了一件商品放入购物车内,当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了,要跟踪该会话,必须引入一种机制:
cookie就是这样的一种机制,它可以弥补http协议无状态的不足,在session出现之前,基本所有网站都采用cookie来跟踪对话.
什么是cookie?
cookie已经成为一种标准,所有主流浏览器都支持cookie
由于http是无状态的协议,服务器单从网络连接上无法知道客户身份,这时就给客户端们颁发通行证,每个人都不同,无论谁访问都必须携带自己的通行证,这样服务器就能从通行证上确认客户身份了,这就是cookie的工作原理.
cookie实际上是一小段的文本信息,客户端请求服务器,如果服务器需要记录该用户状态,就使用response向客户端浏览器办法一个cookie,客户端浏览器会把cookie保存起来,当浏览器再请求该网站时,浏览器把请求的网址连同该cookie一同提交给服务器,服务器检查该cookie,以此来辨认用户状态.
2:
token:令牌,代表执行某些操作的权利的对象
token其实说的更通俗点可以叫暗号，在一些数据传输之前，要先进行暗号的核对，不同的暗号被授权不同的数据操作。例如在USB1.1协议中定义了4类数据包：token包、data包、handshake包和special包。主机和USB设备之间连续数据的交换可以分为三个阶段，第一个阶段由主机发送token包，不同的token包内容不一样（暗号不一样）可以告诉设备做不同的工作，第二个阶段发送data包，第三个阶段由设备返回一个handshake包。 token是多用户下处理认证的最佳方式
token特性:
1:无状态,可扩展
在客户端存储的token是无状态的,并且能够被拓展,基于这种无状态和不存储session信息,负载均衡器能够将用户信息从一个服务传到其他服务器上.如果我们将已验证的用户信息保存在session中,则每次请求都需要用户向已验证的服务器发送验证信息(称为session亲和性).用户量大时,可能会造成一些拥堵.使用token之后这些问题都迎刃而解,因为token自己hold住了用户的验证信息
2:可扩展性
token能够创建与其他程序共享权限的程序.例如,能将一个随便的社交账号和自己的大号联系起来,当通过服务登陆twitter时,我们可以将这些buffer附到twitter的数据流上
使用token时,可以提供可选的权限给第三方应用程序.当用户想让另一个应用程序访问它们的数据,我们可以通过建立自己的API,得出特殊
3:跨程序调用,可多平台跨域,只要用户有一个通过了验证的token,数据和资源就能够在任何域上被请求到
4:安全性
请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造).即便在客户端使用cookie存储token,cookie也仅仅是一个存储机制而不是用于认证,不将信息存储在session中,让我们少了对session操作.
token是有时效的,一段时间之后用户需要重新验证.我们也不一定需要等到token自动时效,token有撤回的操作,通过token revocataion可以使一个特定的token或是一组有相同认证的token无效.
使用token的实际项目:facebook,goole,github等
基于服务器验证方式暴露的一些问题
1.Seesion：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。
2.可扩展性：在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。
3.CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。
4.CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。
在这些问题中，可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。
基于Token的验证原理:
基于Token的身份验证是无状态的，我们不将用户信息存在服务器或Session中。
这种概念解决了在服务端存储信息时的许多问题
NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。
基于Token的身份验证的过程如下:
1.用户通过用户名和密码发送请求。
2.程序验证。
3.程序返回一个签名的token 给客户端。
4.客户端储存token,并且每次用于每次发送请求。
5.服务端验证token并返回数据。
每一次请求都需要token,token应该在http的头部发送从而保证了http请求无状态
我们同样通过设置服务器属性Access-Control-Allow-Origin:* ，让服务器能接受到来自所有域的请求。需要注意的是，在ACAO头部标明(designating)*时，不得带有像HTTP认证，客户端SSL证书和cookies的证书。
3:DES
DES是什么?
全称data encryption standard,即数据加密标准.是一种使用密钥加密的块算法
DES作为算法,称为数据加密算法,又称美国数据加密标准
DES是一种对称加密算法,使用56位密钥,以现代计算能力,24小时内即可破解,因此,简单应用中可以使用DES加密算法
注意:DES加密和解密的过程中,密钥长度都必须是8的倍数
DES算法入口参数有三个:key,data,mode.
其中key为7字节共56位,是DES算法的工作密钥
Data为8个字节64位,是要被加密或被解密的数据
Mode为DES的工作方式,有两种:加密或解密
DES基本原则:
DES设计中使用了分组密码设计的两个原则:混淆和扩散目的是抗击敌人对密码系统的统计分析.
混淆是使密文的统计特性与密钥的取值之间的关系尽可能复杂化,使密钥和明文以及密文之间的依赖性对密码分析者来说是无法利用的.
扩散的作用就是将每一位明文的影响尽可能迅速地作用到较多的输出密文位中以便在大量的密文中清除明文的统计结构,并且使每一位密钥的影响尽可能迅速地扩展到较多的密文位中,以防对密钥进行逐段破译
DES算法把64位的明文输入块变为64位的密文输出块,它所使用的密钥也是64位(实际用到了56位,第8,16,24,32,40,48,56,64位是校检位,使得每一个密钥都有奇数个1)
4:对称加密算法
应用实践较早,数据发信方将明文和加密密钥一起经过特殊加密算法处理后,使其变成复杂的加密密文发送出去,收信方收到密文后,若想解读原文,则需要使用加密用过的密钥及相同算法的逆算法对密文进行解密,才能恢复为可读明文
对称加密算法中,使用的密钥只有一个,收发信双方都使用这个密钥对数据进行加密和解密,这就要求解密方事先必须知道加密密钥.
特点在于算法公开,计算量小
缺点:交易双方都是用同样钥匙,安全性得不到保证
返回列表
评论