sessioncookie(session共享有什么方案么)

1. sessioncookie，session共享有什么方案么？

1. 网站交互体验升级作为网友的我们，每天都会使用浏览器来逛各种网站，来满足日常的工作生活需求。

现在的交互体验还是很丝滑的，但早期并非如此，而是一锤子买卖。

1.1 无状态的 HTTP 协议无状态的 HTTP 协议是什么鬼？

HTTP 无状态协议，是指协议对于业务处理没有记忆能力，之前做了啥完全记不住。每次请求都是完全独立互不影响的，没有任何上下文信息。

缺少状态意味着如果后续处理需要前面的信息，则它必须重传关键信息，这样可能导致每次连接传送的数据量增大。

如果大家没明白，可以想一下《夏洛特烦恼》里面的桥段：

大概明白了吧，假如一直用这种原生无状态的 HTTP 协议，我们每换一个页面可能就得重新登录一次，那还玩个球。

所以必须要解决 HTTP 协议的无状态，提升网站的交互体验，否则星辰大海是去不了的。

1.2 解决之道整个事情交互的双方只有客户端和服务端，所以必然要在这两个当事者身上下手。

客户端来买单

客户端每次请求时把自己必要的信息封装发送给服务端，服务端查收处理一下就行。

服务端来买单

客户端第一次请求之后，服务端就开始做记录，然后客户端在后续请求中只需要将最基本最少的信息发过来就行，不需要太多信息了。

2. Cookie方案Cookie 总是保存在客户端中。按在客户端中的存储位置，可分为内存 Cookie 和硬盘Cookie。

内存 Cookie 由浏览器维护，保存在内存中，浏览器关闭后就消失了，其存在时间是短暂的。硬盘 Cookie 保存在硬盘里，有一个过期时间。除非用户手工清理或到了过期时间，硬盘Cookie不会被删除，其存在时间是长期的。

2.1 Cookie 定义和作用HTTP Cookie（也叫 Web Cookie 或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据。它会在浏览器下次向同一服务器再发起请求时，被携带并发送到服务器上。

通常 Cookie 用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的HTTP协议记录稳定的状态信息成为了可能。

Cookie 主要用于以下三个方面：

会话状态管理（如用户登录状态、购物车等其它需要记录的信息）个性化设置（如用户自定义设置、主题等）浏览器行为跟踪（如跟踪分析用户行为等）2.2 服务端创建 Cookie当服务器收到 HTTP 请求时，服务器可以在响应头里面添加一个 Set-Cookie 选项。

浏览器收到响应后通常会保存下 Cookie，之后对该服务器每一次请求中都通过 Cookie 请求头部将 Cookie 信息发送给服务器。另外，Cookie 的过期时间、域、路径、有效期、适用站点都可以根据需要来指定。

2.3 B/S 的 Cookie 交互

服务器使用 Set-Cookie 响应头部向用户浏览器发送 Cookie信息。

一个简单的 Cookie 可能像这样：

Set-Cookie: <cookie名>=<cookie值> HTTP/1.0 200 OKContent-type: text/htmlSet-Cookie: yummy_cookie=chocoSet-Cookie: tasty_cookie=strawberry

客户端对该服务器发起的每一次新请求，浏览器都会将之前保存的Cookie信息通过 Cookie 请求头部再发送给服务器。

GET /sample_page.html HTTP/1.1Host: www.example.orgCookie: yummy_cookie=choco; tasty_cookie=strawberry

我来访问下淘宝网，抓个包看看这个真实的过程：

2.4 存在的问题Cookie 常用来标记用户或授权会话，被浏览器发出之后可能被劫持，被用于非法行为，可能导致授权用户的会话受到攻击，因此存在安全问题。

还有一种情况就是跨站请求伪造 CSRF，简单来说比如你在登录银行网站的同时，登录了一个钓鱼网站，在钓鱼网站进行某些操作时可能会获取银行网站相关的Cookie信息，向银行网站发起转账等非法行为。

跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF，是一种挟制用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法。跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。

跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。

