python数据可视化数据分析与决策
63.2元
(需用券)
去购买 >
session简介
做过Web开发的程序员应该对Session都比较熟悉，Session是一块保存在服务器端的内存空间，一般用于保存用户的会话信息。
用户通过用户名和密码登陆成功之后，服务器端程序会在服务器端开辟一块Session内存空间并将用户的信息存入这块空间，同时服务器会
在cookie中写入一个Session_id的值，这个值用于标识这个内存空间。
下次用户再来访问的话会带着这个cookie中的session_id，服务器拿着这个id去寻找对应的session，如果session中已经有了这个用户的
登陆信息，则说明用户已经登陆过了。
使用Session保持会话信息使用起来非常简单，技术也非常成熟。但是也存在下面的几个问题：
服务器压力大：通常Session是存储在内存中的，每个用户通过认证之后都会将session数据保存在服务器的内存中，而当用户量增大时，服务器的压力增大。
Session共享：现在很多应用都是分布式集群，需要我们做额外的操作进行Session共享；
CSRF跨站伪造请求攻击：Session机制是基于浏览器端的cookie的，cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
基于token的认证
基于token的认证机制将认证信息返回给客户端并存储。下次访问其他页面，需要从客户端传递认证信息回服务端。简单的流程如下：
客户端使用用户名跟密码请求登录；
服务端收到请求，去验证用户名与密码；
验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端；
客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里；
客户端每次向服务端请求资源的时候需要带着服务端签发的 Token；
服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据；
基于token的验证机制，有以下的优点：
支持跨域访问，将token置于请求头中，而cookie是不支持跨域访问的；
无状态化，服务端无需存储token，只需要验证token信息是否正确即可，而session需要在服务端存储，一般是通过cookie中的sessionID在服务端查找对应的session；
无需绑定到一个特殊的身份验证方案(传统的用户名密码登陆)，只需要生成的token是符合我们预期设定的即可；
更适用于移动端(Android，iOS，小程序等等)，像这种原生平台不支持cookie，比如说微信小程序，每一次请求都是一次会话，当然我们可以每次去手动为他添加cookie，详情请查看博主另一篇博客；
避免CSRF跨站伪造攻击，还是因为不依赖cookie；
缺点的话一个就是相比较于传统的session登陆机制实现起来略微复杂一点，另外一个比较大的缺点是由于服务器不保存 token，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 token 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
退出登陆的话，只要前端清除token信息即可。
基于JWT的token认证实现
JWT(JSON Web Token)就是基于token认证的代表，这边就用JWT为列来介绍基于token的认证机制。
需要引入JWT的依赖
com.auth0
java-jwt
3.8.2
生成token和验证token的工具类如下：
public class JWTTokenUtil {
//设置过期时间
private static final long EXPIRE_DATE=30*60*100000;
//token秘钥
private static final String TOKEN_SECRET = "ZCfasfhuaUUHufguGuwu2020BQWE";
public static String token (String username,String password){
String token = "";
try {
//过期时间
Date date = new Date(System.currentTimeMillis()+EXPIRE_DATE);
//秘钥及加密算法
Algorithm algorithm = Algorithm.HMAC256(TOKEN_SECRET);
//设置头部信息
Map header = new HashMap<>();
header.put("typ","JWT");
header.put("alg","HS256");
//携带username，password信息，生成签名
token = JWT.create()
.withHeader(header)
.withClaim("username",username)
.withClaim("password",password).withExpiresAt(date)
.sign(algorithm);
}catch (Exception e){
e.printStackTrace();
return  null;
}
return token;
}
public static boolean verify(String token){
/**
* @desc   验证token，通过返回true
* @params [token]需要校验的串
**/
try {
Algorithm algorithm = Algorithm.HMAC256(TOKEN_SECRET);
JWTVerifier verifier = JWT.require(algorithm).build();
DecodedJWT jwt = verifier.verify(token);
return true;
}catch (Exception e){
e.printStackTrace();
return  false;
}
}
public static void main(String[] args) {
String username ="name1";
String password = "pw1";
//注意，一般不会把密码等私密信息放在payload中，这边只是举个列子
String token = token(username,password);
System.out.println(token);
boolean b = verify(token);
System.out.println(b);
}
}
执行结果如下：
Connected to the target VM, address: '127.0.0.1:11838', transport: 'socket'
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXNzd29yZCI6IjEyMyIsImV4cCI6MTU5NzM5Nzc0OCwidXNlcm5hbWUiOiJ6aGFuZ3NhbiJ9.LI5S_nX-YcqtExI9UtKiP8FPqpQW_ccaws2coLzyOS0
true
关于DecodedJWT这个类，大家可以重点看下，里面包含了解码后的用户信息。
JWT的使用说明
客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。
此后，客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。
Authorization: Bearer 
另一种做法是，跨域的时候，JWT 就放在 POST 请求的数据体里面。
JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。(或者是对JWT在前后端之间进行加密之后在传输)
关于JWT的一个问题
上面生成JWT token的过程关键点就是密钥，假如这个密钥泄露了，那是不是就可以伪造token了。
还有就是生产环境的密钥值，开发的程序员大概率是知道的，怎么防止程序要监守自盗，伪造token值呢？希望有经验的大佬指教下。
//token秘钥
private static final String TOKEN_SECRET = "ZCfasfhuaUUHufguGuwu2020BQWE";
参考
https://www.cnblogs.com/achengmu/p/12693260.html
https://www.cnblogs.com/ruoruchujian/p/11271285.html
JWT使用详解
JWT官网
java 11官方入门(第8版)教材
79.84元
包邮
(需用券)
去购买 >

