cookie

Writer ：BYSocket（泥沙砖瓦浆木匠） 微 博： BYSocket 豆 瓣： BYSocket FaceBook： BYSocket Twitter ： BYSocket 相继 图解Http协议 和 图解Cookie 之后，中间迷茫期哈，没写了！可是又要告诉你自己明明喜欢写为啥不写了！那就写吧，学到老学到老~ 然后写到老！本系列皆 以图为主 ，力求 简单易懂 ，娓娓道来` 一、Session由来 HTTP的 无状态 ，也就是说，每次请求都是独立的线程。举个例子吧：购物中，你选择了A商品，加入购物车，这就是A线程。然后在选择B商品就是B线程。可是每次线程独立（对容器而言，A、B成了不同的用户），线程A不知道有B，B也不知道A。如何一起付款呢？ 简答来说： 怎么保存同个用户多个请求会话状态呢 ？自然 HTTPS 保证连接是安全的，可以使它与一个会话关联。 问题就在于如何跟踪同一个用户，选择自然很多： 1、 EJB (有状态会话bean保存会话状态) 环境苛刻需要带EJB的J2EE服务器，而不是Tomcat这种Web容器。 2、 数据库 （这貌似万能的。针对数据） 3、就是我们要讲的 HttpSeesion ， 保存跨一个特定用户多个请求的会话状态 。 4、上面说的 HTTPS ,条件太苛刻了。 如图： 二、Session机制 机制，什么用词有点高大上

一个服务器上搭建了多个tomcat或者weblogic，端口不一样，同时启动访问时session丢失。如：A，B两个服务，在浏览器中登录访问A后，当前打开的浏览器上在开一个选项卡访问B服务后，回过来点击访问A时session丢失，需要重新登录A才可以访问。经过资料查找，发现问题是因为： IP相同认为是 同一个 域,接收了B的set-cookie指令,把对应的cookie内容覆盖了,其中包括jsessionid,造成A的 session 丢失。 如果 IP不同 ,则不会发生这个问题 。IP相同的两个session对应的cookie是一样的，而不幸的是sessionID就保存在cookie中，这样先访问A，再访问B的时候，B的sessionid会覆盖A的sessionid。这个事情没办法解决，所以你不要搞两个端口，最好是搞两个IP。原来都是cookie惹的祸，它不会区分端口，造成这多个站点不断的后来的覆盖前面的，从而造成session的丢失。 解决方法： 方法1：将不同的多个应用服务在不同的虚拟主机中，或者映射不同的IP进行部署。 方法2：对应tomcat服务处理方式：修改coocie的名称保证cookie不重复，即jsessionid的不重称，保证ip相同下sessioncookiename域名不同。 1、tomcat5修改方法 在启动项中增加org.apache.catalina

Cookie和会话状态的 工作 原理及Cookie欺骗 session是一种保存上下文信息的机制，它是针对每一个用户的，变量的值保存在服务器端，通过SessionID来区分不同的客户，session是以Cookie或URL重写为基础。默认使用Cookie来实现，系统会创造一个名为JSESSIONID的输出Cookie，或称为"Session Cookie"，以区别Persistent Cookies(通常所说的Cookie).Session Cookie是存储在浏览器中，并不是写在硬盘上的，但是把浏览器的Cookie禁止后，使用response对象的encodeURL或encodeRedirectURL方法编码URL，WEB服务器会采URL重写的方式传递Sessionid，用户就可以在地址栏看到jsessionid=A09JHGHKHU68624309UTY84932之类的字符串。 通常Session Cookie是不能跨窗口使用，当用户新开了一个浏览器进入相同的页面时，系统会赋予用户一个新的SessionID，这样信息共享的目的就达不到，此时可以把SessionID保存在Persistent Cookie中，然后再新的窗口中读出来，就可以得到上一个窗口的SessionID了，这样通过Session Cookie和Persistent Cookie的结合，实现了跨窗口的会话跟踪。

关于 tomcat 和 sessionCookieName 和 SESSION_PARAMETER_NAME 以及 disableURLRewriting 参数 关于 session 和 cookie 参考： http://www.blogjava.net/freeman1984/archive/2011/09/02/357833.html http://www.blogjava.net/freeman1984/archive/2010/09/09/331501.html http://www.blogjava.net/freeman1984/archive/2010/03/30/316901.html tomcat 服务端和客户端通过 sessionCookieName参数 （默认值： jsessionid ）的值来识别 session ，并在此 session 中共享数据。在浏览器首次请求服务的时候， tomcat 服务器会在响应头信息信息里面返回： 告诉浏览器保存cookie名为 JSESSIONID 的cookie，当然此时为会话cookie，此cookie是保存在浏览器当前会话中的。过期时间为当前会话结束时。(当然前提是浏览器要设置为接受第三方cookie) 在下次浏览器请求的时候会将此cookie值返回给服务器，当然cookie的名称同(

存在两种类型的cookie： Session cookies - these are temporary and are erased when you close your browser at the end of your surfing session. The next time you visit that particular site it will not recognise you and will treat you as a completely new visitor as there is nothing in your browser to let the site know that you have visited before 不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。 Persistent cookies - these remain on your hard drive until you erase them or they expire. How long a cookie remains on your browser depends on how long

Cookie和Session的作用： 都是用于存储一些关键数据。 Cookie和Session的存储位置： Cookie储存在客户端，Session储存在服务器 Cookie的产生和销毁以及原理： Cookie由服务器产生，通过HTTP协议发送给客户端。 在协议的响应头中的： Set-Cookie标注了这个cookie的信息 ： 下次如果有cookie带给服务器时，将会在 在协议的请求头中的：Cookie标注了这个cookie的信息： /* * 正值表示 cookie 将在经过该值表示的秒数后过期。注意，该值是 cookie 过期的最大 生存时间， 不是 * cookie的当前生存时间。 负值意味着 cookie 不会被持久存储，将在 Web 浏览器退出时删除。0 值会导致删除cookie */ cookie.setMaxAge(Integer.MAX_VALUE); 删除Cookie注意 ：由于在Http协议中请求发送Cookie的时候只是带有Cookie的名称和值， 但是一个Cookie的唯一标识是Cookie的名称+domain+path。 所以我们在 删除Cookie的时候为了能真正把原来的Cookie的MaxAge改成0的话，就必须要设置这个Cookie的domain和path， 设置的要与之前发送Cookie时一样。也就是说

1. 服务端只创建 cookie字符值： 客户端向服务端发送请求，建立连接。服务端创建 cookie字符值，作为响应头返回。 注意：如果客户端是浏览器，会自动存储这个 Set-Cookie 的值到 浏览器的session 中。如果是脚本，可以手动将该 cookie 保存起来（保存位置可能是session、硬盘或其他位置）。也可以将 cookie 通过响应头再次转发出去 。 2. 客户端（脚本）发送请求，获取 cookie，并维持一个 session中： 由于脚本的 session中，通过类似 session_id的东西 将 session 共享。当脚本发送的请求返回一个携带 set-cookie 的响应时，即将此 set-cookie 中的数据加载到 脚本的 session 中。 那么每次发送请求时，都可以携带此 cookie。（注意：session 是内存的一个区域，并不表示 内存就是 session） 3. 另一种解决方案。客户端（脚本）发送请求，获取 cookie，手动存储到内存、本地硬盘或数据库中： 脚本获取 携带 set-cookie 的响应， 手动将 cookie保存到内存、硬盘或数据库中。这样每次发送请求时，需手动获取 cookie并放置该 cookie 到此请求的 request header 中。 PS：浏览器其实也是维持一个 “智能” session，这个

在Android应用程序中经常会加载一个WebView页，如果需要客户端向WebView传递信息，比如Cookie，也是可以的。 需要应用程序先将Cookie注入进去，打开该网页时，WebView会将加载的url通过http请求传输到服务器。同时，在这次请求中，会将Cookie信息通过http header传递过去。 流程如下： 1、客户端通过以下代码设置cookie public static void synCookies(Context context, String url) { CookieSyncManager.createInstance(context); CookieManager cookieManager = CookieManager.getInstance(); cookieManager.setCookie(url, "uid=1243432"); CookieSyncManager.getInstance().sync(); } 2、CookieManager会将这个Cookie存入该应用程序/data/data/databases/目录下的webviewCookiesChromium.db数据库的cookies表中 3、打开网页，WebView从数据库中读取该cookie值，放到http请求的头部，传递到服务器 4

会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。 Cookie通过在客户端记录信息确定用户身份，Session通过服务器端记录信息确定用户身份。 1.1 Cookie机制 在程序中，会话跟踪是很重要的事情。理论上， 一个用户的所有请求操作都应该属于同一个会话 ，而另一个用户的所有请求操作则应该属于另一个会话，二者不能混淆。例如，用户A在超市购买的任何商品都应该放在A的购物车内，不论是用户A什么时间购买的，这都是属于同一个会话的，不能放入用户B或用户C的购物车内，这不属于同一个会话。 而Web应用程序是使用HTTP协议传输数据的。 HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话 。即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了。要跟踪该会话，必须引入一种机制。 Cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。 1.1.1 什么是cookie 由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就 给客户端们颁发一个通行证吧

前言 之前有一位购买我课程的童鞋利用最新的IdentityServer4版本即对应.NET Core 3.x，发布到生产环境在学习，结果出了一些问题，此前我并未过多关注IdentityServer4升级到3.x版本，所以在此做一个基本的总结，或许能对出现相同问题的童鞋能提供一点帮助。 IdentityServer4迁移至3.x版本问题 针对将.NET Core 2.x升级到3.x就不用再多讲，请参看官方迁移文档（ https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.1&tabs=visual-studio ），我们只介绍对于对于配置IdentityServer4方面的更改变化 .NET Core Identity 对于Identity里面的上下文【IdentityDbContext】需要额外下载包【Microsoft.AspNetCore.Identity.EntityFrameworkCore】 OIDC配置 针对如下客户端OIDC的配置，需要下载包【Microsoft.AspNetCore.Authentication.OpenIdConnect】 授权中间件配置 针对客户端认证和授权配置，需要如下配置授权中间件（认证和授权无先后顺序） 迁移类生成