由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了 Web 中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

不过这种情况有很多解决方法，特别对于银行这类金融性质的站点，用户的任何敏感操作都需要确认，并且敏感信息的 Cookie 只能拥有较短的生命周期。

同时 Cookie 有容量和数量的限制，每次都要发送很多信息带来额外的流量消耗、复杂的行为 Cookie 无法满足要求。

特别注意：以上存在的问题只是 Cookie 被用于实现交互状态时存在的问题，但并不是说 Cookie 本身的问题。

试想一下：菜刀可以用来做菜，也可以被用来从事某些暴力行为，你能说菜刀应该被废除吗？

3. Session 方案3.1 Session 机制的概念如果说 Cookie 是客户端行为，那么 Session 就是服务端行为。

Cookie 机制在最初和服务端完成交互后，保持状态所需的信息都将存储在客户端，后续直接读取发送给服务端进行交互。

Session 代表服务器与浏览器的一次会话过程，并且完全由服务端掌控，实现分配ID、会话信息存储、会话检索等功能。

Session 机制将用户的所有活动信息、上下文信息、登录信息等都存储在服务端，只是生成一个唯一标识 ID 发送给客户端，后续的交互将没有重复的用户信息传输，取而代之的是唯一标识 ID，暂且称之为 Session-ID 吧。

3.2 简单的交互流程当客户端第一次请求 session 对象时候，服务器会为客户端创建一个 session，并将通过特殊算法算出一个 session 的 ID，用来标识该 session 对象；当浏览器下次请求别的资源的时候，浏览器会将 sessionID 放置到请求头中，服务器接收到请求后解析得到 sessionID，服务器找到该 id 的 session 来确定请求方的身份和一些上下文信息。3.3 Session 的实现方式首先明确一点，Session 和 Cookie 没有直接的关系。可以认为 Cookie 只是实现 Session 机制的一种方法途径而已，没有 Cookie 还可以用别的方法。

Session和Cookie的关系就像加班和加班费的关系，看似关系很密切，实际上没啥关系。

Session 的实现主要两种方式：Cookie 与 URL 重写，而 Cookie 是首选方式。因为各种现代浏览器都默认开通 Cookie 功能，但是每种浏览器也都有允许 Cookie 失效的设置，因此对于 Session 机制来说还需要一个备胎。

将会话标识号以参数形式附加在超链接的URL地址后面的技术称为 URL 重写

原始 URL：

http://taobao.com/getitem?name=baymax&action=buy

重写后的 URL:

http://taobao.com/getitem?sessionid=1wui87htentg&?name=baymax&action=buy

3.4 存在的问题

由于 Session 信息是存储在服务端的，因此如果用户量很大的场景，Session 信息占用的空间就不容忽视。

对于大型网站必然是集群化&分布式的服务器配置。如果 Session 信息是存储在本地的，那么由于负载均衡的作用，原来请求机器 A 并且存储了 Session 信息，下一次请求可能到了机器 B，此时机器 B 上并没有 Session 信息。

这种情况下要么在 B 机器重复创建造成浪费，要么引入高可用的 Session 集群方案，引入 Session 代理实现信息共享，要么实现定制化哈希到集群 A，这样做其实就有些复杂了

4. Token 方案Token 是令牌的意思，由服务端生成并发放给客户端，是一种具有时效性的验证身份的手段。

Token 避免了 Session 机制带来的海量信息存储问题，也避免了 Cookie 机制的一些安全性问题，在现代移动互联网场景、跨域访问等场景有广泛的用途。

4.1 简单的交互流程

客户端将用户的账号和密码提交给服务器；服务器对其进行校验，通过则生成一个 token 值返回给客户端，作为后续的请求交互身份令牌；客户端拿到服务端返回的 token 值后，可将其保存在本地，以后每次请求服务器时都携带该 token，提交给服务器进行身份校验；服务器接收到请求后，解析关键信息，再根据相同的加密算法、密钥、用户参数生成 sign 与客户端的 sign 进行对比，一致则通过，否则拒绝服务；验证通过之后，服务端就可以根据该 Token 中的 uid 获取对应的用户信息，进行业务请求的响应。4.2 Token 的设计思想以 JSON Web Token（JWT）为例，Token主要由三部分组成：