目录
session认证
session认证过程
cookie与session的区别
Token认证
Token认证过程
session与token的区别
keep-alive

HTTP是一个无状态的面向连接的协议，服务器不知道客户端的状态，比如使用用户名密码认证成功后，在下一次的请求中，服务器不知道用户是谁，如果需要后续服务，需要进行重新认证。然而，在某些场景，我们需要保存某些状态，比如在购物网站进行商品购买时，在某个域名下浏览多个网页，选择多个商品，这种情况下需要保存已加入购物车的商品信息，在需要支付时，也要保存用户认证信息。为了实现保存用户登录状态，可以使用session或者token解决HTTP协议的无状态特性。
session认证
session认证过程
session用于记录服务器和客户端之间的会话状态，下面以用户认证为例介绍session连接过程：



client发送post请求到server端
server端接收到请求并认证通过后建立一个session，HTTP响应中包含Set-Cookie头部（包括了一个sessionId）
client再次发送请求时请求头中携带了cookie
服务器根据cookie值来验证client信息（根据sessionId与保存的session进行比较来验证用户身份），并对client进行响应。

cookie与session的区别

cookie是实现session的其中一种方案，session可以基于 cookie，也可以基于 query参数。
cookie存储在客户端，客户端（浏览器）接受服务器的Set -Cookie指令，并把 cookie保存到电脑上。
session存储在服务端，只把关联数据的一个加密串放到 cookie中标记
根据他们的存储位置，session相对来说更加安全。

Token认证
Token认证过程
Token认证是另外一种常用的身份认证方式，相比session更加安全，比较常用的Token认证方案是JSON Web Token（JWT），是一种基于 JSON 的开放标准（RFC 7519），客户端和服务器之间使用JSON对象进行安全信息传输，信息进行数字签名，可以使用私钥（HMAC算法）或者公钥/私钥对（RSA算法）进行签名。Token认证过程可以简单描述如下：


client发送post请求到server端
server端使用秘钥创建JWT并将JWT发送给client
client本地保存JWT，client在每次请求的请求头中携带JWT
server端验证JWT并响应

在token认证中，可以凭借认证信息生成 token，也可以通过后台配置token，比如配置github的token：

常用的token认证header使用Bearer 模式：Authorization: Bearer <token>，比如Github:
$ curl -H "Authorization: Bearer TOKEN" https://api.github.com/user

session与token的区别

token是一个用户请求时附带的请求字段，用于验证身份与权限，不存储在服务器上。
token 安全性比 Session 要好，因为token每一个请求都有数字签名，Session 仅通过sessionId进行简单认证。
大多web应用和移动设备身份验证使用token进行身份认证，android原生系统不支持cookie。

