cookie

二者的定义： 当你在浏览网站的时候，WEB 服务器会先送一小小资料放在你的计算机上，Cookie 会帮你在网站上所打的文字或是一些选择， 都纪录下来。当下次你再光临同一个网站，WEB 服务器会先看看有没有它上次留下的 Cookie 资料，有的话，就会依据 Cookie 里的内容来判断使用者，送出特定的网页内容给你。 Cookie 的使用很普遍，许多有提供个人化服务的网站，都是利用 Cookie 来辨认使用者，以方便送出使用者量身定做的内容，像是 Web 接口的免费 email 网站，都要用到 Cookie。 具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。 同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制 来达到保存标识的目的，但实际上它还有其他选择。 cookie机制。正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示 浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。而cookie的使用 是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围

csrf，跨站请求伪造，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法 攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。 如下：其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户。 CSRF攻击攻击原理及过程如下： 1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A； 　　2.在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A； 3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B； 4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A； 　　5. 浏览器在接收到这些攻击性代码后，根据网站 B 的请求，在用户不知情的情况下携带 Cookie 信息，向网站 A 发出请求。网站 A 并不知道该请求其实是由 B 发起的，所以会根据用户 C 的 Cookie 信息以 C 的权限处理该请求，导致来自网站 B 的恶意代码被执行。 讲的挺详细的： https://www.freebuf.com/articles/web

其实token与session的问题是一种时间与空间的博弈问题， session是空间换时间，而token是时间换空间。 一、发展史 　　很久很久以前，Web 基本上就是文档的浏览而已， 既然是浏览，作为服务器， 不需要记录谁在某一段时间里都浏览了什么文档，每次请求都是一个新的HTTP协议， 就是请求加响应， 尤其是我不用记住是谁刚刚发了HTTP请求， 每个请求对我来说都是全新的。这段时间很嗨皮。 　　但是随着交互式Web应用的兴起，像在线购物网站，需要登录的网站等等，马上就面临一个问题，那就是要管理会话，必须记住哪些人登录系统， 哪些人往自己的购物车中放商品， 也就是说我必须把每个人区分开，这就是一个不小的挑战，因为HTTP请求是无状态的，所以想出的办法就是给大家发一个会话标识(session id), 说白了就是一个随机的字串，每个人收到的都不一样， 每次大家向我发起HTTP请求的时候，把这个字符串给一并捎过来， 这样我就能区分开谁是谁了 　　这样大家很嗨皮了，可是服务器就不嗨皮了，每个人只需要保存自己的session id，而服务器要保存所有人的session id ！ 如果访问服务器多了， 就得由成千上万，甚至几十万个。 这对服务器说是一个巨大的开销 ， 严重的限制了服务器扩展能力， 比如说我用两个机器组成了一个集群， 小F通过机器A登录了系统， 那session

// 旧版 HttpClient httpClient = new DefaultHttpClient(); // execute get/post/put or whatever httpClient.doGetPostPutOrWhatever(); // get cookieStore CookieStore cookieStore = httpClient.getCookieStore(); // get Cookies List<Cookie> cookies = cookieStore.getCookies(); // process... // 新版 /* init client */ HttpClient http = null; CookieStore httpCookieStore = new BasicCookieStore(); http = HttpClientBuilder.create().setDefaultCookieStore(httpCookieStore).build(); /* do stuff */ HttpGet httpRequest = new HttpGet("http://stackoverflow.com/"); HttpResponse httpResponse = null; try {httpResponse =