Header 头部信息：记录了使用的加密算法信息；Payload 净荷信息：记录了用户信息和过期时间等；Signature 签名信息：根据 header 中的加密算法和 payload 中的用户信息以及密钥key来生成，是服务端验证服务端的重要依据。

header 和 payload 的信息不做加密，只做一般的 base64 编码。服务端收到 token 后剥离出 header 和 payload 获取算法、用户、过期时间等信息，然后根据自己的加密密钥来生成 sign，并与客户端传来的 sign 进行一致性对比，来确定客户端的身份合法性。

这样就实现了用 CPU 加解密的时间换取存储空间，同时服务端密钥的重要性就显而易见，一旦泄露整个机制就崩塌了，这个时候就需要考虑 HTTPS 了。

4.3 Token 方案的特点Token 可以跨站共享，实现单点登录；Token 机制无需太多存储空间。Token 包含了用户的信息，只需在客户端存储状态信息即可，对于服务端的扩展性很好；Token 机制的安全性依赖于服务端加密算法和密钥的安全性；Token 机制也不是万金油。5. 总结Cookie、Session、Token 这三者是不同发展阶段的产物，并且各有优缺点，三者也没有明显的对立关系，反而常常结伴出现，这也是容易被混淆的原因。

Cookie 侧重于信息的存储，主要是客户端行为。Session 和 Token 侧重于身份验证，主要是服务端行为。

三者方案在很多场景都还有生命力，了解场景才能选择合适的方案。

本文分享自华为云社区《Cookie、Session、Token 背后的故事-云社区-华为云》，作者：龙哥手记。

sessioncookie(session共享有什么方案么)

2. cookie和session都可以存取任何类型数据？

cookie和session可以存取任何类型的数据，因为存入形式cookie是以字符串的形式，session是以文本域的形式存在。

3. 简述ApplicationSessionCookie三者的相同点与不同点？

相同点：都能用来储存数据

不同点：

1.Application 储存在服务端，没有时间限制，服务器关闭即销毁（前提是自己没写销毁方法）

2.Session 储存在服务端，客户端（浏览器）关闭即销毁(若长时间不使用且浏览器未关闭的情况下，默认自动销毁时间为20分钟)

3.Cookie 储存在客户端，由用户自己销毁

4. localstorage和cookie之间的区别？

他们之间的区别主要体现在如下几个方面

1. 存储数据的大小：

Cookie：早期的Cookie规范中，每个站点的Cookie总量不能超过4KB，但随着Cookie的升级版——Cookie2和RFC 2965的出现，Cookie的大小得到了大幅提升，单个Cookie可以达到约50KB，但不同浏览器可能对单个Cookie大小限制不同。

LocalStorage：LocalStorage的总容量可以达到约5MB，比Cookie大得多。

SessionStorage：SessionStorage的大小通常与LocalStorage一样大，约为5MB。

2. 存储数据的生命周期：

Cookie：Cookie数据会随着浏览器关闭而消失，除非设置了持久化选项（如使用expires或max-age）。

LocalStorage：LocalStorage中的数据在没有手动删除的情况下会一直保存，即使浏览器关闭或电脑重启。

SessionStorage：SessionStorage中的数据仅在当前浏览器窗口或标签页的生命周期内存在，关闭窗口或标签页后，其中的数据将被清除。

3. 作用域：

Cookie：Cookie的作用域是站点的，即它们仅在创建它们的站点中可用。这意味着其他站点无法访问或读取它们。

LocalStorage和SessionStorage：LocalStorage和SessionStorage的作用域是域的，也就是说在同一站点的所有标签页和窗口中都可以访问它们。但是，不同站点的数据是隔离的，一个站点的数据无法被其他站点访问。

4. 线程安全：

Cookie：Cookie不是线程安全的，可以在浏览器的任何线程中读取或写入。

