怎么从0学习接口测试,session机制与JWT机制对比

发布时间:2019-10-06  栏目:编程  评论:0 Comments

今天要给大家分享一下接口测试的相关知识,废话不多说下面直接进入今天的分享。

本文将对比讨论cookie-session与JWT
下面这幅图简单地说明了cookie-session机制与JWT机制

 一、含义

  WebSocket 是一种在单个TCP连接上进行全双工通讯的协议。

   
WebSocket 使得客户端和服务器之间的数据交换变得更加简单,允许服务端主动向客户端推送数据。在WebSocket
API中,浏览器和服务器只需要完成一次握手,两者之间就直接可以创建持久性的连接,并进行双向数据传输。

这是咱们今天要讲的内容目录

图片 1

二、Websocket 产生背景

  很多网站为了实现推送技术,所用的技术都是轮询。

  轮询是在特定的的时间间隔(如每1秒),由浏览器对服务器发出HTTP请求,然后由服务器返回最新的数据给客户端的浏览器。

  传统的模式的缺点,即浏览器需要不断的向服务器发出请求,然而HTTP请求可能包含较长的头部,其中真正有效的数据可能只是很小的一部分,显然这样会浪费很多的带宽等资源。

 

  比较新的技术去做轮询的效果是Comet。

  Comet 是一种用于web的推送技术,能使服务器实时地将更新的信息传送到客户端,而无须客户端发出请求,目前有两种实现方式,长轮询和iframe流。

  长轮询 是在打开一条连接以后保持,等待服务器推送来数据再关闭的方式。

  iframe流 方式是在页面中插入一个隐藏的iframe,利用其src属性在服务器和客户端之间创建一条长链接,服务器向iframe传输数据(通常是HTML,内有负责插入信息的javascript),来实时更新页面。

  Comet技术虽然可以双向通信,但依然需要反复发出请求。

   
Comet中,普遍采用的长链接,也会消耗服务器资源。

 

  Websocket使用和 HTTP 相同的
TCP 端口,可以绕过大多数防火墙的限制。

  默认情况下,Websocket协议使用80端口;运行在TLS之上时,默认使用443端口。

  WebSocket 是独立的、创建在 TCP
上的协议。

  Websocket 通过 HTTP/1.1
协议的101状态码进行握手。

  为了创建Websocket连接,需要通过浏览器发出请求,之后服务器进行回应,这个过程通常称为“握手”(handshaking)。

图片 2

cookie与token机制对比

 三、Python编写Socket服务端

那么什么是接口,接口测试又是什么呢?

基于Cookie的身份验证

基于 Cookie 的身份验证是长期处理用户身份验证的默认的方法。

基于cookie的身份验证是有状态的。这意味着验证的记录或者会话(session)必须同时保存在服务器端和客户端。服务器端需要跟踪记录session并存至数据库,同时前端需要在cookie中保存一个sessionID,作为session的唯一标识符,可看做是session的“身份证”。

举一个栗子,以登录新浪微博为例,当用户来到微博登陆页面,输入用户名和密码之后,点击“登录”后,浏览器将认证信息POST发送给远端的服务器,服务器执行验证逻辑,如果验证通过,则浏览器会跳转到登录用户的微博首页,在登录成功后,服务器如何验证我们对其他受限制页面的访问呢?

因为HTTP协议是无状态的,所以很显然服务器不可能知道我们已经在上一次的HTTP请求中通过了验证。最简单的解决方案就是所有的请求里面都带上用户名和密码,这样虽然可行,但大大加重了服务器的负担(对于每个request都需要到数据库验证),也大大降低了用户体验(每个页面都需要重新输入用户名密码,每个页面都带有登录表单)。既然直接在请求中带上用户名与密码不可行,那么就只有在服务器或客户端保存一些类似的可以代表身份的信息了,所以就有了cookie与session。

 1.客户端
客户端:浏览器(必须要有socket包或者类库,一般自带,个别浏览器没有,所以websocket有局限性)
  <script type="text/javascript">
    # 创建连接
    # 发送消息
    # 接收验证消息 下面的一句话做了上面的三件事
    var socket = new WebSocket("ws://127.0.0.1:8002/xxoo"); 

    # 与服务器端连接成功后,自动执行 
    socket.onopen = function () {

    };

    # 服务器端向客户端发送数据时,自动执行
    socket.onmessage = function (event) {

    };
  </script>