keep-alive
现在已经大致了解了session和token这两种认证方式，那么HTML 页面加载流程是什么呢？在开头提到过，HTTP是一个无状态的面向连接的协议，HTTP是应用层协议，TCP协议工作在传输层，在进行认证之前需要进行TCP连接，也就是三次握手。
HTML 页面加载、解析流程大致如下：

浏览器向服务器发起请求，浏览器先查询本地（浏览器或者本机）DNS缓存，如果没有，向DNS 服务器发起 域名解析请求
浏览器拿到域名对应的IP地址后，建立与服务器的 TCP/IP 连接（3次握手，断开连接进行4次挥手）
浏览器向服务器发送 HTTP / HTTPs 请求，服务器进行后台内部处理，进行HTTP响应，返回状态和浏览器请求的内容。session和token认证过程就在这一步完成。
浏览器接收到HTTP数据包后进行解析

解析HTML页面代码，遇到静态资源（js、css、图片等）则向服务器发起请求。
从上到下进行加载、渲染，下载和渲染同时进行
js文件的加载会阻塞HTML内容的加载
CSS样式表下载完成之后会跟之前的样式表一起进行解析，会对之前的元素重新渲染



上面的步骤中提到了静态资源的请求，在HTTP/0.9版本中使用短连接，发送完 HTTP 的响应之后，服务器就会断开 TCP 连接，遇到需要请求资源时，浏览器会重新建立一个HTTP会话，也就是重复第一步。为了节约资源，HTTP/1.0版本新增了 keep-alive 字段（长连接，不过默认还是短连接），HTTP/1.1默认开启长连接。
长连接表示在完成HTTP 请求之后，不断开TCP 连接，这样之后发送 HTTP 请求就不需要重新建立 TCP 连接了。在请求头中加入了Connection: keep-alive 字段，当然，实现长连接需要客户端和服务端都支持，如果不希望使用长连接，在请求头中加上Connection: close。长连接不会永久保持，一般会有一个超时时间，某些服务器还会设置一个最大请求次数，如果超过就断开连接。
--THE END--

欢迎关注公众号:「测试开发小记」及时接收最新技术文章！

token单点登入原理及实现过程
什么是单点登入（SSO）
token单点原理
安全性
代码演示

什么是单点登入（SSO）
首先举个例子：

对于某个银行系统，本身有开发自己的系统，比如门户之类的。最近有新的新的需求，比如数据分析的业务需求，于是购买了一套数据分析系统、，之后又上线了一套贷款系统等等，如下图。那么用户在在登入操作的时候，就会面临一个问题，多个系统之间是不是需要登入多次呢？



比如我从门户页面进入系统，接下来要在贷款系统上进行操作，那是不是又要输入一次用户名、密码？如果没有密码的话肯定会有安全问题。这时候就要用到SSO单点了，只需要在门户首页登入一次，在各个系统中可以进行免登入操作。

单点登录(Single Sign On)，简称为 SSO，在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

常见的SSO有token回调、Oauth、cas，同时还可以集成在第三方系统上，比如微信、钉钉等。这篇文章主要介绍token单点登入。
token单点原理


a、首先要求用户登入自己的系统（银行系统），然后打开第三方系统，比如通过url访问第三方系统，在访问的时候携带上token（一般是作为参数直接拼接在url上）；

b、当第三方系统接收到一个未登入的请求时，会调用客户系统（银行系统或者独立的验证系统）提供接口对这个token进行校验，如果检验成功，则返回用户信息（比如用户id，登入name），验证失败则跳转到错误页面；

c、第三方系统（数据分析系统）拿到这些信息后，对该请求根据返回的用户名进行登入处理。
对于自己的系统来说，需要完成的工作是：提供一个验证token的接口，在跳转到第三方系统时生成token并且放到请求中。对于第三方系统来说，需要开发一个拦截请求然后判断登入的逻辑（常见的处理方式是  过滤器）。
安全性
1、在整个过程中是没有用户名和密码的传递的，不会存在密码被盗用的风险；