LocalStorage和SessionStorage：LocalStorage和SessionStorage是线程安全的，只能在主线程中访问它们。这意味着在Web Worker或WebSockets等非主线程中不能直接访问它们。

5. Web Worker和SessionStorage的使用：

当使用Web Worker时，由于它们运行在独立于主线程的单独线程上，因此不能直接访问SessionStorage。但是，可以使用IndexedDB或Web SQL Database来在Web Worker中存储数据。

6. 安全性：

Cookie：由于Cookie可以包含敏感信息（如用户凭据），因此需要小心保护它们免受未经授权的访问。可以使用安全标志来保护Cookie数据，使其仅在HTTPS连接中传输。

LocalStorage和SessionStorage：LocalStorage和SessionStorage本身不提供任何内置的安全性。它们中的数据可以被任何脚本读取和修改。因此，不建议在其中存储敏感信息。如果需要保护数据的安全性，应使用加密或其他安全措施来保护存储的数据。

7. 跨域访问：

Cookie：由于安全原因，通常不允许跨域访问其他站点的Cookie。但是，可以使用CORS（跨源资源共享）策略来允许跨域访问某些资源。

LocalStorage和SessionStorage：LocalStorage和SessionStorage本身不具有跨域访问的限制。任何站点的脚本都可以读取和修改它们中的数据。如果需要限制跨域访问，应在服务器端实施相应的CORS策略或其他安全措施。

5. 如何清除jsp页面缓存cookiesession？

1、Session是一种保持浏览器和服务器之间连接状态的机制。实际上是靠cookie机制产生的一种方式。

2、cookie分为内存cookie和普通cookie，浏览器和服务端保持session就是靠内存cookie，内存cookie不往硬盘里写，普通cookie会落盘。如果你完全禁止了cookie就不能用session了，你删除了还能用的（楼主可以自己做实验）。

3、你关闭页签这要看不同浏览器的机制了。要看这个浏览器的该也签关闭后，是否内存cookie跟着一起清掉，这个你可以再上网查详细的资料。

6. 如何解决跨域问题？

一、什么是跨域？1.什么是同源策略及其限制内容？同源策略是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSRF等攻击。所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。同源策略限制内容有：

Cookie、LocalStorage、IndexedDB 等存储性内容DOM 节点AJAX 请求发送后，结果被浏览器拦截了但是有三个标签是允许跨域加载资源：

<img src=XXX><link href=XXX><script src=XXX>2.常见跨域场景当协议、子域名、主域名、端口号中任意一个不相同时，都算作不同域。不同域之间相互请求资源，就算作“跨域”。

特别说明两点：

第一：如果是协议和端口造成的跨域问题“前台”是无能为力的。

第二：在跨域问题上，仅仅是通过“URL的首部”来识别而不会根据域名对应的IP地址是否相同来判断。“URL的首部”可以理解为“协议, 域名和端口必须匹配”。

这里你或许有个疑问：请求跨域了，那么请求到底发出去没有？

跨域并不是请求发不出去，请求能发出去，服务端能收到请求并正常返回结果，只是结果被浏览器拦截了。你可能会疑问明明通过表单的方式可以发起跨域请求，为什么 Ajax 就不会?因为归根结底，跨域是为了阻止用户读取到另一个域名下的内容，Ajax 可以获取响应，浏览器认为这不安全，所以拦截了响应。但是表单并不会获取新的内容，所以可以发起跨域请求。同时也说明了跨域并不能完全阻止 CSRF，因为请求毕竟是发出去了。

二、跨域解决方案1.jsonp1) JSONP原理利用 <script> 标签没有跨域限制的漏洞，网页可以得到从其他来源动态产生的 JSON 数据。JSONP请求一定需要对方的服务器做支持才可以。

2) JSONP和AJAX对比JSONP和AJAX相同，都是客户端向服务器端发送请求，从服务器端获取数据的方式。但AJAX属于同源策略，JSONP属于非同源策略（跨域请求）

