token

2019年9月17日 由于此次日记篇幅较长blog限制直接使用word发布所以分成几篇来发。 1. 环境准备 10.110.149.172|192.168.111.51 K8s-1 Centos7.5 10.110.149.173|192.168.111.5 K8s-2 Centos7.5 1.1添加记录到hosts文件 [root@k8s-1 ~]# cat /etc/hosts 10.110.149.172 k8s-1 10.110.149.173 k8s-2 两台都添加。 1.2关闭防火墙，不关闭则需要添加k8s以及docker相关通信端口 systemctl stop firewalld systemctl disable firewalld 　　 1.3禁用selinux setenforce 0 vi /etc/selinux/config SELINUX=disabled 1.4 关闭swap swapoff -a 1.5创建/etc/sysctl.d/k8s.conf文件，添加如下内容： net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 net.ipv4.ip_forward = 1 执行命令使其生效 [root@k8s-2 ~]# modprobe br

参考地址： https://www.cnblogs.com/xiaozhang2014/p/7750200.html 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重写的方式

转自： https://www.cnblogs.com/xuxinstyle/p/9675541.html 摘要: Token 是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位 不久前，我在在前后端分离实践中提到了基于 Token 的认证，现在我们稍稍深入一些。 通常情况下，我们在讨论某个技术的时候，都是从问题开始。那么第一个问题： 为什么要用 Token？ 而要回答这个问题很简单——因为它能解决问题！ 可以解决哪些问题呢？ Token 完全由应用管理，所以它可以避开同源策略 Token 可以避免 CSRF 攻击(http://dwz.cn/7joLzx) Token 可以是无状态的，可以在多个服务间共享 Token 是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位。如果这个 Token 在服务端持久化（比如存入数据库），那它就是一个永久的身份令牌。 于是，又一个问题产生了：需要为 Token 设置有效期吗？ 需要设置有效期吗？ 对于这个问题，我们不妨先看两个例子。一个例子是登录密码，一般要求定期改变密码，以防止泄漏

callBack.address=http://www.*****.com/ebox/api/v1/user/callBack qqAddress=https://qyapi.weixin.qq.com qqCodeAddress=https://open.weixin.qq.com corpId=ww1**281b66436**** corpSecret=GJPmBMIpKeL_-0ica48848mK2OMmILikxT******* agentId=10000** scope=snsapi_privateinfo successHtml=http://****/scan_success.html failHtml=http://****/scan_fail.html //微信扫码返回个人信息 public String callback(String code, String state, HttpServletResponse response, HttpServletRequest request) { String corpid = serverConfig.get("corpId"); String corpsecret = serverConfig.get("corpSecret"); String success = serverConfig.get(

目录 概述 一. 秒杀令牌 1.1 原理 1.2 代码实现 二. 秒杀大闸原理 2.1 原理 2.2 代码 三. 队列泄洪 原理 3.2 代码实现 四. 本地OR分布式 概述 上一章节使用了多级缓存+分布式事务管理，即便查询优化，交易优化技术用到极致后，只要外部的流量超过了系统可承载的范围就有拖垮系统的风险。本章通过秒杀令牌，秒杀大闸，队列泄洪等流量削峰技术解决全站的流量高性能运行效率。 项目缺陷： 秒杀接口会被脚本不断调用 秒杀验证逻辑与秒杀下单接口强关联 代码冗余度高 秒杀验证逻辑负责 对系统产生无关的负载 本章目标: 掌握秒杀令牌的原理和使用方式 掌握秒杀大闸的原理和使用方式 掌握队列泄洪的原理和使用方式 一. 秒杀令牌 1.1 原理 秒杀接口需要依靠令牌才能进入 ，对应的秒杀下单接口需要新增一个入参，表示对应前端用户获得传入的一个令牌，只有令牌处于合法之后，才能进入对应的秒杀下单的逻辑 秒杀令牌由秒杀活动模块负责生成 ，交易系统仅仅验证令牌的可靠性，以此来判断对应的秒杀接口是否可以被这次http的request进入 秒杀活动模块对秒杀令牌生成全权处理，逻辑收口 秒杀下单前需要获得秒杀令牌才能开始秒杀 我们生成秒杀令牌并且放到redis 中 在生成令牌的时候把一些基本的风控的能力都搬到这里，让 下单接口只管下单操作，不包含用户验证等 。 1.2 代码实现 * * *

