cookie时效无限延长方案

cookie,时效,无限,延长,方案 · 浏览次数 : 347

小编点评

**作者:京东科技 刘清洁1、痛点(*)自动化测试有2种形式,接口自动化和UI自动化。** **a、如何才能绕过登录,实现从前端到后端的自动化执行** 可以使用短时间有效性的 cookie 来绕过登录验证。可以通过将 cookie 的有效时间设置到会话级别,从而在浏览器关闭时立即失效。 **b、面对复杂的登录验证无法直接自动获取到cookie,需要人工操作登录,而cookie又有时效,不能长久使用本方案将有效解决以上问题,在面对复杂登录验证及有cookie时效的模式下,可以将短暂时效的cookie改为长久有效,真正意义上实现UI自动化和依赖cookie鉴权的接口自动化。 **3、过期时间查看方式打开浏览器,并转到您希望查看 cookie 的网站** 在开发者工具的“调试工具”选项卡中,单击“存储”按钮。在左侧的“网站数据”列表中,单击“Cookies”。在右侧的“值”列表中,查看每个 cookie 的“Expires”或“Max-Age”字段。 **4、cookie机制客户端发送一个请求到服务器 --》 服务器发送一个HttpResponse响应到客户端,其中包含Set-Cookie的头部 --》 客户端保存cookie,之后向服务器发送请求时,HttpRequest请求中会包含一个Cookie的头部 --》服务器返回响应数据时效限制:每个cookie都有时效,默认的有效期是,会话级别:就是当浏览器关闭,那么cookie立即销毁,但是我们也可以在存储的时候手动设置cookie的过期时间 **5、cookie时效无限延长方案(*)5-1、前提a. 登录节点有验证机制,例如短信验证码、图形识别、滑块等校验;b. cookie有时效,超过时效则需要重新登录;c. 同一个账号不会在多个平台退出或登录5-2、实现原理此方案是通过一个微服务提供接口,供自动化调用,通过传递账号,返回永久cookie,将此步嵌入到自动化流程中,替代登录并获取cookie的节点,并将cookie的时效永久延长,并不会时效,以保证后续自动化流程永久循环正常执行** **5-3、核心流程步骤步骤1:先手工登录,从header中获取cookie,将此cookie和时效值保存在微服务平台(一个账号只需一次手工登录,后续永久不需要操作登录)。** **5-2、实现原理此方案是通过一个微服务提供接口,供自动化调用,通过传递账号,返回永久cookie,将此步嵌入到自动化流程中,替代登录并获取cookie的节点,并将cookie的时效永久延长,并不会时效,以保证后续自动化流程永久循环正常执行** **6、落地案例** 目前通过下方方案,已实现了cookie一次配置,长久使用的目的。实践效果对比之前:ui自动化和http接口自动化执行时经常出现cookie过期,需要手工重新登录,并在自动化平台上更新cookie,比较繁琐,且影响凌晨自动执行成功率现在:使用上面方案后,只需手工在cookie微服务平台上配置一次cookie,以后不再需要更新cookie

正文

作者:京东科技 刘清洁

1、痛点(*)

自动化测试有2种形式,接口自动化和UI自动化。而UI自动化经常会被登录节点堵塞,例如验证码、图形、滑块等,尽管有些方式可以识别图形和定位滑块位置,但成功率都不高,无法真正意义上实现自动化执行;而http接口的自动化测试前置如果依赖cookie,也无法实现自动化执行。

a、怎么样才能绕过登录,实现从前端到后端的自动化执行

b、面对复杂的登录验证无法直接自动获取到cookie,需要人工操作登录,而cookie又有时效,不能长久使用

本方案将有效解决以上问题,在面对复杂的登录验证及有cookie时效的模式下,可以将短暂时效的cookie改为长久有效,真正意义上实现UI自动化和依赖cookie鉴权的接口自动化。

2、什么是cookie

cookie称之为会话跟踪技术,是一个很小的文本文件,是浏览器储存在用户的机器上的。Cookie是纯文本,没有可执行代码。储存一些服务器需要的信息,每次请求站点,会发送相应的cookie,这些cookie可以用来辨别用户身份信息等作用

3、过期时间查看方式

打开浏览器,并转到您希望查看 cookie 的网站。

按 F12 键打开浏览器的开发者工具。

在开发者工具的“调试工具”选项卡中,单击“存储”按钮。

在左侧的“网站数据”列表中,单击“Cookies”。

在右侧的“值”列表中,查看每个 cookie 的“Expires”或“Max-Age”字段。这些字段显示 cookie 的过期时间。

4、cookie机制

客户端发送一个请求到服务器 --》 服务器发送一个HttpResponse响应到客户端,其中包含Set-Cookie的头部 --》 客户端保存cookie,之后向服务器发送请求时,HttpRequest请求中会包含一个Cookie的头部 --》服务器返回响应数据

时效限制:每个cookie都有时效,默认的有效期是,会话级别:就是当浏览器关闭,那么cookie立即销毁,但是我们也可以在存储的时候手动设置cookie的过期时间

5、cookie时效无限延长方案(*)

5-1、前提

a. 登录节点有验证机制,例如短信验证码、图形识别、滑块等校验;

b. cookie有时效,超过时效则需要重新登录;

c. 同一个账号不会在多个平台退出或登录

5-2、实现原理

