token

AspNetCore3.1_Secutiry源码解析_6_Authentication_OpenIdConnect

橙三吉。 提交于 2020-03-26 11:16:43
title: "AspNetCore3.1_Secutiry源码解析_6_Authentication_OpenIdConnect" date: 2020-03-25T21:33:12+08:00 draft: false 系列文章目录 AspNetCore3.1_Secutiry源码解析_1_目录 AspNetCore3.1_Secutiry源码解析_2_Authentication_核心流程 AspNetCore3.1_Secutiry源码解析_3_Authentication_Cookies AspNetCore3.1_Secutiry源码解析_4_Authentication_JwtBear AspNetCore3.1_Secutiry源码解析_5_Authentication_OAuth AspNetCore3.1_Secutiry源码解析_6_Authentication_OpenIdConnect AspNetCore3.1_Secutiry源码解析_7_Authentication_其他 AspNetCore3.1_Secutiry源码解析_8_Authorization_核心项目 AspNetCore3.1_Secutiry源码解析_9_Authorization_Policy oidc简介 oidc是基于oauth2.0的上层协议。 OAuth有点像卖电影票的

H5微信授权登录

妖精的绣舞 提交于 2020-03-26 11:15:17
这里介绍H5微信授权登录,采用了微信公众号授权原理,是oauth2的登录授权方式,简单的来讲,就是用户通过手机微信确认登录之后,微信方会返回一个授权码code给回第三方(接入方),这个授权码code一次有效期,且有效时间比较短;第三方通过此code去调用微信接口获取token,token的有效期也比较短;第三步通过token再去调用微信开发平台接口,获取微信个人用户信息(昵称、头像地址、openid、unionid、地区……)。 申请测试账号: https://mp.weixin.qq.com/debug/cgi-bin/sandbox?t=sandbox/login 在微信公众号请求用户网页授权之前,开发者需要先到公众平台官网中的“开发 - 接口权限 - 网页服务 - 网页帐号 - 网页授权获取用户基本信息”的配置选项中,修改授权回调域名。请注意,这里填写的是域名(是一个字符串),而不是URL,因此请勿加 http:// 等协议头; 前提先关注微信测试公众号,然后即可以在微信开发者工具的公众号网页调试模式,地址栏进行输入授权登录; 参考链接(请在微信客户端中打开此链接体验): scope为snsapi_base https://open.weixin.qq.com/connect/oauth2/authorize?appid=wx520c15f417810387&redirect

kubernetes 新加入节点

岁酱吖の 提交于 2020-03-25 16:45:03
一、kubernetes 对于已经搭建好的集群,新加入节点 1.新的node 节点需要装好:docker kubelet kube-proxy 2.kubeadm reset 二、加入集群 1.在主节点查询jion的token kubeadm token list 若token 创建时间超过24H,token失效,重新创建有效的token kubeadm token create 2.新的node 加入集群 kubeadm join ${Mater_ip}:6443 --token 40dup1.urffu06eu0u1hzy3 --discovery-token-ca-cert-hash kubectl get node 3.当某个节点node_x故障,需要临时处理 可以先不让这个节点再调度任务,排除故障后,再恢复节点 kubectl cordon node_x kubectl drain node_x 平滑的将该node_x 上面的业务pod 迁移到另外安全的node 节点上。 维护好node_x节点后,恢复该node_x节点可调度 kubectl uncordon node_x 来源: 51CTO 作者: Mart_sea 链接: https://blog.51cto.com/13396187/2481651

python多线程完成模拟支付请求

本秂侑毒 提交于 2020-03-25 09:27:50
import asyncioimport sysfrom queue import Queuesys.path.append("../")from tool.__init__ import *from tool.decorator_token import *import timefrom threading import Thread,Lockclass doWeChatNotify(BaseTest): def __init__(self): super().__init__() self.limit_num=100 #查询记录条数 self.WeChatNotify_sql='''select order_id,order_sn from fw_order where `status`=0 and course_id=1569 ORDER BY create_time desc limit %d ;'''%(self.limit_num) self.fwh_test_api=fwh_test_api self.data = self.my_op.sql_operation_fwh(self.WeChatNotify_sql) self.fwh_order_dict = {} self.que = Queue() @token_fwh#验证token有效性 def get

浅析Cookie、Session以及Token机制

最后都变了- 提交于 2020-03-25 02:41:56
一、前言   这篇博客来谈一谈 Web 应用中广泛使用的 Cookie 、 Session 以及 Token 机制,它们在 Web 应用中起着至关重要的作用,同时也是面试中的高频考点。这篇博客我主要来介绍一下这三种东西的相关概念和它们实现的原理,以及它们之间的区别。 二、正文   2.1 为什么需要它们   首先来说第一个问题,我们为什么需要这三样东西?稍微了解过 HTTP 的应该知道, HTTP 协议是一个无状态的协议。什么是无状态?就是说, HTTP 服务器对每一条请求一视同仁,不会记录每一条请求的状态,比如是由谁发出的,所有的请求对它来说都是陌生的。就算你连续向同一个服务器发送两条请求,对它来说,这也是两条完全不相关的请求。但是,我们会发现这样一个现象,当我们在一个网站登录后,服务器就好像认识了我们,我们发送出去的请求,都能得到与我们自身相关的响应。比如说我们在淘宝登录后,点击购物车,就能够看见我们自己加入的商品;而如果我们没有登录,就会被拦截下来,跳转到登录页面。这是为什么呢?不是说 HTTP 是无状态的吗。其实,这就是依赖于上面的三种机制。   2.2 Cookie    Cookie 其实就是浏览器保存在电脑中的一些文本数据,它们都是 key-value 形式的,其中包含了我们自己以及服务器的一些信息。当我们向一个服务器发送请求时,服务器可能希望我们在本地保存一些数据