spring boot集成JWT算法 JWT算法，通常用于登录授权和信息交换。这里做简单的demo，具体使用，结合项目情况。 一、.JWT的结构 通俗来讲JWT由 header.payload.signature 三部分组成的字符串，网上有太多帖子介绍这一块了，所以在这里就简单介绍一下就好了。 1.1 header header 由使用的 签名算法 和 令牌 的类型的组成。 1.2 payload payload 说直白一些就类似你的requestBody中的数据。 1.3 signature 如果要生成 signature ，就需要使用jwt自定义配置项中的secret，也就是Hmac算法加密所需要的密钥。 二、使用 2.1导包 <dependency> <groupId>com.auth0</groupId> <artifactId>java-jwt</artifactId> <version>3.4.0</version> </dependency> 2.2 token工具 包含创建token,验证token，解析token. 封装成工具，在项目中直接调用。 import com.auth0.jwt.JWT; import com.auth0.jwt.JWTVerifier; import com.auth0.jwt.algorithms.Algorithm; import

我们在很多网站注册会员时，注册完成后，系统会自动向用户的邮箱发送一封邮件，这封邮件的内容就是一个URL链接，用户需要点击打开这个链接才能激活之前在该网站注册的帐号。激活成功后才能正常使用会员功能。 本文将结合实例，讲解如何使用PHP+Mysql完成注册帐号、发送激活邮件、验证激活帐号、处理URL链接过期的功能。 业务流程 1、用户提交注册信息。 2、写入数据库，此时帐号状态未激活。 3、将用户名密码或其他标识字符加密构造成激活识别码（你也可以叫激活码）。 4、将构造好的激活识别码组成URL发送到用户提交的邮箱。 5、用户登录邮箱并点击URL，进行激活。 6、验证激活识别码，如果正确则激活帐号。 准备数据表 用户信息表中字段Email很重要，它可以用来验证用户、找回密码、甚至对网站方来说可以用来收集用户信息进行Email营销，以下是用户信息表t_user的表结构： CREATE TABLE IF NOT EXISTS `t_user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(30) NOT NULL COMMENT '用户名', `password` varchar(32) NOT NULL COMMENT '密码', `email` varchar(30) NOT NULL COMMENT '邮箱',

1 获取短信发送参数 1.1 登录腾讯云，获取腾讯云短信开发者ID（AppID）和开发者密码（AppKey） 1.2 设置并注册短信模板，获取模板号 1.3 在GeneralTools目录下创建一个Constants.py文件，用于保存运行常量。内容如下： """ 腾讯云短信相关常量设置 """ # 云短信应用 SDK AppID SMS_SDK_APP_ID = '14044453' # 云短信应用 SDK AppKey SMS_APP_KEY = 'e8dfd927c527513f6c6787289b402d' # 注册短信模板ID SMS_REGISTER_TEMPLATE_ID = 391568 # 短信签名，签名参数使用的是`签名内容`，而不是`签名ID`。 SMS_SIGN = '仝恒智能科技温馨提示' # 验证access_token有效时间: s VERIFY_ACCESS_TOKEN_EXPIRES = 300 # 短信验证码的有效期，单位秒 SMS_CODE_REDIS_EXPIRES = 300 # 短信验证码发送间隔，单位秒 SEND_SMS_CODE_INTERVAL = 60 2 获取短信接口 　　获取短信接口的基本思路是：前端先发一个手机号到后端，后端根据手机号生成用户身份令牌access_token，并返回前端。 　　有以下几个问题要处理： 2.1

CSRF即Cross Site Request Forgery（跨站点请求伪造）。 用户在客户端（浏览器）上任何一个操作如提交表单、点击超链接、或者是页面资源的显示都是向服务器发起请求 而得以实现的，所以攻击者往往都是可以通过模拟真实用户的请求来“代替”用户完成操作的。 例如A用户删除id为18的文章的请求地址为：www.eco.com/delete?id=18 那么攻击者可以构造一个html页面，页面中有这样一段代码： *** <img src="http://www.eco.com/delete?id=18" /> *** （当然，用户会看到一张无法显示的图片） 然后引导A用户去访问攻击者的这个html页面，A用户看到了这样一张无法显示的图片，然后回到自己的博客，一看， 自己的id为18的文章不翼而飞了，这，就是跨站点请求伪造。当然了，CSRF肯定不会这么轻易就能成功的，因为大多 数web项目都会对http请求设置一个过滤器，用来验证发出请求的用户身份，使得CSRF的实施变得麻烦起来。 1.浏览器的cookie策略 我应该不止一次地说过，用户注册之后，会设置一个cookie（token）返回给客户端（浏览器），用于之后请求的身份 验证。 浏览器所持有的cookie分为两种，一种是“Session Cookie”、一种是“Third-party Cookie