cookie

一. 基础概念 URI - 包括URL和URN 请求和响应报文 请求报文： 响应报文： 二. Http方法 客户端发送的请求报文为第一行，包含了方法字段。 GET - 获取资源，当前网络请求中，绝大部分是GET方法 HEAD - 获取报文首部，主要用于确认URL的有效性和资源更新的日期时间等 POST - 传输实体主体，POST主要用来传输数据，GET主要用来获得资源 三. HTTP状态码 1XX 信息： 100 Continue 表示到目前为止都很正常，客户端可以继续发送请求或忽略这个响应。 2XX 成功：200 OK 204 No Content: 请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。 206 Partial Content: 表示客户端进行了范围请求，响应报文包含由Content-Range指定范围的实体内容。 3XX 重定向：301 Moved permennantly 永久性重定向 302 Found 临时性重定向 304 Not modified 如果请求报文首部欧包含一些条件，例如：If-Match, If-Modified-Since, 如果不满足条件，则服务器会返回304状态码。 具体解释：在客户端向服务端发送http请求时，若返回状态码为304 Not Modifiied

本文由红日安全成员： ruanruan 编写，如有不当，还望斧正。 大家好，我们是红日安全-Web安全攻防小组。此项目是关于Web安全的系列文章分享，还包含一个HTB靶场供大家练习，我们给这个项目起了一个名字叫 Web安全实战 ，希望对想要学习Web安全的朋友们有所帮助。每一篇文章都是于基于漏洞简介-漏洞原理-漏洞危害-测试方法（手工测试，工具测试）-靶场测试（分为PHP靶场、JAVA靶场、Python靶场基本上三种靶场全部涵盖）-实战演练（主要选择相应CMS或者是Vulnhub进行实战演练)，如果对大家有帮助请Star鼓励我们创作更好文章。如果你愿意加入我们，一起完善这个项目，欢迎通过邮件形式（sec-redclub@qq.com）联系我们。 1.会话安全概述 1.1 什么是会话 session会话机制是一种服务器端机制，它使用类似于哈希表（可能还有哈希表）的结构来保存信息。当程序需要为客户端的请求创建会话时，服务器首先检查客户端的请求是否包含会话标识符（称为会话ID）。如果包含它，它先前已为此客户端创建了一个会话。服务器根据会话ID检索会话（无法检索，将创建新会话），如果客户端请求不包含会话ID，则为客户端创建会话并生成与会话关联的会话ID。 session id应该是一个既不重复也不容易被复制的字符串。会话ID将返回给客户端以保存此响应。 1.2常见会话问题 1.2

某厂面试归来，发现自己落伍了！>>> 前言：其实好早就想把CAS的这一套知识整合一下，在工作上也应用到了这块，只是最近才在工作上接触到CAS，所以刚好把这些知识总结一下。这块可能是一个比较大的模块知识点，所以会有多篇文章进行逐一展开，笔者会尽量抽空更新，当然如果文章中存在错误，期望大家指出。 一、初识CAS 首先我们来说一下CAS，CAS全称为Central Authentication Service即中央认证服务，是一个企业多语言单点登录的解决方案，并努力去成为一个身份验证和授权需求的综合平台。 CAS是由Yale大学发起的一个企业级的、开源的项目，旨在为Web应用系统提供一种可靠的单点登录解决方法（属于 Web SSO ）。 CAS协议至少涉及三方：客户端Web浏览器，请求身份验证的Web应用程序和CAS服务器。 它也可能涉及后端服务，如数据库服务器，它没有自己的HTTP接口，但与Web应用程序进行通信。 主要特征： 多种的协议的支持，包括CAS (v1、v2、v3)、SAML(v1、v2)、OAuth、OpenID、OpenID Connect和WS-Federation Passive Requestor 多种认证机制，可以通过JAAS，LDAP，RDBMS，X.509，Radius，SPNEGO，JWT，Remote，Trusted，BASIC，Apache Shiro

