token验证失败

用户登录登出

天大地大妈咪最大 提交于 2019-12-03 04:26:24
记录一个使用redis记录token的用户登录登出 参考demo地址 https://gitee.com/super_star_man/juneweb 1.用户实例 package top.xzhand.po; import lombok.Data; import java.io.Serializable; import java.util.Date; @Data public class UserInfo implements Serializable { private Long id; private String username; private String password; private String mobile; private Date createAt; private Date updateAt; private Integer status; private String photoUrl; private String nickname; private String wxId; } package top.xzhand.dto; import lombok.Data; import java.io.Serializable; import java.util.Date; @Data public class UserInfoDto

【1101 | Day58】一篇文章彻底理解cookie,session,token

痴心易碎 提交于 2019-12-03 03:37:46
目录 彻底理解cookie,session,token 发展史 Cookie Session Token 彻底理解cookie,session,token 发展史 1、很久很久以前,Web 基本上就是文档的浏览而已, 既然是浏览,作为服务器, 不需要记录谁在某一段时间里都浏览了什么文档,每次请求都是一个新的HTTP协议, 就是请求加响应, 尤其是我不用记住是谁刚刚发了HTTP请求, 每个请求对我来说都是全新的。这段时间很嗨皮 2、但是随着交互式Web应用的兴起,像在线购物网站,需要登录的网站等等, 马上就面临一个问题,那就是要管理会话,必须记住哪些人登录系统, 哪些人往自己的购物车中放商品, 也就是说我必须把每个人区分开,这就是一个不小的挑战,因为HTTP请求是无状态的 ,所以想出的办法就是给大家发一个会话标识(session id), 说白了就是一个随机的字串,每个人收到的都不一样, 每次大家向我发起HTTP请求的时候,把这个字符串给一并捎过来, 这样我就能区分开谁是谁了 3、这样大家很嗨皮了,可是服务器就不嗨皮了,每个人只需要保存自己的session id,而服务器要保存所有人的session id ! 如果访问服务器多了, 就得由成千上万,甚至几十万个。 这对服务器说是一个巨大的开销 , 严重的限制了服务器扩展能力, 比如说我用两个机器组成了一个集群,

springboot+redis+Interceptor+自定义annotation实现接口自动幂等

匿名 (未验证) 提交于 2019-12-03 00:44:02
前言: 在实际的开发项目中,一个对外暴露的接口往往会面临很多次请求,我们来解释一下幂等的概念: 任意多次执行所产生的影响均与一次执行的影响相同 redis实现自动幂等的原理图: Ŀ¼ 一:搭建redis的服务Api 1:首先是搭建redis服务器,这个之前搭过了,就不赘述了。详情可参考: https://www.cnblogs.com/wyq178/p/10340234.html 2:引入springboot中到的redis的stater,或者Spring封装的jedis也可以,后面主要用到的api就是它的set方法和exists方法,这里我们使用springboot的封装好的redisTemplate /** * redis工具类 */ @Component public class RedisService { @Autowired private RedisTemplate redisTemplate; /** * 写入缓存 * @param key * @param value * @return */ public boolean set(final String key, Object value) { boolean result = false; try { ValueOperations<Serializable, Object> operations =

微信公众号授权获取用户信息

匿名 (未验证) 提交于 2019-12-03 00:42:01
同上一篇文章 同上一篇文章 include "conf.php" ; // 微信端授权登录---生成二维码 $code_url ="https://open.weixin.qq.com/connect/oauth2/authorize?appid= $appid &redirect_uri= $re_url &response_type=code&scope= $scope &state= $state #wechat_redirect" ; include ‘phpqrcode.php‘ ; // 官网下载地址 https://sourceforge.net/projects/phpqrcode/files/ $QR =‘qrcode.png‘; // 二维码图片名称 $errorLevel = "L"; // 定义纠错级别 $size = "4"; // 定义生成内容 QRcode ::png( $code_url , $QR , $errorLevel , $size , 2); // 执行生成图片 echo ‘<img src="‘. $QR .‘">‘; // 输出二维码 注意: 二维码生成目录必须有创建写入文件权限 4、也可是使用用户微信端打开连接 (与 第3 步 执行方式不同)code.php include "conf.php" ; // https://mp

Session 与 Token 的区别

匿名 (未验证) 提交于 2019-12-03 00:30:01
1. 为什么要有session的出现? 答:是由于网络中http协议造成的,因为http本身是无状态协议,这样,无法确定你的本次请求和上次请求是不是你发送的。如果要进行类似论坛登陆相关的操作,就实现不了了。 2. session生成方式? 答:浏览器第一次访问服务器,服务器会创建一个session,然后同时为该session生成一个唯一的会话的key,也就是sessionid,然后,将sessionid及对应的session分别作为key和value保存到缓存中,也可以持久化到数据库中,然后服务器再把sessionid,以cookie的形式发送给客户端。这样浏览器下次再访问时,会直接带着cookie中的sessionid。然后服务器根据sessionid找到对应的session进行匹配; 还有一种是浏览器禁用了cookie或不支持cookie,这种可以通过URL重写的方式发到服务器; 简单来讲,用户访问的时候说他自己是张三,他骗你怎么办? 那就在服务器端保存张三的信息,给他一个id,让他下次用id访问。 3. 为什么会有token的出现? 答:首先,session的存储是需要空间的,其次,session的传递一般都是通过cookie来传递的,或者url重写的方式;而token在服务器是可以不需要存储用户的信息的,而token的传递方式也不限于cookie传递,当然

