token验证失败

通常情况下，把API直接暴露出去是风险很大的，不说别的，直接被机器***就喝一壶的。那么一般来说，对API要划分出一定的权限级别，然后做一个用户的鉴权，依据鉴权结果给予用户开放对应的API。目前，比较主流的方案有几种: 用户名和密码鉴权，使用Session保存用户鉴权结果。 使用OAuth进行鉴权（其实OAuth也是一种基于Token的鉴权，只是没有规定Token的生成方式） 自行采用Token进行鉴权 第一种就不介绍了，由于依赖Session来维护状态，也不太适合移动时代，新的项目就不要采用了。第二种OAuth的方案和JWT都是基于Token的，但OAuth其实对于不做开放平台的公司有些过于复杂。我们主要介绍第三种：JWT。 什么是JWT？ JWT是 Json Web Token 的缩写。它是基于 RFC 7519 标准定义的一种可以安全传输的 小巧 和 自包含 的JSON对象。由于数据是使用数字签名的，所以是可信任的和安全的。JWT可以使用HMAC算法对secret进行加密或者使用RSA的公钥私钥对来进行签名。 JWT的工作流程 下面是一个JWT的工作流程图。模拟一下实际的流程是这样的（假设受保护的API在/protected中） 用户导航到登录页，输入用户名、密码，进行登录 服务器验证登录鉴权，如果改用户合法，根据用户的信息和服务器的规则生成JWT Token

1.JWT简介 2.JWT的原理 { "用户名": "admin", "角色": "超级管理员", "到期时间": "2019-07-13 00:00:00" } 为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名（详见后文）。 3.JWT的数据结构 实际的 JWT是一个很长的字符串，中间用点（ . ）分隔成三个部分。 就像下面这样： eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImp0aSI6IjNmMmc1N2E5MmFhIn0.eyJpYXQiOjE1NjI4MzM0MDgsImlzcyI6Imh0dHA6XC9cL3d3dy5weWcuY29tIiwiYXVkIjoiaHR0cDpcL1wvd3d3LnB5Zy5jb20iLCJuYmYiOjE1NjI4MzM0MDcsImV4cCI6MTU2MjkxOTgwOCwianRpIjoiM2YyZzU3YTkyYWEiLCJ1c2VyX2lkIjoxfQ.NFq1qQ-Z5c4pwit8ZkyWEwX6SBXmnHJcc6ZDgSD5nhU JWT的三个部分依次如下： - Header（头部） - Payload（负载） - Signature（签名） 4.JWT的使用方式 客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。 此后