3) JSONP优缺点JSONP优点是简单兼容性好，可用于解决主流浏览器的跨域数据访问的问题。缺点是仅支持get方法具有局限性,不安全可能会遭受XSS攻击。

4) JSONP的实现流程声明一个回调函数，其函数名(如show)当做参数值，要传递给跨域请求数据的服务器，函数形参为要获取目标数据(服务器返回的data)。创建一个<script>标签，把那个跨域的API数据接口地址，赋值给script的src,还要在这个地址中向服务器传递该函数名（可以通过问号传参:?callback=show）。服务器接收到请求后，需要进行特殊的处理：把传递进来的函数名和它需要给你的数据拼接成一个字符串,例如：传递进去的函数名是show，它准备好的数据是show('我不爱你')。最后服务器把准备的数据通过HTTP协议返回给客户端，客户端再调用执行之前声明的回调函数（show），对返回的数据进行操作。在开发中可能会遇到多个 JSONP 请求的回调函数名是相同的，这时候就需要自己封装一个 JSONP函数。

上面这段代码相当于向http://localhost:3000/say?wd=Iloveyou&callback=show这个地址请求数据，然后后台返回show('我不爱你')，最后会运行show()这个函数，打印出'我不爱你'

5) jQuery的jsonp形式JSONP都是GET和异步请求的，不存在其他的请求方式和同步请求，且jQuery默认就会给JSONP的请求清除缓存。

2.corsCORS 需要浏览器和后端同时支持。IE 8 和 9 需要通过 XDomainRequest 来实现。

浏览器会自动进行 CORS 通信，实现 CORS 通信的关键是后端。只要后端实现了 CORS，就实现了跨域。

服务端设置Access-Control-Allow-Origin 就可以开启 CORS。该属性表示哪些域名可以访问资源，如果设置通配符则表示所有网站都可以访问资源。

虽然设置 CORS 和前端没什么关系，但是通过这种方式解决跨域问题的话，会在发送请求时出现两种情况，分别为简单请求和复杂请求。

1) 简单请求只要同时满足以下两大条件，就属于简单请求

条件1：使用下列方法之一：

GETHEADPOST条件2：Content-Type 的值仅限于下列三者之一：

text/plainmultipart/form-dataapplication/x-www-form-urlencoded请求中的任意 XMLHttpRequestUpload 对象均没有注册任何事件监听器； XMLHttpRequestUpload 对象可以使用 XMLHttpRequest.upload 属性访问。

2) 复杂请求不符合以上条件的请求就肯定是复杂请求了。复杂请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求,该请求是 option 方法的，通过该请求来知道服务端是否允许跨域请求。

我们用PUT向后台请求时，属于复杂请求，后台需做如下配置：

接下来我们看下一个完整复杂请求的例子，并且介绍下CORS请求相关的字段

上述代码由http://localhost:3000/index.html向http://localhost:4000/跨域请求，正如我们上面所说的，后端是实现 CORS 通信的关键。

3.postMessagepostMessage是HTML5 XMLHttpRequest Level 2中的API，且是为数不多可以跨域操作的window属性之一，它可用于解决以下方面的问题：

页面和其打开的新窗口的数据传递多窗口之间消息传递页面与嵌套的iframe消息传递上面三个场景的跨域数据传递postMessage()方法允许来自不同源的脚本采用异步方式进行有限的通信，可以实现跨文本档、多窗口、跨域消息传递。

otherWindow.postMessage(message, targetOrigin, [transfer]);

message: 将要发送到其他 window的数据。targetOrigin:通过窗口的origin属性来指定哪些窗口能接收到消息事件，其值可以是字符串"*"（表示无限制）或者一个URI。在发送消息的时候，如果目标窗口的协议、主机地址或端口这三者的任意一项不匹配targetOrigin提供的值，那么消息就不会被发送；只有三者完全匹配，消息才会被发送。transfer(可选)：是一串和message 同时传递的 Transferable 对象. 这些对象的所有权将被转移给消息的接收方，而发送一方将不再保有所有权。接下来我们看个例子：http://localhost:3000/a.html页面向http://localhost:4000/b.html传递“我爱你”,然后后者传回"我不爱你"。