1 数据库操作 app.models.py class Foo: xx= 字段（数据库数据类型） 字段类型 字符串 EmailField(CharField)： IPAddressField(Field) URLField(CharField) SlugField(CharField) UUIDField(Field) FilePathField(Field) FileField(Field) ImageField(FileField) CommaSeparatedIntegerField(CharField) 时间类： models.DateTimeField(null=True) 数字： num = models.IntegerField() num = models.FloatField() mum = models.DecimalField(max_digits=30,decimal_places=10) 枚举（Django）： color_list = ( (1,'黑色'), (2,'白色'), (3,'蓝色') ) color = models.IntegerField(choices=color_list) 1. 自己操作： 自己取，自己用 2. 给Django admin使用 应用场景：选项固定 PS: FK选项动态 字段参数 null 数据库中字段是否可以为空

　　session：将会话数据存储在服务器端，并且让数据能够识别浏览器的一种技术。 　　原理图： 　　 　　通过分析原理图： 　　1）会在服务器开辟SESSION会话数据区保存会话数据； 　　2）开辟会话数据区后，将会生成一个唯一的PHPSESSID，并且返回给浏览器作为一个COOKIE数据。 　　 session的使用 -- 基本操作 　　1.要使用session， 必须先开启SESSION机制，使用session_start()函数 #开启session session_start(); 　　 2.增删改查操作 　　我们可以通过操作$_SESSION数组变量来增删改查SESSION数据 　　 　　我们还可以通过配置php.ini中session.auto_start配置项来开启SESSION机制。默认情况下，配置的值为0，表示不自动开启，我们可以修改为1，来开启自动开启SESSION机制。 　　（项目中不推荐使用这种方式,我们并不是所有程序页面都需要使用SESSION数据，什么时候需要就什么时候开启） 　　 $_SESSION变量和SESSION会话数据区的关系 　　 　　 通过分析原理图： 　　1）会话数据存储在服务器的会话数据区中； 　　2）Session_start时，如果没有会话数据区将会开辟一个新的会话数据区；如果有，则找到该数据区，将其中的数据取出来初始化给$

某厂面试归来，发现自己落伍了！>>> HTTP Request header 当今web程序的开发技术真是百家争鸣，ASP.NET, PHP, JSP，Perl, AJAX 等等。 无论Web技术在未来如何发展，理解Web程序之间通信的基本协议相当重要, 因为它让我们理解了Web应用程序的内部工作. 本文将对HTTP协议进行详细的实例讲解，内容较多，希望大家耐心看。也希望对大家的开发工作或者测试工作有所帮助。使用Fiddler工具非常方便地捕获HTTP Request和HTTP Response, 关于Fiddler工具的用法，请看我另一篇博客[ Fiddler 教程 ] 阅读目录 什么是HTTP协议 协议是指计算机通信网络中两台计算机之间进行通信所必须共同遵守的规定或规则，超文本传输协议(HTTP)是一种通信协议，它允许将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器 目前我们使用的是HTTP/1.1 版本 Web服务器，浏览器,代理服务器 当我们打开浏览器，在地址栏中输入URL，然后我们就看到了网页。 原理是怎样的呢？ 实际上我们输入URL后，我们的浏览器给Web服务器发送了一个Request, Web服务器接到Request后进行处理，生成相应的Response，然后发送给浏览器， 浏览器解析Response中的HTML,这样我们就看到了网页，过程如下图所示