登录鉴权： 1. 用户名+密码 登录请求 2. 后台接收登录请求，生成ToKen（用户名/密码正确） 返回token 3. 请求其他api 都带上token，后台校验token是否存在/过期 后台代码如下： 登录/登出 -------------- @RestController @RequestMapping class AuthController { @Autowired private lateinit var tokenService: TokenService @Autowired private lateinit var appUserService: AppUserService @PostMapping(value = ["/auth/login"]) fun login(username: String, password: String, request: HttpServletRequest): RestResponse<Any> { val predicate = Predicate.eq("username", username).eq("password", password) val user = appUserService.findOne(predicate) ?: return RestResponse(1, "用户不存在") // 生成一个

package com . lst . classifydeviceapi . filter ; import com . lst . api . enummsg . ReturnMsg ; import com . lst . api . utils . JsonUtils ; import com . lst . api . utils . TokenUtil ; import org . slf4j . Logger ; import org . slf4j . LoggerFactory ; import org . springframework . stereotype . Component ; import javax . servlet .*; import javax . servlet . annotation . WebFilter ; import javax . servlet . http . HttpServletRequest ; import javax . servlet . http . HttpServletResponse ; import java . io . IOException ; @Component @WebFilter ( urlPatterns = { "/*" }, filterName =

参考： https://blog.csdn.net/qq_34309704/article/details/80572077 1、Token：token是客户端频繁向服务器端请求数据，服务器频繁的去数据库查询用户名和密码进行对比，判断用户名和密码正确与否，并作出相应的提示，在这样的背景下，token便应运而生了。 2、使用token的目的：token的目的是为了减轻服务器的压力，减少频繁的查询数据库。 3、在前端请求后台的API接口的时候，为了安全性，一般需要再用户登录成功之后才能发送其他请求。 因此，在用户登录成功之后，后台会返回一个token给前端，这个时候我们就需要把token暂时保存在本地，每次发送请求的时候需要在header里边带上token（无需再次带上请求名和密码），这个时候本地的token和后台数据库中的token进行一个验证，如果两者一致，则请求成功，否则失败。 4、如何使用token？ ①使用设备号/设备mac地址作为token（推荐） 客户端：客户端在登录的时候获取设备的设备号/mac地址，并将其作为参数传递到服务器端 服务器：服务器接收到该参数之后，使用一个变量接收同时将其作为token保存数据库，并将该token设置在session中，客户端每次请求的时候都要统一拦截，并将客户端传递的token和服务器session中的token对比，如果相同则放下

token验证方案： session验证方案： session即会话是将用户信息保存在服务端，根据请求携带的session_id，从服务端存储（通常是redis）里提取出session。token即令牌是将用户信息保存在请求中，不过是加密后的值，在服务端需要对token进行解密，从而提取用户信息。 authentication: 这是JWT最常见的应用场景。当用户登陆之后，接下来的每个请求都会携带这个JWT信息。单点登录基本上使用它。 information exchange: JWT是一种安全的多点之间信息传输的方式，因为它使用了签名。 JWT的构成： Header Payload Signature 因此一个JWT看上去是长这样的： xxxxxx.yyyyy.zzzzzz 在此之前，我们将用户登陆后的认证信息保存在SecurityContextHolder中，用户登陆信息保存在ThreadLocal中，理论上不能保证同一用户下一个请求是否被挡。这里将之前提到的Spring security认证方式改成使用token进行认证。 @Slf4j public class PasswordAuthenticationFilter extends UsernamePasswordAuthenticationFilter { private AuthenticationManager

2. 什么是REST REST不是”rest”这个单词，而是几个单词的缩写 REpresentation State Transfer，直接翻译：表现层状态转移，这个翻译不太好理解。网上找到一个比较通俗的说法是：URL定位资源，用HTTP动词（GET，POST，DELETE，PUSH等）描述操作 3. 什么是Restful 基于REST构建的API就是Restful风格。 4. 为什么使用Restful (1). 我们团队之前一直使用JSP作为表现层，但是这样的技术限制了我们的开发效率，我们需要将前端组给出静态html页面转换为jsp页面，并且写一些js代码，甚至是一些前端代码。这样会严重限制我们的开发效率，也不能让后端组专注于业务功能的开发，所以目前越来越多的互联网公司开始实行前后端分离。 (2). 近年随着移动互联网的发展，各种类型的客户端层出不穷，Restful可以通过一套统一的接口为PC、微信(H5)、IOS和Android提供服务，这样的接口不需要前端样式，只提供数据。Restful架构如下： 举一个实际的例子： 比如用户愚公币交易记录列表， PC网站里需要这个功能， Android App里面也需要这个功能， IOS App里面也需要这个功能。 按照我们现有的开发模式，我们就要写了2套(PC和APP端)获取用户说说列表的功能。也就是需要在2个地方都写连接数据库配置信息

随着互联网的不断发展，技术的迭代也非常之快。我们的用户认证也从刚开始的用户名密码转变到基于cookie的session认证，然而到了今天，这种认证已经不能满足与我们的业务需求了（分布式，微服务）。我们采用了另外一种认证方式：基于token的认证。 一、与cookie相比较的优势： 1、支持跨域访问，将token置于请求头中，而cookie是不支持跨域访问的； 2、无状态化，服务端无需存储token，只需要验证token信息是否正确即可，而session需要在服务端存储，一般是通过cookie中的sessionID在服务端查找对应的session； 3、无需绑定到一个特殊的身份验证方案（传统的用户名密码登陆），只需要生成的token是符合我们预期设定的即可； 4、更适用于移动端（Android，iOS，小程序等等），像这种原生平台不支持cookie，比如说微信小程序，每一次请求都是一次会话，当然我们可以每次去手动为他添加cookie，详情请查看博主另一篇博客； 5、避免CSRF跨站伪造攻击，还是因为不依赖cookie； 6、非常适用于RESTful API,这样可以轻易与各种后端（java，.net，python......）相结合，去耦合 还有一些优势这里就不一一列举了。 二、基于JWT的token认证实现 JWT：JSON Web Token，其实token就是一段字符串

功能:登录验证+过期验证+注销清除cookie+未注销下关闭或刷新浏览器仍可直接访问action 概述:token只存在客户端cookie,后端AES加密解密验证,每一次成功访问action都会刷新token包括过期时间 1.过滤器 using System; using System.IO; using System.Security.Cryptography; using System.Text; using System.Web; using System.Web.Mvc; namespace TokenTest.MyActionFilter { /// <summary> /// <param name="Die_Time">Die_Time//设置token过期时间小于7days</param> /// <param name="Jump_Page">Jump_Page//设置token验证失败后跳转页面如/Login/Index;可携带参数/Login/Index?******</param> /// </summary> public class Token_Filter:ActionFilterAttribute//继承ActionFilterAttribute类 { public int Die_Time { get; set;}//设置token过期时间

一. Token出现的背景 1. 在早前的Web应用中，Web 基本上就是文档的浏览而已， 既然是浏览，作为服务器， 不需要记录谁在某一段时间里都浏览了什么文档，每次请求都是一个新的HTTP协议， 就是请求加响应， 尤其是我不用记住是谁刚刚发了HTTP请求，每个请求对我来说都是全新的； 2. 但是随着交互式Web应用的兴起，像在线购物网站，需要登录的网站等等，马上就面临一个问题，那就是要管理会话，必须记住哪些人登录系统， 哪些人往自己的购物车中放商品， 也就是说我必须把每个人区分开，这就是一个不小的挑战，因为HTTP请求是无状态的，所以想出的办法就是给大家发一个会话标识(session id), 说白了就是一个随机的字串，每个人收到的都不一样， 每次大家向我发起HTTP请求的时候，把这个字符串给一并捎过来， 这样我就能区分开谁是谁了； 3. 但是客户端只需要保存自身的session id，而服务器端则要保存所有客户端的session id ，这对服务器说是一个巨大的开销 ， 严重的限制了服务器扩展能力； Token的出现解决了这个问题，因为服务端 不需要存储Token的信息 ，而是通过 CPU的计算 + 数据的加密解密再核对Token的方式 来验证用户是否合法（即HTTP请求信息有没有被篡改），让服务器内存得到释放； 4. session id可以被伪造， 没有采取加密的方法！！！