4.websocketWebsocket是HTML5的一个持久化的协议，它实现了浏览器与服务器的全双工通信，同时也是跨域的一种解决方案。WebSocket和HTTP都是应用层协议，都基于 TCP 协议。但是 WebSocket 是一种双向通信协议，在建立连接之后，WebSocket 的 server 与 client 都能主动向对方发送或接收数据。同时，WebSocket 在建立连接时需要借助 HTTP 协议，连接建立好了之后 client 与 server 之间的双向通信就与 HTTP 无关了。

原生WebSocket API使用起来不太方便，我们使用Socket.io，它很好地封装了webSocket接口，提供了更简单、灵活的接口，也对不支持webSocket的浏览器提供了向下兼容。

我们先来看个例子：本地文件socket.html向localhost:3000发生数据和接受数据

5. Node中间件代理(两次跨域)实现原理：同源策略是浏览器需要遵循的标准，而如果是服务器向服务器请求就无需遵循同源策略。代理服务器，需要做以下几个步骤：

接受客户端请求。将请求转发给服务器。拿到服务器响应数据。将响应转发给客户端。我们先来看个例子：本地文件index.html文件，通过代理服务器http://localhost:3000向目标服务器http://localhost:4000请求数据。

上述代码经过两次跨域，值得注意的是浏览器向代理服务器发送请求，也遵循同源策略，最后在index.html文件打印出{"title":"fontend","password":"123456"}

6.nginx反向代理实现原理类似于Node中间件代理，需要你搭建一个中转nginx服务器，用于转发请求。

使用nginx反向代理实现跨域，是最简单的跨域方式。只需要修改nginx的配置即可解决跨域问题，支持所有浏览器，支持session，不需要修改任何代码，并且不会影响服务器性能。

实现思路：通过nginx配置一个代理服务器（域名与domain1相同，端口不同）做跳板机，反向代理访问domain2接口，并且可以顺便修改cookie中domain信息，方便当前域cookie写入，实现跨域登录。

先下载nginx，然后将nginx目录下的nginx.conf修改如下:

最后通过命令行nginx -s reload启动nginx

7.window.name + iframewindow.name属性的独特之处：name值在不同的页面（甚至不同域名）加载后依旧存在，并且可以支持非常长的 name 值（2MB）。

其中a.html和b.html是同域的，都是http://localhost:3000;而c.html是http://localhost:4000

b.html为中间代理页，与a.html同域，内容为空。

总结：通过iframe的src属性由外域转向本地域，跨域数据即由iframe的window.name从外域传递到本地域。这个就巧妙地绕过了浏览器的跨域访问限制，但同时它又是安全操作。

8.location.hash + iframe实现原理： a.html欲与c.html跨域相互通信，通过中间页b.html来实现。三个页面，不同域之间利用iframe的location.hash传值，相同域之间直接js访问来通信。

具体实现步骤：一开始a.html给c.html传一个hash值，然后c.html收到hash值后，再把hash值传递给b.html，最后b.html将结果放到a.html的hash值中。同样的，a.html和b.html是同域的，都是http://localhost:3000;而c.html是http://localhost:4000

9.document.domain + iframe该方式只能用于二级域名相同的情况下，比如 a.test.com 和 b.test.com 适用于该方式。只需要给页面添加 document.domain ='test.com' 表示二级域名都相同就可以实现跨域。

实现原理：两个页面都通过js强制设置document.domain为基础主域，就实现了同域。

我们看个例子：页面a.zf1.cn:3000/a.html获取页面b.zf1.cn:3000/b.html中a的值

三、总结CORS支持所有类型的HTTP请求，是跨域HTTP请求的根本解决方案JSONP只支持GET请求，JSONP的优势在于支持老式浏览器，以及可以向不支持CORS的网站请求数据。不管是Node中间件代理还是nginx反向代理，主要是通过同源策略对服务器不加限制。日常工作中，用得比较多的跨域方案是cors和nginx反向代理