2、对于自己的系统来说，不会让第三方公司知道自己的加密策略的加密手段，因为生成token和验证token的过程都是在自己系统上进行，第三方系统并不关心这个过程是如何进行的，只需要返回一个验证结果就行了；

3、比较担心的是token如果被拦截获取，是不是就可以从别的地方根据这个token登入第三方系统了呢？

分情况讨论吧：

a、首先一般这个token是一串很长的字符串，凭肉眼记忆几乎是不可能的，被盗的情况应该是这台电脑中病毒，从而请求被拦截并获取盗这些参数。对于内网环境、或者安全级别比较高的办公环境来说，这种可能性很小；

b、token往往具有时效性、一般有效期在2~3分钟（每个厂子的安全策略不同，控制的时间也不同），即使被拷贝给其他人，很快也会失效；

c、更高级的做法，就是token只能检验一次，然后就会被回收，这样几乎不存在泄露的问题。
token生成机制有很多，比如 通过MD5来进行加密得到加密串，md5(用户名 + 时间戳 + key)、或者hash算法生成等等。
代码演示
客户的回调接口java代码举例
public class TokenCheckServlet extends HttpServlet {

 private static final long serialVersionUID = 1L;

    
   public TokenCheckServlet() {

       super();

   }

 protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
         String token = request.getParameter("token");
         if(token == null || "".equals(token.trim())) {
                //token不存在处理逻辑
         return;
         }
         else {
                 // 校验token是否合法
                 StringBuilder result = new StringBuilder();
                 
                 if(check(token)) {
                 //token验证通过就返回当前登录用户
                  result.append("{\"result\":\"success\",\"userId\":\"test\"}");
                 }
                 else {
                   // token验证没通过就不返回userId。
                   result.append("{\"error\":\"james\"}");
                 }

                 response.getWriter().write(result.toString());
         }
 }

 
/**
*校验tokan是否有效
*/
 private boolean check(String token) {
        return true;
 }
 
 protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
      doGet(request, response);
 }
}

一、简述

1、在web刚兴起的时候，人们使用网络主要是用来浏览文章，服务器不需要记录某位用户看了哪篇文章。

2、随着网上购物的出现，服务器必须区分登陆的每一个用户，记住哪位用户购买了什么东西，向购物车添加了什么商品，为此，服务器为每一个用户生成一个唯一的识别码,如：session，使用户每次请求时都携带该码。

3、但是随着用户量的增多，管理session的成本及开销越来越大，一台机器A已经顶不住压力，所以我们做了横向扩展，再增加一台机器B，用这两个机器做一个集群，但是用户的请求不一定转发到哪一个机器上，这就导致了，当用户F在机器A上登陆后，再次请求服务器，请求到了机器B上，可是机器B上并没有F的认证信息，导致用户F得重新认证，所以我们想出了粘连session，这样访问机器A的用户就一直访问机器A，不会访问机器B。

4、可是当机器A挂掉之后，用户只能访问机器B，而机器B上还是没有用户F的认证信息，所以用户F又得重新认证，后来我们想出了各个机器间session同步的方法，当一个用户在任何一个机器上认证以后，该session信息将复制给该集群下的所有其他机器。

5、但是这样的话频分的复制session，又极大了增加了服务器的开销，在这时，memcache提出了将session存于一处的方法，所有机器要获取的数据都从存储session的地方读取。

6、这样虽然降低了服务器开销，但是又会出现单点崩溃的现象，如果memcache挂掉，那么所有的用户都得重新登陆。所有的session都在服务器端管理，那么交由浏览器端管理呢。用户认证成功后，服务器向浏览器返回用户唯一识别信息和一个用只有服务器端才知道的密钥加密用户信息后的结果，如：token，浏览器每次请求服务器都必须携带该token信息，服务器每次获取用户唯一信息，然后经过服务器的加密算法，得到的结果与token的结果相同，来标识是哪位用户。以延长计算时间来减少空间存储。

如今，token是多用户认证系统最受欢迎的方法，它无状态，跨平台。