IE8 Session 混乱问题的解决方案

最新推荐文章于 2021-05-18 17:02:50 发布
转载 最新推荐文章于 2021-05-18 17:02:50 发布 · 1.8k 阅读 · 0
文章标签：

#session #ie

本文提供了Internet Explorer 8中会话管理的相关说明及解决方案链接，包括MSDN官方文档和技术博客中的详细指南。
Java Web学习总结（10）——Session详解
科技D人生
01-04 2192
摘要：虽然session机制在web应用程序中被采用已经很长时间了，但是仍然有很多人不清楚session机制的本质，以至不能正确的应用这一技术。本文将详细讨论session的工作机制并且对在Java web application中应用session机制时常见的问题作出解答。 目录： 一、术语session 二、HTTP协议与状态保持 三、理解cookie机制 四、理解session
IE8下session共享的问题以及相应的解决方案
knuthdream的专栏
01-15 1909
在开发WEB项目的过程中，如果采用IE8浏览器进行测试的话，会出现用户信息覆盖的现象。也就是说，在IE8浏览器中，打开多个窗口或者一个窗口里打开多个标签，采用多用户登陆的时候，后登录的用户信息，会覆盖先登录的用户信息。这就是session共享导致的。 这个问题的解决，可以从两个方面入手。 客户端：如果在IE8浏览器中访问资源的时候，是用的新建会话，则不会存在这个问题。众所周知，在不同的会话中，
如何解决串session:
BigData
01-11 723
在IE快捷方式上点击鼠标右键》属性》快捷方式》目标："C:\Program Files\Internet Explorer\iexplore.exe" -nomerge这样就可以了。 -nomerge这个前面有一个空格
IE8串session的解决方法
02-19
IE8串session的解决方法
div错位解决IE6IE7IE8样式不兼容问题
10-18
div错位解决IE6IE7IE8样式不兼容问题
关于多个浏览器进程间共享session引发的安全漏洞思考
whoisyoya的博客
04-01 440
早上在为项目的安全框架做选型，目前选择和测试的是Apache Shiro，以此为基础做web application的应用测试，无意中，发现了可能大家早已知晓的问题。 1.打开两个同类型的浏览器，(我测试过IE6/7/8、Chorme、Firefox)，分别为A、B 2.我在A中登录应用，然后直接关闭。 3.我在B中直接通过URL进入应用，这时应用的授权状...
IE SESSION 共享问题
weixin_43417960的博客
01-18 852
IE SESSION 共享问题
Session机制详解
xiaoyaGrace的博客
02-11 1733
Session机制详解虽然session机制在web应用程序中被采用已经很长时间了，但是仍然有很多人不清楚session机制的本质，以至不能正确的应用这一技术。本文将详细讨论session的工作机制并且对在Java web application中应用session机制时常见的问题作出解答。一、术语session 在我的经验里，session这个词被滥用的程度大概仅次于transact...
前后端接口联调终极方案：彻底解决CORS跨域问题的4种高效策略
![前后端接口联调终极方案：彻底解决CORS跨域问题的4种高效策略]...同时，文章对比分析了代理层部署、API网关集成及替代性跨域技术的应用场景与安全边界，构建涵盖开发、生产与联调阶段的全链路解决方案
Web开发常见错误及解决方案汇总
下面将这些常见问题分为七个类别，并详细介绍症状、原因和解决方案。 #### 1. 错误分类概述 常见错误主要分为以下七类： - 安装与设置问题 - Visual FoxPro开发问题 - 脚本和模板特定问题 - 操作问题 - COM和基于...
浏览器多窗口共用session引发的混乱
05-25
NULL 博文链接：https://vearn.iteye.com/blog/376407
多开session,开发必备,可一次性打开多个网页登录多个用户,免去来回切换账号的烦恼
02-14
可用于web开发使用,将资源解压,选择对应的CRX文件放于谷歌浏览器扩展程序中,使用该插件可以免去频繁退出登录不同账号的烦恼,避免浪费不必要的开发时间,实乃开发必备之利器
同浏览器不同窗口不同用户Session问题
04-10
正对java Web项目，同浏览器同时打开两个登录窗口（不同Tag），用不同用户登录，为避免使用同一个Session，需要使用这段代码。否则先登录的用户的Session会变成后登录用户的Session.相关系统使用权限也会变。
不同浏览器Session使用和常见问题分析
热门推荐
u014419219的专栏
05-15 1万+
session跟踪机制 HTTP协议为无状态协议，对于每一个web请求，服务器是无法知道是否为同一个请求者。那么是怎么样跟踪请求的呢？ 图一 请求交互流程图 目前有两种方式。 第一种，使用cookie记录标志。浏览器是可以保存cookie信息的，在请求响应的时候，创建一个对应的cookie，记录一个编号，下次再发送请求的时候，将cookie记录的信息发送到服务器上，服务器取得这个值
j2ee session机制
一个人，在路上
06-06 2744
如何理解session机制，就让我们先从网络服务开始说起。目前网络服务主要分为两大类1）面向连接的服务2）面向无连接的服务。       对于面向连接的服务，在计算机开始通信之前首先必须建立网络连接，待数据通信结束才撤销连接，因此只有服务端和一个客户端进行通信。这样不需要多次验证客户端信息，因为在服务器端第一次就进行了验证并记住验证。       对无连接的服务，在通信之前并没有建立连
一个用户如果浏览器打开两个不同的帐套会导致数据混乱
a1192529545的专栏
06-01 2850
数据混乱的原因：同一浏览器窗口同一系统不同用户同时登陆时共享同一个session（是否共享取决于浏览器本身，我们无法控制） 仔细剖析：第一个人登陆，浏览器创建session，后台也根据sessionid创建session；同一浏览器窗口，第二个人登陆，浏览器不再创建新的session，而是将第二个人的信息保存到原来的session中（将原来的用户信息覆盖） 解决方法：同一个窗口只允许一个用户登
多个应用使用一个浏览器的session丢失问题
a760352276的博客
05-18 901
问题场景 之前使用Dubbo做前后台项目的时候，因为前台和后台使用了同一浏览器登录。发现登录了前台，再登录后台时，前台的状态已经被磨掉了 产生原因 通过DEBUG调试了一下，发现是session失效的问题。但是自己想的是两个系统应该不会有影响。 而实质是使用同一个浏览器导致的。当我使用两个不同的浏览器来处理的时候就会互不影响。 简单场景复现 复现场景 通过启动两个SpringBoot框架的Web项目，并打印对应的sessionId观察情况 两个请求的映射对应session1和session2，同时在后端处理
session 之session混乱解决方法
sdx_8218的专栏
03-17 772
<br />  session 之session混乱解决方法 收藏 <br />知道了session混乱产生的原因之后，也就知道了问题的根源。同时也引出了很多的问题：<br />1、如何记录住在线人员（这里只有帐号的系统用户，不包括访客）；<br />2、如何限制同一个帐号在同一时间段内只能够登陆一次系统？<br />3、如何限制不同的用户在同一台机器上登陆系统？<br />4、管理员如何踢人？<br />我们首先来分析上面的问题：<br />首先在服务器端当用户通过身份验证成功登陆系统之后，我们将此用户的
前端浏览器多开自动保存cookie会乱保存，保存到之前的数据解决
最新发布
05-10
<think>好的，我现在需要解决用户提到的前端浏览器多开时自动保存Cookie导致数据混乱的问题。首先，我需要理解用户的具体场景。用户可能在多个浏览器标签页或窗口同时登录不同的账号，或者同一应用的不同实例，导致Cookie被覆盖或混用，进而引发数据错乱。比如，用户可能在多个标签页中登录不同的账户，但Cookie存储的是同一个键名，导致不同标签页之间的数据互相干扰。 接下来，我要回顾之前的回答。上一次用户问的是前端自动保存Cookie失效的问题，我分析了原因并给出了解决方案，包括设置maxAge、域名路径配置、安全策略等。但这次的问题不同，是关于多开时的数据混乱，所以需要针对这个特定场景来思考。 首先，Cookie是基于域名和路径存储的，同一域名下所有标签页和窗口共享相同的Cookie存储空间。当用户多开时，如果每个实例使用相同的Cookie键名，就会导致数据相互覆盖。例如，用户同时在两个标签页登录不同的账号，后登录的会覆盖之前的Cookie，导致两个标签页都显示后登录的账号信息。 接下来，我需要考虑解决方案的方向。可能的思路包括隔离不同实例的Cookie，或者使用不同的存储机制。常见的解决方法可能有： 1. **会话标识隔离**：为每个浏览器实例生成唯一的会话ID，附加到Cookie的键名或值中，使得每个实例使用独立的Cookie。例如，在Cookie键名中加入随机后缀，如sessionId_123，这样不同实例的Cookie不会互相覆盖。 2. **使用不同域名或子域名**：为每个实例分配独立的子域名，如user1.example.com和user2.example.com，利用Cookie的domain属性隔离存储。但这种方法可能需要服务器配置支持，且对用户不太友好。 3. **切换存储方式**：避免使用Cookie，改用localStorage或sessionStorage，并结合实例标识来区分数据。但需要考虑这些存储方式的同源策略和生命周期。 4. **多标签同步管理**：通过共享Worker或BroadcastChannel API来协调多个标签页的Cookie使用，确保数据一致性。不过这可能比较复杂，且需要处理同步问题。 5. **用户手动选择上下文**：提供界面让用户选择不同的身份或环境，每次切换时动态更新Cookie。但用户体验可能受影响。 再考虑用户的实际使用情况，可能更倾向于无需用户干预的技术方案。所以，生成唯一的会话ID并隔离Cookie存储可能比较可行。例如，每个实例启动时生成一个UUID，作为Cookie键名的一部分，这样每个实例的Cookie独立存储，不会互相干扰。同时，需要考虑如何将生成的会话ID传递给后端，以便服务器识别不同的实例。 另外，需要处理用户主动刷新页面或重新打开标签页时的会话ID持久化问题。可能需要将实例ID存储在localStorage中，或者通过URL参数传递，确保同一实例在不同页面加载时使用相同的ID。 还有，Cookie的作用域和路径也需要正确设置，避免不同实例间的Cookie被错误读取。例如，设置path为特定路径，或结合实例ID在路径中区分。 另外，用户可能同时使用多个账号，导致需要同一域名下多个身份并存。这种情况下，传统的Cookie机制确实容易冲突，需要更彻底的隔离方案。例如，使用不同的端口或域名来区分实例，但这可能不太实际。 或者，后端可以支持多个会话令牌，前端根据实例选择对应的token进行请求。这需要后端的配合，允许同一用户有多个活跃会话。 此外，需要考虑安全性，避免会话ID被泄露或被恶意利用。生成足够随机的ID，使用HTTPS传输，设置Secure和HttpOnly属性等。 总结可能的步骤： 1. 前端生成唯一实例ID，存储在localStorage或URL参数中。 2. 将实例ID附加到Cookie的键名或作为值的一部分。 3. 后端根据不同的实例ID处理对应的会话数据。 4. 在页面加载时检查实例ID，若不存在则生成新的，确保每个实例独立。 这样，每个浏览器实例使用不同的Cookie键，数据就不会混乱了。同时，需要考虑实例ID的持久化，防止页面刷新后ID丢失，导致无法恢复之前的会话。 可能的问题点： - 如何管理大量生成的Cookie键，避免存储空间超出限制。 - 用户关闭实例后如何清理对应的Cookie，避免残留。 - 后端需要支持多会话管理，可能需要调整现有的认证机制。 另外，可能需要结合其他技术，如使用IndexedDB存储实例相关数据，而仅用Cookie存储会话ID，减少Cookie的使用量。 最后，验证方案的有效性，通过测试多个实例同时运行，检查数据是否独立，以及实例关闭后的清理情况。</think>### 前端浏览器多开导致 Cookie 数据混乱的解决方案 当用户在同一浏览器中多开标签页或窗口时，若共用同一套 Cookie 机制，会导致不同实例的会话数据相互覆盖，引发混乱（如多账号登录冲突、状态错乱）。以下是具体解决方案： --- #### 一、核心思路：隔离 Cookie 存储空间 通过为每个浏览器实例生成**唯一标识**，动态隔离 Cookie 的作用域或键名，实现数据独立存储。 --- #### 二、具体方案 1. **动态生成实例标识** 在页面初始化时，为每个标签页/窗口生成唯一标识（如 `instanceId`），并将其融入 Cookie 的键名或作用域中： ```javascript // 生成唯一实例ID（若不存在则创建） const instanceId = localStorage.getItem('instanceId') || crypto.randomUUID(); localStorage.setItem('instanceId', instanceId); // 持久化 // 写入带实例ID的Cookie（示例键名格式：auth_<instanceId>） document.cookie = `auth_${instanceId}=token_value; path=/; max-age=3600`; ``` **优势**： - 每个实例独立存储 Cookie，互不干扰 - 支持同一域名下多账号同时登录[^1] 2. **后端多会话支持** 改造后端认证逻辑，允许同一用户关联多个会话（通过 `instanceId` 区分）： ```java // 伪代码示例：根据 instanceId 存储多会话 Map<String, Session> userSessions = new ConcurrentHashMap<>(); userSessions.put(instanceId, new Session(userId, token)); ``` 3. **请求自动附加实例标识** 通过拦截器在每次请求中携带当前实例的标识： ```javascript // Axios 请求拦截器示例 axios.interceptors.request.use(config => { const instanceId = localStorage.getItem('instanceId'); config.headers['X-Instance-Id'] = instanceId; return config; }); ``` 4. **清理策略** 关闭标签页时自动清理关联的 Cookie（需监听 `beforeunload` 事件）： ```javascript window.addEventListener('beforeunload', () => { // 删除当前实例的Cookie document.cookie = `auth_${instanceId}=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;`; }); ``` --- #### 三、扩展优化方案 1. **使用 Web Workers 共享实例ID** 通过 `SharedWorker` 跨标签页管理实例ID，避免重复生成[^2]： ```javascript // SharedWorker 脚本（worker.js） onconnect = (e) => { const port = e.ports[0]; port.postMessage({ instanceId: globalInstanceId ||= crypto.randomUUID() }); }; ``` 2. **URL 参数注入标识** 对于深度链接场景，将 `instanceId` 注入 URL 参数以确保一致性： ```javascript if (!window.location.search.includes('instanceId')) { window.history.replaceState(null, '', `?instanceId=${instanceId}`); } ``` 3. **浏览器指纹辅助** 结合浏览器指纹（如 `navigator.userAgent` + 屏幕分辨率）生成更稳定的实例ID，减少 localStorage 依赖。 --- #### 四、注意事项 1. **Cookie 存储限制** 单个域名下 Cookie 总数通常不超过 **50 个**，单个 Cookie 大小不超过 **4KB**，需避免过度创建键名[^3]。 2. **安全性增强** - 为含敏感信息的 Cookie 添加 `HttpOnly` 和 `Secure` 属性 - 定期轮换 `instanceId` 防止长期暴露 3. **兼容性检查** - `crypto.randomUUID()` 需兼容 IE11 等旧浏览器时可替换为 `uuid` 库 - 隐私模式下 `localStorage` 可能受限，需降级方案 --- ### 相关问题 1. 如何实现同一浏览器的多账号同时登录？ 2. Web Workers 如何用于跨标签页通信？ 3. 浏览器指纹生成有哪些常见方法？
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值