
session 是为了保持服务器与客户端的会话状态,在用户登录后,服务器端生成一个sessionID传给客户端;之后的每次会话,客户端只需要传这个sessionID即可不用重新登录,保持在线状态。故服务器端需要保存所有在线的sessionID,从而影响服务器性能! sessionID是存在cookie中的。
token 是为了解决服务器压力,用户登录成功后,服务器端生产token(钥匙和锁)通过 cookie或请求头的方式 传给客户端,再次请求时带上token即可,无状态(服务端通过算法验证钥匙和锁是否正确)。
总之 ,就是两种鉴权方式,通过sessionID或者token,服务器来判断是否是某用户登录后的其他请求。
其他:
2、一个用户在一次会话(打开浏览器,访问服务器,直到浏览器关闭,称为一次会话,严格的说,一次会话应该是依赖 session 的生成机制)上就是一个session_id。
3、每次登录时,总会产生一个token或者sessionID,生成这个的目的是为了每次 *** 作其他接口的时候,会判断当前用户是否登录。
1)cookie的处理
准备:两个接口:一个登录、一个充值
登录接口
充值接口:会失败
1、添加:HTTPCookie管理器,放到最上面。
2、再次运行:就会充值成功。
登录时会有set_Cookie存在
1、添加后置处理器>>>正则表达式提取器
设置:
2、添加:调试取样器
运行结果:已经拿到cookie
3、添加:右击线程组>>添加>>配置元件>>HTTPCookie管理器
设置:
4、添加:JSESSIONID:${正则表达式提取器提取到的变量名}
域:
路径:
5、查看运行结果:
2)token的处理
查询用户信息需要先登录,在查询用户信息的时候需要携带token。
1、在登录接口下面使用正则表达式提取器获取token
登录接口响应数据中返回token。
配置提取器:
2、添加:调试取样器,运行后查看是否可以获取到
3、添加HTTP信息头管理器
运用相关资料
应用使用的cookies符合兼容性规范的话,JMeter的标准cookies是可以自动管理的.如果应用没有指明cookies版本,同时又使用了特殊符号,JMeter调用的httpclient就不能正确管理这种非标cookies了.(从应用的cookies兼容性来说是有问题的.)
这种有问题的应用,我最近也遇到一个,不考虑应用的兼容性问题的话,需要让JMeter能准确管理这样的cookies,就要改写标准cookies的SPEC或者写一个定制的也可以,改写的目标可以定位在commons httpclient.
一下是网上搜索的关于httpclient支持的cookies说明:
[code]
以下Cookies标准,HttpClient3.1可以支持。
RFC2109
RFC2109是W3C组织第一次推出的官方Cookies标准。理论上,所有使用版本1Cookies的服务端都应该使用此标准。HttpClient已经将此标准设定为默认。
遗憾的是,许多服务端不正确的实现了标准或者仍然使用Netscape标准。所有有时感到此标准太多于严格。
RFC2109是HttpClient使用的默认Cookies协议。
RFC2965
RFC2965定义了版本2并且尝试去弥补在版本1中Cookie的RFC2109标准的缺点。RFC2965是,并规定RFC2965最终取代RFC2109.
发送RFC2965标准Cookies的服务端,将会使用Set-Cookie2 header添加到Set-Cookie Header信心中,RFC2965 Cookies是区分端口的。
Netscape标准
Netscape是最原始的Cookies规范,同时也是RFC2109的基础。尽管如此,还是在很多重要的方面与RFC2109不同,可能需要特定服务器才可以兼容。
Browser Compatibility
这种兼容性设计要求是适应尽可能多的不同的服务器,尽管不是完全按照标准来实现的。如果你遇到了解析Cookies的问题,你就可能要用到这一个规范。
有太多的web站点是用CGI脚本去实现的,而导致只有将所有的Cookies都放入Request header才可以正常的工作。这种情况下最好设置http.protocol.single-cookie-header参数为true。
Ignore Cookies
此规格忽略所有Cookie 。被用来防止HttpClient接受和发送的Cookie。
[/code]
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)