这是我们首先需要搞清楚的东西,如果连接口都不知道,那还谈何做接口测试呢?

cookie

cookie,简而言之就是在客户端(浏览器等)保存一些用户操作的历史信息(当然包括登录信息),并在用户再次访问该站点时浏览器通过HTTP协议将本地cookie内容发送给服务器,从而完成验证,或继续上一步操作。

图片 3

cookie原理图

2.服务端
import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind(('127.0.0.1', 8002))
sock.listen(5)
# 获取客户端socket对象
conn, address = sock.accept()
# 获取客户端的【握手】信息
data = conn.recv(1024)
...
...
...
conn.send('响应【握手】信息')

   请求握手时,浏览器发来的请求信息

GET /chatsocket HTTP/1.1
Host: 127.0.0.1:8002
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://localhost:63342
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: mnwFxiOlctXFN/DeMt1Amg==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

请求和响应的【握手】信息需要遵循规则:

  • 从请求【握手】信息中提取 Sec-WebSocket-Key
  • 利用magic_string 和 Sec-WebSocket-Key
    进行hmac1加密,再进行base64加密
  • 将加密结果响应给客户端

注:magic
string为:258EAFA5-E914-47DA-95CA-C5AB0DC85B11

  
 其中 Sec``-``WebSocket``-``Key: mnwFxiOlctXFN``/``DeMt1Amg``=``= 是浏览器给服务端的一个随机字符串(mnwFxiOlctXFN``/``DeMt1Amg``=``=),服务端需要给这个随机字符串进行加密,然后在给浏览器send数据的时候带上这个加密后的随机字符串,如果浏览器可以解密,那么就是说服务端支持websocket,进而进行建立连接通信。

  提取Sec-WebSocket-Key值并加密:

import socket
import base64
import hashlib

def get_headers(data):
    """
    将请求头格式化成字典
    :param data:
    :return:
    """
    header_dict = {}
    data = str(data, encoding='utf-8')

    for i in data.split('rn'):
        print(i)
    header, body = data.split('rnrn', 1)
    header_list = header.split('rn')
    for i in range(0, len(header_list)):
        if i == 0:
            if len(header_list[i].split(' ')) == 3:
                header_dict['method'], header_dict['url'], header_dict['protocol'] = header_list[i].split(' ')
        else:
            k, v = header_list[i].split(':', 1)
            header_dict[k] = v.strip()
    return header_dict


sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind(('127.0.0.1', 8002))
sock.listen(5)

conn, address = sock.accept()
data = conn.recv(1024)
headers = get_headers(data) # 提取请求头信息
# 对请求头中的sec-websocket-key进行加密
response_tpl = "HTTP/1.1 101 Switching Protocolsrn" 
      "Upgrade:websocketrn" 
      "Connection: Upgradern" 
      "Sec-WebSocket-Accept: %srn" 
      "WebSocket-Location: ws://%s%srnrn"
magic_string = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11'
value = headers['Sec-WebSocket-Key'] + magic_string
ac = base64.b64encode(hashlib.sha1(value.encode('utf-8')).digest())
response_str = response_tpl % (ac.decode('utf-8'), headers['Host'], headers['url'])
# 响应【握手】信息
conn.send(bytes(response_str, encoding='utf-8'))
...
...
...

  此外还有服务端需要实现封包解包的功能,而客户端浏览器的JS已经帮我们实现了封包解包了。

  封包解包详见:武沛齐

网络编程:

  day31–多进程和多线程

  day32–同步锁、死锁递归锁、Event对象

  day33–IO模型

  day34–selectors、队列、生产者和消费者模型

 

图片 4

session

session,会话,简而言之就是在服务器上保存用户操作的历史信息,在用户登录后,服务器存储用户会话的相关信息,并为客户端指定一个访问凭证,如果有客户端凭此凭证发出请求,则在服务端存储的信息中,取出用户相关登录信息,并且使用服务端返回的凭证常存储于Cookie中,也可以改写URL,将id放在url中。这个访问凭证一般来说就是SessionID。