原文: QQ浏览器兼容模式下Cookie失效 导致的NetCore Cookie认证失效 最近在写NetCore项目采用的是NetCore的Cookie认证。结果偶然发现QQ浏览器登录不好用。 这里先需要了解一下set-cookie中的SameSite属性 导致原因 首先Fiddler 4查看一下两次请求 第一次Post进行登录 返回302重定向到站点首页并带回Cookie （一切正常） 但是看第二条http请求，返回又是302 ，查看相关信息，请求时Cookie 根本没带入 到此基本知道整个登录失败是因为Cookie没有带入请求头。 解决方案： NetCore Cookie认证下如何解决 经过一系列测试后发现是因为我们响应的Cookie里面有samesite属性 影响了QQ浏览器兼容Cookie带入（也许是个浏览器Bug吧） 好下面说如何解决此问题在NetCore认证中我们如何取消掉此属性， 自定义Cookie如何解决 其实不光我们的认证Cookie 其他Cookie也一样 只要我们在NetCore中指定了Cooke的CookieOptions，不设置SameSite的情况下默认为SameSiteMode.Lax 此时在QQ浏览器兼容模式 你的Cookie就不会带入请求 context.Response.Cookies.Append("test-SameSite",

原文: asp.net core session丢失问题排查 最近公司采用asp.net core的站点在外测环境中，总是发现存在session丢失的情况。排查了好久，客户端.AspNetCore.Session的cookie未丢失，session的分布式缓存采用的redis主从复制也未发现问题，也想用cookie的变通解决方案，但是没解决根本问题，总是觉得如鱼梗在喉的不爽。后来在排查的过程中，发现同一个客户端通过nginx居然有时候会负载到不同的网站服务器上，检查过nginx，是通过ip_hash进行转发的啊，迷惑不解之际，公司的运维一语破的，原来公司是采用双线路由器的。于是猜测，是否因为存储cookie加密的key存在不同服务器上所导致。 打开微软的Session的源码，先查看SessionMiddleware中间件的代码，其中有以下的关键源码： var cookieValue = context.Request.Cookies[_options.CookieName]; var sessionKey = CookieProtection.Unprotect(_dataProtector, cookieValue, _logger); if (string.IsNullOrWhiteSpace(sessionKey) || sessionKey.Length !=

PHP在设计的时候已经预定义了9个超全局变量、8个魔术变量和13魔术方法，这些变量和函数可以在脚本的任何地方不用声明就可以使 用。 在PHP开发会频繁的使用这些变量和函数，这些变量和函数可以方便的帮我们解决很多问题。下面详细的讲解下PHP中的超全局变量、魔术变量和魔术方法。 PHP超全局变量（9个） 　　$GLOBALS　　储存全局作用域中的变量 　　$_SERVER　　获取服务器相关信息 　　$_REQUEST　　获取POST和GET请求的参数 　　$_POST　　获取表单的POST请求参数 　　$_GET　　获取表单的GET请求参数 　　$_FILES　　获取上传文件的的变量 　　$_ENV　　获取服务器端环境变量的数组 　　$_COOKIE　　 浏览器cookie的操作 　　　　　　　　　　设置cookie:setcookie(name, value, expire, path, domain); 　　　　　　　　　　获取cookie：$_COOKIE["user"]; 　　　　　　　　　　删除cookie：setcookie("user", "", time()-3600);//设置过期时间 　　$_SESSION　　服务端session的操作 　　　　　　　　　　使用session前一定要session_start()启动session 　　　　　　　　　

Cookie和Session 为什么需要Cookie和Session 这就需要从HTTP状态协议 的无状态性开始说起了。 无状态协议是指协议对事物处理没有记忆能力 ，简单说来就是每个HTTP请求都是独立的，每个请求都只处理自己的信息，不与其他的请求发生关系。 HTTP是超本文传输协议，顾名思义，这个协议支持超文本的传输。 什么是超文本？简单来说就是使用HTML编写的页面。 HTTP协议的目的是在于支持超文本的传输，也就是资源的传输，客户端浏览器向HTTP服务器发送请求，继而HTTP服务器将相信资源发回给客户端这样一个过程中，无论对于客户端还是服务器，都没有必要记录这个过程 。所以HTTP协议被设计为无状态的协议是符合其要求的。 在早期的互联网，这就够了，但是随着互联网的发展，简单的资源传输不能满足用户的需求了，用户需要更丰富的需求。这时，cookie和session登场了，它们被设计用来为用户保存状态。 Cookie cookie是客户端保持状态的解决方案 ，第一次连接后， 服务器发送资源的同时也发送了一些cookie到用户浏览器，它们是保存在本地的一小块数据 ，在浏览器下次向同一个服务器再次发送请求的时候，cookie会被放在请求头中发送到服务器。 这是访问Google的请求头信息，可以看到有一个Cookie字段，后面是一串很长的字符。 这是Google在本地存储的cookie

目录 spring security实现记住我下次自动登录功能 一、原理分析 二、实现方式 2.1 简单实现方式 2.2 数据库实现方式 三、区分是密码登录还是rememberme登录 spring security实现记住我下次自动登录功能 上一篇: spring security的BCryptPasswordEncoder加密和对密码验证的原理 一、原理分析 第一次登陆时，如果用户勾选了readme选项,登陆成功后springsecurity会生成一个cookie返回给浏览器端，浏览器下次访问时如果携带了这个cookie,springsecurity就会放行这次访问。 二、实现方式 2.1 简单实现方式 (1) 在springsecurity的配置文件中,http节点下增加一个remember-me配置 <security:http auto-config="true" use-expressions="false"> <!-- 配置链接地址，表示任意路径都需要ROLE_USER权限,这里可以配置 一个逗号隔开的角色列表--> <security:intercept-url pattern="/**" access="ROLE_USER"/> <!--自定义登录页面--> <security:form-login login-page="/login.html" login

Cookie Cookie的由来 Http协议是无状态的 无状态的意思是每次都是独立的请求存在，它的执行情况和结果与前面的请求和后面的请求都无直接关系，它不会受到前面的请求响应情况直接影响，也不会直接影响后面的请求响应情况。 一句话来说，人生若只如初见，对服务器来说，每一次的请求都是全新的 状态可以理解为客户端和服务端在某次会话中产生的数据，那无状态的就以为这些数据不会得到保存。会话中的数据又是我们需要保存的，也就是说’保存状态‘。因此诞生cookie 什么是cookie cookie具体指的是一小段信息，它是服务器发送给存储在浏览器的一组键值对，下次访问服务器时浏览器会自动携带这些键值对，以便服务器提取有用信息 保存在浏览器本地上的一组组键值对 cookie的原理 cookie的工作原理：由服务器产生内容，浏览器收到请求后保存到本地；当浏览器再次访问时，浏览器会自动携带上cookie，这样服务端就可以通过cookie的内容来判断这个是谁了 查看cookie 使用Chrome浏览器，打开开发者工具。 cookie特性 由服务器让浏览器进行设置的 访问相应的网站携带对应的cookie Django操作cookie 1. 设置cookie # 响应对象设置set_cookie response.set_cookie('is_login','1') response.set_cookie