shiro+jwt整合

匿名 (未验证) 提交于 2019-12-03 00:27:02
特性 完全使用了Shiro的注解配置,保持高度的灵活性。 放弃Cookie,Session,使用JWT进行鉴权,完全实现无状态鉴权。 JWT密钥支持过期时间。 对跨域提供支持 准备工作 在开始本教程之前,请保证已经熟悉以下几点。 Spring Boot 基本语法,至少要懂得 Controller 、 RestController 、 Autowired 等这些基本注释。其实看看官方的Getting-Start教程就差不多了。 JWT (Json Web Token)的基本概念,并且会简单操作JWT的 JAVA SDK 。 Shiro的基本操作,看下官方的 10 Minute Tutorial 即可。 模拟HTTP请求工具,我使用的是PostMan。 简要的说明下我们为什么要用JWT,因为我们要实现完全的前后端分离,所以不可能使用 session , cookie 的方式进行鉴权,所以JWT就被派上了用场,你可以通过一个加密密钥来进行前后端的鉴权。 程序逻辑 我们POST用户名与密码到 /login 进行登入,如果成功返回一个加密token,失败的话直接返回401错误。 之后用户访问每一个需要权限的网址请求必须在 header 中添加 Authorization 字段,例如 Authorization: token , token 为密钥。 后台会进行 token 的校验

14.2 基于令牌的认证

匿名 (未验证) 提交于 2019-12-03 00:22:01
一. 修改app/models.py class User(db.Model): #生成认证令牌 def generate_auth_token(self, expiration): s = Serializer(current_app.config['SECRET_KEY'], expires_in=expiration) return s.dumps({'id': self.id}) #验证认证令牌, 如果令牌可用就返回对应的用户 @staticmethod def verify_auth_token(self, token): s = Serializer(current_app.config['SECRET_KEY']) try: data = s.loads() except: return None return User.query.get(data['id']) 二. 修改app/api_1_0/authentication.py @auth.verify_password def verify_password(email_or_token, password): #如果填的是token字符串 if password = '': g.current_user = User.verify_auth_token(email_or_token) g.token

手把手带你使用JS-SDK自定义微信分享效果

匿名 (未验证) 提交于 2019-12-03 00:22:01
前言 刚进入一家新公司,接到的第一个任务就是需要需要自定义微信分享的效果(自定义缩略图,标题,摘要),一开始真是一脸懵逼,在网上搜索了半天之后大概有了方案。值得注意的是一开始搜索到的解决方案全是调用微信的自带的JS-SDK,然而腾讯是不会让广大吃瓜群众这么轻而易举的调用他们的东西的。微信开发团队已经把调用的权限收回,现在无法直接在页面直接调用JS-SDK了。话不多说,直接上干货。 预期效果 原始的分享效果: 使用微信JS-SDK的分享效果: 可以看出缩略图,标题,摘要样式良好,给用户的体验很好。 准备工作 微信官方开发者文档地址: https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421141115 现在的思路已经很明确了,就是 通过调用微信的JS-SDK实现自定义分享效果 。但是这个调用过程比较繁琐,需要提前准备如下东西: (1)微信服务号一个,并且已经通过了实名认证;    没有实名认证的话,一些接口没有调用权限。 (2)一个ICP备案的域名; 这个域名需要设置为微信公众号后台的JS接口安全域名,否则微信仍然不允许调用它的接口。 这时大家应该就犯难了,这样的话岂不是不能在本地测试,只能部署到生产环境才能测试?不用着急,解决方案告诉大家: 花生壳的内网穿透服务 (收费,20元以内) 花生壳官网: http://hsk

js 前端请求头里传 token

匿名 (未验证) 提交于 2019-12-03 00:15:02
参考: 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对比,如果相同则放下

移动客户端与服务器端安全通信方案

匿名 (未验证) 提交于 2019-12-02 23:43:01
2019独角兽企业重金招聘Python工程师标准>>> 公钥加密私钥解密是密送,保证消息即使公开也只有私钥持有者能读懂。 私钥加密公钥解密是签名,保证消息来源是私钥持有者。 数字签名只能验证数据的完整性,数据本身是否加密不属于数字签名的控制范围 CS C客户端,S服务器端 在客户端软件发布前,客户端保存一个公钥,服务器保存一个私钥;客服端and服务器都保存一个固态key : solid_key 步骤1: 客户端随机生成一个对称密钥,称为动态key : dynamic_key,使用公钥加密内容(dynamic_key+账户+密码+其他需要的参数)。发送给服务器 步骤2: 服务器收到后使用私钥解密,并验证用户和密码是否正确,正确的话保存此dynamic_key在用户的信息中(如果原先已经有了dynamic_key就替换掉旧的); 返回数据:包括客户端登录成功的信息,返回一个Token(令牌,以后见牌如见人)和其他需要返回的参数(传输过程中不携带uid,用token标识用户唯一身份,更安全)。 步骤3: 使用本地保存的dynamic_key解密得到token和其他参数。 安全传输准备工作做完了。 步骤4: 每次传输数据对于加密的内容一律使用dynamic_key进行加密,按照协商好的签名规则进行签名signature(需要dynamic_key参与到签名规则中,以保障安全)