发表于： 2017-05-10 10:59:12
3 2060
今天完成的任务:
调试运行任务五,和师兄们分享,思考session,cookie,token
一.,使用DES对用户ID和登录时间加密，生成Token，放入Cookie中，拦截器里通过Cookie中判断Token的有效性来判断用户是否登录, 以下面的代码实现DES加密,并放入Cookie中
以下代码实现拦截器拦截并验证cookie
controller代码有许多代码段,在理解过程中有点小收获,在这里记下来
1.@RequestMapping(value = "/loginfrom",method = RequestMethod.POST)
public String login(
@RequestParam("name") String name,
@RequestParam("password") String password,
Model model)方法中传入的参数,下面的方法可以直接使用.
比如在
public void setName(String name) {
this.name = name;
}
中,上面方法中的形参名字可以随便起,它是在调用该方法的入参,只要数值类型匹配就行了.这个方法的功能只是给上面声明的name这个变量赋值.所以说是set.name这里的(String student)或者阿猫,啊狗都可以.
静态方法,也叫类方法,可以直接用类名调用,也就是说可以把类看成一个对象,它是父类的对象.可以直接调用其中的静态方法.而实例方法,或者普通方法,必须要有实例对象后用构造函数赋值(null也是值)后才能调用.因为具体的对象都是实际存在的实体,必须给予它属性.
2.实现前台和后端数据在jsp上的传输,model连接jsp和controller,查询出的内容会塞到model,输出到jsp,比如下面这样,有一点不解的是只能查到这个接口,它的实现在哪里呢?
"model.addAttribute("studentList", studentList);"
这是具体的接口
package org.springframework.ui;
import java.util.Collection;
import java.util.Map;
public interface Model {
^^^^^^
}
3.Base64是一个类"import org.apache.commons.net.util.Base64"引入它的encondeBase64String(bytes)方法.
public static String encodeBase64String(byte[] binaryData) {
return newStringUtf8(encodeBase64(binaryData, true));
}
完成对toke的先加密(desCrypto()方式),再编码(Base64.encodeBase64String())并存入cookie
String token = id +"="+System.currentTimeMillis();
byte[] bytes = DESUtil.desCrypto(token, "12345678");
Cookie cookie = new Cookie("token", Base64.encodeBase64String(bytes));
4.这里httpServletResponse.addCookie(cookie);httpServletResponse是一个interface,需要实现.
运行结果:
二.分享
1.内容
cookie
cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。若不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就消失。这种生命期为浏览器会话期的cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。若设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式.
session
当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。
保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。
session机制。session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。
cookie,session的区别
具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。
cookie机制。一般的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript也可以生成cookie。而cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。
2.讨论
在分享的过程中,莎莎师兄提出了很多有益于思考的问题,拓展了自己的思路,也解开了很多疑惑.
第一点:代码段中缺少验证环节,会造成异常无法处理的情况
正确的情况是应该加上if判断
第二点,token令牌在访问没有cookie的手机等移动客户端时可以提供身份验证,不装在cookie里,也可以单独使用(明天自己尝试能不能单独用token验证)
第三点,莎莎师兄提供的内容,更加详细和具有操作性,丰富了自己的验证知识
后端服务器有两种基本的身份验证：
b.基于令牌Token的认证，较新的方法，依赖于被发送到服务器上每个请求的签署令牌。
token的优势
a. 跨域: / CORS: cookies并不能跨不同的域名:
b. 无态(代表服务器端可伸缩): 没有必要将会话保存，令牌 token 自己是一个自我包容的实体，包含用户各种信息，其他状态信息可以保存在cookie或客户端本地存储器中
c. CDN: 能够适用来自CDN任何应用部件(e.g. javascript, HTML, images, etc.), 你的服务器只是一个 API.
d. 解耦: 你不必和一个特定的验证格式Schema绑定，令牌token 能在任何地方产生，这样的你的API可以在任何地方以同一种验证方式调用验证。
e.对移动Mobile友善: 当你在一个原生平台(iOS, Android, Windows 8, etc.)时， cookies依赖于一个安全API，并不是好主意，因为你得和一个cookie容器打交道，而基于令牌则简单多。
f.CSRF: 因为你不依赖cookies, 你就不需要跨请求保护，(e.g. it 有可能来自 <iframe> 请求一个POST，需要重用一个存在的验证。).
g.性能:一个网络往返（如发现在数据库中的会话）可能会比计算的HMACSHA256验证令牌耗费更多时间
h.基于标准: 你的API能接受一个标准的 JSON Web Token (JWT). 这个标准后面有多个库(.NET, Ruby, Java, Python, PHP)，许多公司支持(e.g. Firebase, Google, Microsoft). ，比如Firebase允许他们的客户使用任何身份验证机制，只要你使用预先定义的属性生成一个 JWT，并使用共享密钥签署，就能调用它们的API.
基于Token的验证原理
基于Token的身份验证是无状态的，我们不将用户信息存在服务器或Session中。
这种概念解决了在服务端存储信息时的许多问题
NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。
基于Token的身份验证的过程如下:
a.用户通过用户名和密码发送请求。
b.程序验证。
c.程序返回一个签名的token 给客户端。
d.客户端储存token,并且每次用于每次发送请求。
e.服务端验证token并返回数据。
遇到的问题:
可以说因为要分享,今天的压力增加了,很快的进入了状态,效率提高了不少.看来需要给自己一点压力.
收获:
分享是一个很不错的方法,激发自己的能量,碰撞他人的思想.可以成倍的提高效率.
明天的计划:
开始任务六,尝试用token单独实现验证.
返回列表
评论