此方案是通过一个微服务提供接口,供自动化调用,通过传递账号,返回永久cookie,将此步嵌入到自动化流程中,替代登录并获取cookie的节点,并将cookie的时效永久延长,并不会时效,以保证后续自动化流程永久循环正常执行。

5-3、核心流程步骤

步骤1:先手工登录,从header中获取cookie,将此cookie和时效值保存在微服务平台(一个账号只需一次手工登录,后续永久不需要操作登录)。

步骤2:微服务平台将此账号、cookie、时效值、关联的业务接口进行持久化存储,并跟进时效值计算出轮询时长,并触发轮询任务执行,任务中将携带此cookie去调用业务接口,保持长会话,并hold进程等待,在轮询时长到达时,继续执行任务执行,再次hold进程等待,持续循环,以保证次cookie的会话永久保持住。

步骤3:自动化任务执行前会调用微服务接口,通过账号获取到永久cookie,携带此cookie执行后续自动化任务。

6、落地案例

目前通过下方方案,已实现了cookie一次配置,长久使用的目的。

实践效果对比

之前:ui自动化和http接口自动化执行时经常出现cookie过期,需要手工重新登录,并在自动化平台上更新cookie,比较繁琐,且影响凌晨自动执行成功率

现在:使用上面方案后,只需手工在cookie微服务平台上配置一次cookie,以后不再需要更新cookie

7、专利描述

https://zhuanli.tianyancha.com/811840799431036187d34680d5b10ae3

与cookie时效无限延长方案相似的内容:

cookie时效无限延长方案

自动化测试有2种形式,接口自动化和UI自动化。而UI自动化经常会被登录节点堵塞,例如验证码、图形、滑块等,尽管有些方式可以识别图形和定位滑块位置,但成功率都不高,无法真正意义上实现自动化执行;而http接口的自动化测试前置如果依赖cookie,也无法实现自动化执行。

前端如何对cookie加密

在前端对 Cookie 进行加密时,你可以使用加密算法对 Cookie 的值进行加密,然后再将加密后的值存储到 Cookie 中。常用的加密算法包括对称加密算法(如 AES)和非对称加密算法(如 RSA)。以下是一个简单的示例,演示如何在前端使用 AES 对 Cookie 进行加密: // 引入加密

【转帖】nginx变量使用方法详解-8

https://www.diewufeiyang.com/post/582.html 与 $arg_XXX 类似,我们在 (二) 中提到过的内建变量 $cookie_XXX 变量也会在名为 XXX 的 cookie 不存在时返回特殊值“没找到”: Bash location /test { cont

鸿蒙HarmonyOS实战-Web组件(Cookie及数据存储)

前言 Cookie是一种存储在用户计算机上的小文本文件,用于在用户访问网站时存储和提取信息。它由网站服务器发送到用户的浏览器,并存储在用户的计算机上。每当用户访问该网站时,浏览器将发送该Cookie回服务器,以用于识别用户和存储用户的首选项和其他信息。 Cookie可以用于跟踪用户的行为,例如记

[转帖]RabbitMQ erlang.cookie解惑

https://www.cnblogs.com/xgtx/articles/6068392.html 在搭建RabbitMQ集群的时候往往会因为.erlang.cookie而报各种错误,网上查资料也会经常说.erlang.cookie会在$home下,或者在/var/lib/rabbitmq下,到底

[BJDCTF2020]Cookie is so stable

打开题目是三个页面 Hint中有提示 flag页面有个输入框抓包观察cookie发现多了一user就是回显内容 然后猜测有模板注入漏洞就开始尝试 '时代少年团队长乌萨奇的颜值一直被质疑'的文章内容 如何判断对方的模板? 常见模板有Smarty、Mako、Twig、Jinja2、Eval、Flask、

深入探讨安全验证:OAuth2.0、Cookie与Session、JWT令牌、SSO与开放授权平台设计

这篇文章讨论了认证和授权的概念,并探讨了设计权限认证框架的原则。它还比较了Cookie和Session的区别,并探讨了处理分布式部署时的Session保存问题。此外,文章还介绍了CSRF攻击及其防范方法,以及OAuth2.0、JWT令牌和SSO的概念。最后,文章提出了设计开放授权平台时需要考虑的因素。

[转帖]全连接队列和半连接队列

半连接队列 syn-cookie打开的情况下 服务器接收到第一次握手的消息后,不会立刻将相关信息放进半连接队列,而是根据对面发过来的报文计算自己的SYN初始序列号。 利用下面几个部分: 客户端IP、客户端端口号、服务端IP、服务端端口号,这4个部分计算一个哈希值一个缓慢增长的时间戳t客户端发来的SY

nginx中一个请求匹配到多个location时的优先级问题,马失前蹄了

背景 为什么讲这么小的一个问题呢?因为今天在进行系统上线的时候遇到了这个问题。 这次的上线动作还是比较大的,由于组织架构拆分,某个接入层服务需要在两个部门各自独立部署,以避免频繁的跨部门沟通,提升该接入层服务的变更效率。 该接入层服务之前是使用cookie + 内存session机制的,这次要独立部

[转帖]Cookies 和 Session的区别

一、共同之处: cookie和session都是用来跟踪浏览器用户身份的会话方式。 二、工作原理: 1.Cookie的工作原理 (1)浏览器端第一次发送请求到服务器端 (2)服务器端创建Cookie,该Cookie中包含用户的信息,然后将该Cookie发送到浏览器端 (3)浏览器端再次访问服务器端时