LoadRunner11 实现token的解析与认证

问题描述:

1、当前系统通过token实现系统安全验证,登录成功后,token被存储在返回体中(reaponse body),后续服务器请求时,需要将该token添加到请求头部(request header)中;

2、当前web服务访问时,强制限制必须适应谷歌浏览器;

3、Lr录制脚本时,需要通过代理的方式录制,但录制结果回放时,总是提示错误:

Error -26630: HTTP Status-Code=401 (Unauthorized) for ***;

##解决办法:

1、打开录制的脚本,默认为脚本[Script]模式,需要切换到树[Tree]视图;

2、在左侧列表汇总找到系统登录请求[login]步骤,在右侧找到[Response Body]步骤,返回数据为json格式,如下:

{

“code” : 200,

“message” : “操作成功”,

“name”:admin,

“token”:“3E78453A8B17F3A4EBA1B19D7F4D22D4-NKifP2w4mhXI9vl1YZynupr”

}

3、选择[token]的值域内容,右键选择[Create Parameter];切换到[Script]视图,看到如下Lr新增内容:

//Correlation comment - Do not change!Original value=‘3E78453A8B17F3A4EBA1B19D7F4D22D4-NKifP2w4mhXI9vl1YZynupr‘ Name =‘CorrelationParameter_1‘

// Lr自动添加的参数解析算法

web_reg_save_param_ex(

"ParamName=CorrelationParameter_1",

"LB=\"",

"RB=\",",

SEARCH_FILTERS,

"Scope=Body",

"RequestUrl=*/login*",

LAST);

// 修订[token]解析算法:

// 按照默认Lr解析[token]的算法,无法获取到真正的token,需要修改如下:

web_reg_save_param_ex(

"ParamName=my_token", // 修改参数名,便于记忆

"LB=\"token\":\"", // 修改 token 值解析算法

"RB=\",",

SEARCH_FILTERS,

"Scope=Body",

"RequestUrl=*/login*",

LAST);

// 登录模块-此部分为Lr自动生成部分,不需要修改;

web_custom_request("login",

"URL=http://192.168.0.1:8080/test/login",

"Method=POST",

"Resource=0",

"RecContentType=application/json",

"Referer=http://192.168.0.1:8080/test/index.html",

"Snapshot=t6.inf",

"Mode=HTML",

"EncType=application/json",

"Body={\"userName\":\"admin\",\"password\":\"123456\"}",

LAST);

//新增将解析出的token自动添加在每一个后续请求的头部(request header):

web_add_auto_header("Authorization", "{my_token}");

// 后续的web请求,自动添加token认证:

web_url(***);

web_submit_data(***);

至此完成token解析与认证。

说明:非原创,忘记文章链接了

原文地址:https://www.cnblogs.com/amy720/p/12187015.html

时间: 2024-11-01 11:54:20

LoadRunner11 实现token的解析与认证的相关文章

jcSQL词法分析器对字符串token的解析

上星期写完词法分析器的时候,曾遇上一个无关紧要却X疼的问题.毕竟是第一次完整地写整个语言的编译器(暂且这么叫着吧,解释器更靠谱),由于经验不足,在字符串解析这一块驻足了两天才解决掉,这里记录下来供以后参考.哦对了,之所以想自己手写词法分析器,并不是我不知道有自动工具可以自动生成,而是我不会用,嗯,果然高冷. 词法分析器的作用简而言之就是将语言分割成一个一个独立的词法单元(单词),并赋予一定的类型.(如果不了解其作用,建议参考词法分析) 例如: a = 3 ; 我们就可以将其分课程一个个有意义的单

Linux Token Auth 一次性密码认证

Linux Token Auth 一次性密码认证 http://netkiller.github.io/journal/token.html Mr. Neo Chen (netkiller), 陈景峰(BG7NYT) 中国广东省深圳市龙华新区民治街道溪山美地 518131 +86 13113668890 +86 755 29812080 <[email protected]> Mr. 曾 祥建, Android 手机端开发 中国广东省深圳市南山区 +86 18665871161 <[em