图片 5

session原理

根据百度百科显示,接口测试就是:测试系统组件间接口的一种测试。后面的都是关于接口测试的补充。

小结

session和cookie的目的相同,都是为了克服http协议无状态的缺陷,但完成的方法不同。
session可以通过cookie来完成,在客户端保存session
id,而将用户的其他会话消息保存在服务端的session对象中,与此相对的,cookie需要将所有信息都保存在客户端。因此cookie存在着一定的安全隐患,例如本地cookie中保存的用户名密码被破译,或cookie被其他网站收集(例如:1.
appA主动设置域B cookie,让域B cookie获取;2.
XSS,在appA上通过javascript获取document.cookie,并传递给自己的appB)。

对于新人来说,看到这个解释肯定也是懵懵懂懂,还是不知道到底什么是接口。

基于cookie-session身份验证机制的流程

1.用户输入登录信息
2.服务器验证登录信息是否正确,如果正确就创建一个session,并把session存入数据库
3.服务器端会向客户端返回带有sessionID的cookie
4.在接下来的请求中,服务器将把sessionID与数据库中的相匹配,如果有效则处理该请求
5.如果用户登出app,session会在客户端和服务器端都被销毁

那到底什么是接口呢?

基于token的身份验证

最近几年由于单页app、web
APIs等的兴起,基于token的身份验证开始流行。当我们谈到利用token进行认证,我们一般说的就是利用JSON
Web Tokens(JWTs)进行认证。虽然有不同的方式来实现token, 事实上,JWTs
已成为标准。因此在本文中将互换token与JWTs。

基于token的身份验证是无状态的,服务器不需要记录哪些用户已经登录或者哪些JWTs已经处理。每个发送到服务器的请求都会带上一个token,服务器利用这个token检查确认请求的真实性。

这里可以把token理解成一张演唱会的门票。服务器(演唱会主办方)每次只需要检查你这张门票的有效性,不需要知道你这张门票是在哪里买的,从谁买的,什么时候买的等等。不同等级的门票可以坐的位置不同,同样的,权限不同的用户可以进行的操作也不同。

图片 6

门票

token通常以Bearer { JWT
}的形式附加在已验证的请求头中,但是也可以用post请求体或者问句参数进行传递。

图片 7

JWT

JWT是一种无状态的鉴权机制。将用户登录后的一些信息(比如用户Id)和过期时间等信息存储在一个加密过的字符串中,当服务器收到请求的时候,进行解密并直接使用信息
JWT的组成:使用base64编码描述jwt的头部、使用base64编码的payload,以及加密签名
缺点,服务器无法像session一样方便地管理用户登录状态

这张图对于新手来说就比较友好了,咱们现在的客户端和服务器要建立一种连接。

JWT机制工作流程

1.用户输入登录信息
2.服务器验证登录信息,如果正确就返回一个已签名的token
3.这个token存储在客户端,最常见的是存储在localstorage中,但是也可以存在session
storage和cookie中
4.之后向服务器发送的请求都会带上这个token
5.服务器解码JWT,如果token是有效的则处理这个请求
6.如果用户退出登录,token会在客户端销毁,这一步与服务器无关

参考:
http://blog.leapoahead.com/2015/09/07/user-authentication-with-jwt/
https://auth0.com/blog/cookies-vs-tokens-definitive-guide/
https://my.oschina.net/biezhi/blog/490242#OSC_h2_3

比如说你打开一个网页,服务器要告诉你这个网页有什么东西,首先要建立一个连接,连接

就是一个通道,有了通道之后,客户端就发送一个请求信息给服务端,服务端

收到之后就会给你一个响应信息,告诉你这个页面上到底长什么样子。最后再把这个通道关掉。

这就有点像咱们生活中打电话的情形:也是你先拨号,说话。对方听到,再给你回话。最后挂电话。

接口就是上图“发出请求信息”这一项。

那接口测试测什么呢?

既然“发出请求信息”这项就是接口,那么接口测试测的也就是这块东西。

最常见的接口就是我们的http:/www.
类接口了。只要是问服务器拿到的任何逻辑都是接口。

既然现在我们知道了什么是接口,接口测什么。那下一步自然是——

留下评论

网站地图xml地图