某厂面试归来，发现自己落伍了！>>> 1. 什么是Cookie 1.1什么是Cookie？ Cookie 意为“小甜点”，是由 W3C 组织提出，最早由 Netscape 社区发展的一种机制。目前 Cookie 已经成为标准，所有的主流浏览器如 IE、Netscape、Firefox、Opera 等都支持 Cookie。其实Cookie就是一个键和一个值构成的，随着服务器端的响应发送给客户端浏览器。然后客户端浏览器会把Cookie保存起来，当下一次再访问服务器时把Cookie再发送给服务器。 Cookie是HTTP协议的规范之一，它是服务器和客户端之间传输的小数据。 首先由服务器通过响应头把Cookie传输给客户端，客户端会将Cookie保存起来。 当客户端再次请求同一服务器时，客户端会在请求头中添加该服务器保存的Cookie，发送给服务器。 Cookie就是服务器保存在客户端的数据！ Cookie就是一个键值对！！！ 1.2Cookie规范 Cookie大小上限为4KB； 一个服务器最多在客户端浏览器上保存20个Cookie； 一个浏览器最多保存300个Cookie； 注意，不同浏览器之间是不共享Cookie的。也就是说在你使用IE访问服务器时，服务器会把Cookie发给IE，然后由IE保存起来，当你在使用FireFox访问服务器时，不可能把IE保存的Cookie发送给服务器。

cookie与session 会话跟踪技术 在一个会话的多个请求中共享数据，比如： - 请求银行主页； - 请求登录（请求参数是用户名和密码）； - 请求转账（请求参数与转账相关的数据）； - 请求信誉卡还款（请求参数与还款相关的数据） 在这上会话中当前用户信息必须在这个会话中共享的 Cookie Cookie规范 Cookie大小上限为4KB； 一个服务器最多在客户端浏览器上保存20个Cookie； 一个浏览器最多保存300个Cookie； Cookie与HTTP头 Cookie是通过HTTP请求和响应头在客户端和服务器端之间传递的： Cookie：请求头，客户端发送给服务器端； 格式：Cookie: a=A; b=B; c=C。即多个Cookie用分号离开； Set-Cookie：响应头，服务器端发送给客户端； 一个Cookie对象一个Set-Cookie： Set-Cookie: a=A Set-Cookie: b=B Set-Cookie: c=C Cookie的覆盖 如果服务器端发送重复的Cookie那么会覆盖原有的Cookie，例如客户端的第一个请求服务器端发送的Cookie是：Set-Cookie: a=A；第二请求服务器端发送的是：Set-Cookie: a=AA，那么客户端只留下一个Cookie，即：a=AA。 django中的cookie语法 设置cookie：

摘要：实际生产应用中都会采用消息队列的集群方案，如果选择RabbitMQ那么有必要了解下它的集群方案原理 一般来说，如果只是为了学习RabbitMQ或者验证业务工程的正确性那么在本地环境或者测试环境上使用其单实例部署就可以了，但是出于MQ中间件本身的可靠性、并发性、吞吐量和消息堆积能力等问题的考虑，在生产环境上一般都会考虑使用RabbitMQ的集群方案。 对于RabbitMQ这么成熟的消息队列产品来说，搭建它并不难并且也有不少童鞋写过如何搭建RabbitMQ消息队列集群的博文，但可能仍然有童鞋并不了解其背后的原理，这会导致其遇到性能问题时无法对集群进行进一步的调优。本篇主要介绍RabbitMQ集群方案的原理，如何搭建具备负载均衡能力的中小规模RabbitMQ集群，并最后给出生产环境构建一个能够具备高可用、高可靠和高吞吐量的中小规模RabbitMQ集群设计方案。 一、RabbitMQ集群方案的原理 RabbitMQ这款消息队列中间件产品本身是基于Erlang编写，Erlang语言天生具备分布式特性（通过同步Erlang集群各节点的magic cookie来实现）。因此，RabbitMQ天然支持Clustering。这使得RabbitMQ本身不需要像ActiveMQ、Kafka那样通过ZooKeeper分别来实现HA方案和保存集群的元数据。集群是保证可靠性的一种方式

在API接口测试过程中，我们需要传递cookie值作为连接状态的保持，例如登录后状态信息。通过使用Jmeter提供的“HTTP Cookie管理器”来实现。 一般情况下不需要输入什么值，就这样即可，如何想手动传递cookie值。 来源： https://www.cnblogs.com/xiaobaibailongma/p/12512954.html