AspNetCore3.1_Secutiry源码解析_5_Authentication_OAuth

泪湿孤枕 提交于 2020-03-25 01:58:26
title: "AspNetCore3.1_Secutiry源码解析_5_Authentication_OAuth" date: 2020-03-24T23:27:45+08:00 draft: false 系列文章目录 AspNetCore3.1_Secutiry源码解析_1_目录 AspNetCore3.1_Secutiry源码解析_2_Authentication_核心流程 AspNetCore3.1_Secutiry源码解析_3_Authentication_Cookies AspNetCore3.1_Secutiry源码解析_4_Authentication_JwtBear AspNetCore3.1_Secutiry源码解析_5_Authentication_OAuth( https://holdengong.com/aspnetcore3.1_secutiry源码解析_5_authentication_oauth ) AspNetCore3.1_Secutiry源码解析_6_Authentication_OpenIdConnect AspNetCore3.1_Secutiry源码解析_7_Authentication_其他 AspNetCore3.1_Secutiry源码解析_8_Authorization_核心项目 AspNetCore3.1

kubeadm部署kubernetes v1.17.4 单master节点

不羁岁月 提交于 2020-03-24 17:46:35
环境说明: #操作系统:centos7 #docker版本:19.03.8 #kubernetes版本:v1.17.4 #K8S master 节点IP:192.168.3.62 #K8S worker节点IP:192.168.2.186 #网络插件:flannel #kube-proxy网络转发: ipvs #kubernetes源:使用阿里云源 #service-cidr:10.96.0.0/16 #pod-network-cidr:10.244.0.0/16 部署准备: 操作在所有节点进行 修改内核参数: 关闭swap vim /etc/sysctl.conf vm.swappiness=0 net.ipv4.ip_forward = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-arptables=1 sysctl -p 临时生效 swapoff -a && sysctl -w vm.swappiness=0 修改 fstab 不在挂载 swap vi /etc/fstab /dev/mapper/centos-swap swap swap defaults 0 0 安装docker yum-config

vue -- axios封装和api接口管理

℡╲_俬逩灬. 提交于 2020-03-23 10:34:39
axios封装【https://juejin.im/post/5b55c118f265da0f6f1aa354】 在vue项目中,一般和后台数据交互获取,使用的是axios库,它是基于promise的http库,可运行到浏览器和node.js中。 axios的特性: 拦截请求和响应; 取消请求; 转换JSON 客户端防御XSRF等 安装: npm install axios; //安装axios 引入:【可以在项目的src中,新建一个request文件夹,然后里面新建两个文件,http.js和api.js。http.js文件用来封装axios,api.js文件用来统一管理我们的接口。】 //在http.js中引入axios import axios from 'axios'; //引入axios import QS from 'qs'; //引入qs模块,用来序列化post类型的数据 环境的切换:【项目中有开发环境、测试环境和生产环境,我们通过node的环境变量来匹配我们的默认接口url前缀。】 //环境的切换 if(process.env.NODE_ENV == 'development'){ axios.defaults.baseURL = 'https://www.baidu.com';//开发地址 } else if (process.env.NODE_ENV ==

自动化接口测试之Postman

不羁岁月 提交于 2020-03-23 10:30:41
我们先思考一下,如果需要达到自动化接口测试的效果,那么我们在基本的模拟请求上还需要做哪些呢? 以下我粗略概括为 3 个问题(欢迎更多补充与建议): 如何判断接口是否请求成功 如何进行接口批量、定期测试 如何处理依赖接口问题(比如商品下单的接口必须要求先登录) 所以,接下来就主要分为 3 个部分进行介绍,以分别解决这 3 个问题。 一、接口结果判断 首先 , 既然是自动化测试 , 那么我们肯定需要 工具 (Postman) 或者代码能帮我们直接判断结果是否符合预期。那么在接口测试上,大体就两个思路: 判断请求返回的 code 是否符合预期 判断请求返回的内容中是否包含预期的内容(关键字) 接下来我们看看如何利用 Postman 来解决上述的问题: 1、功能区 在 Postman 中相关的功能在非常显眼的地方, Tests 功能的使用需要我们有一定的编程语言基础,目前支持的脚本语言即为 JavaScript 。 但比较好的一点是,我们不需要再去考虑上下文问题以及运行环境的问题 ,也就是说我们只需要在这边完成结果逻辑判断的代码块即可。而 Postman 还为我们提供了一些常用的代码模板,在 Tests 面板右边的 SNIPPETS 功能区中,所以对 JavaScript 不大了解问题也不大。代码编写相关将在下文进行具体介绍。 2、脚本相关 先看上图的代码部分,我们可以发现

AspNetCore3.1_Secutiry源码解析_4_Authentication_JwtBear

不打扰是莪最后的温柔 提交于 2020-03-23 01:48:12
title: "AspNetCore3.1_Secutiry源码解析_4_Authentication_JwtBear" date: 2020-03-22T16:29:29+08:00 draft: false 系列文章目录 AspNetCore3.1_Secutiry源码解析_1_目录 AspNetCore3.1_Secutiry源码解析_2_Authentication_核心流程 AspNetCore3.1_Secutiry源码解析_3_Authentication_Cookies AspNetCore3.1_Secutiry源码解析_4_Authentication_JwtBear AspNetCore3.1_Secutiry源码解析_5_Authentication_OAuth AspNetCore3.1_Secutiry源码解析_6_Authentication_OpenIdConnect AspNetCore3.1_Secutiry源码解析_7_Authentication_其他 AspNetCore3.1_Secutiry源码解析_8_Authorization_核心项目 AspNetCore3.1_Secutiry源码解析_9_Authorization_Policy JwtBear简介 首先回想一下Cookie认证