Spring Security 解析(二) —— 认证过程

Spring Security 解析(二) -- 认证过程 ??在学习Spring Cloud 时,遇到了授权服务oauth 相关内容时,总是一知半解,因此决定先把Spring Security .Spring Security Oauth2 等权限.认证相关的内容.原理及设计学习并整理一遍.本系列文章就是在学习的过程中加强印象和理解所撰写的,如有侵权请告知. 项目环境: JDK1.8 Spring boot 2.x Spring Security 5.x 一.@EnableGlobalAuth

基于Token的WEB后台认证机制

几种常用的认证机制 HTTP Basic Auth HTTP Basic Auth简单点说明就是每次请求API时都提供用户的username和password,简言之,Basic Auth是配合RESTful API 使用的最简单的认证方式,只需提供用户名密码即可,但由于有把用户名密码暴露给第三方客户端的风险,在生产环境下被使用的越来越少.因此,在开发对外开放的RESTful API时,尽量避免采用HTTP Basic Auth OAuth OAuth(开放授权)是一个开放的授权标准,允许用户让

django-rest-framework之 json web token方式完成用户认证

json web token的介绍:https://blog.csdn.net/kevin_lcq/article/details/74846723 1. 安装 $ pip install djangorestframework-jwt 2. 添加配置 REST_FRAMEWORK = { 'DEFAULT_AUTHENTICATION_CLASSES': ( 'rest_framework.authentication.BasicAuthentication', 'rest_framework

JWT 认证 签发与校验token 多方式登陆 自定义认证规则反爬 admin密文显示

一 .认证方法比较 1.认证规则图 django 前后端不分离 csrf认证 drf 前后端分离 禁用csrf 2. 认证规则演变图 数据库session认证:低效 缓存认证:高效 jwt认证:高效 3. 认证比较 """ 1)session存储token,需要数据库参与,耗服务器资源.低效 2)缓存存token,需要缓存参与,高效,不易集群 3)客户端存token,服务器存签发与交易token的算法,高效,易集群 """ 缓存认证: 不易并发

Laravel5.7+Json Web Token实现接口用户认证

废话:记得在我刚实习那会,在某家公司写PHP,主要对接'某赞' '某盟' '微信'的接口,回想起来写代码真的是一把梭啊,能跑起来就行那种,从不考虑程序性能,比如时间复杂度和空间复杂度. ok,经过我努力学习,我现在要装逼了(其实没什么技术含量),讲一下接口服务的开发. 1.有人说用Session判断用户的状态就行了.这里我提出几个问题,如下: 如果做了负载均衡,上游服务器有几台,请问Session 怎么存?(不要说存在redis共享出来,或者nginx配置ip_hash) Session的存储机

权限认证 cookie VS token

权限认证 cookie VS token 我前公司的应用都是 token 授权的,现公司都是维护一个 session 确认登录状态的.那么我在这掰扯掰扯这两种权限认证的方方面面. 工作流程 先说 cookie cookie 登录是有状态的,服务端维护一个 session 客户端维护一个 cookie,cookie 只保留 sessionID 服务端要保存并跟踪所有活动的 session 如下: 输入用户名密码登陆. 服务器拿到身份并验证后生成一个 session 存到数据库. 把 session

rest_framework-00-规范-APIview源码解析-认证

rest_framework-00-规范-APIview源码解析-认证 规范 支付宝: 接口开发 订单api----order 方式1:缺点:如果有10张表,则需要40个url. urls.py views.py 缺点:如果有10张表,则需要40个url.    接下来就出现了resrful 规范,比较简洁 方式2:resrful 规范(建议)  url简洁了,只有一条. 1. 根据method不同做不同的操作,示例:基于FBV: urls.py views.py 2. 根据method不同做不