sessionID一直变化。

本文探讨了在使用iframe引入另一个项目时遇到的跨域登录问题,并提供了两种解决方案:一是设置P3P策略来保留cookie;二是针对外网映射导致的session冲突问题提出了调整IP配置的方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1.  第一种出现是在一个项目里面这里叫A项目,需要嵌入另外一个项目这里叫B项目,通过iframe (IE会出现)

     通过iframe引入   B项目  因为B项目里面有登录拦截,所以在A项目里面会请求登录一下,可是只要一请求B项目,就一直停留在请登录

     调试后发现每次请求都会产生一个全新的sessionid,所以才会一直出现请重新登录的界面。问题是找到了(ps:只要可以登录,到时候通过iframe就可以引入自己需要的B项目页面了)要怎么解决呢?

    百度了以后发现,IE会丢失iframe中的cookie,而session其实就是基于cookie的,客户端在第一次与服务器进行会话时,会分配给客户端sessionid保存在cookie中,然后在后面的请求中,会带上cookie, 现在IE会丢失iframe中的cookie,所以服务器会重新分配给客户端sessionid ,所以会提示一直需要登录

   所以只要设置一下p3p就可以了。

   P3P(Platform for Privacy Preferences)正是一种可以提供这种个人隐私保护策略,一般浏览器都支持P3P协议。P3P header允许跨域访问隐私数据,从而可以跨域set-cookie成功

 我是在B项目的拦截器里面加了一个p3p协议设定的代码

  HttpServletResponse res = (HttpServletResponse) ServletActionContext.getResponse();

  res.setHeader("P3P","CP=CAO PSA OUR");

  

2.第二种是出现在外网访问的地方,第二种出现的情况是基于第一种,就是我们的A项目和B项目本来是在内网部署的,然后需要给领导看,叫网管把我们这两个项目的地址给映射到外网了。登录A项目的时候,一直提示,请重新登录

   一调试,还是一样的问题,sessionid一直在变化,那这个是什么原因呢?

   后面百度得知:因为我们的A项目和B项目映射到外网以后是ip一致,然后端口不同而已,这样子会造成session冲突

    IP相同认为是 同一个域,接收了B的set-cookie指令,把对应的cookie内容覆盖了,其中包括sessionid,造成A的session丢失。 如果 IP不同,则不会发生这个问题。IP相同的两个session对应的cookie是一样的,而不幸的是sessionID就保存在cookie中,这样先访问A,再访问B的时候,B的sessionid会覆盖A的sessionid。这个事情没办法解决,所以不能弄两个端口,要弄两个外网ip。都是cookie出现的问题,它不会区分端口,造成这多个站点不断的覆盖前面的,从而造成session的丢失

转载:http://blog.youkuaiyun.com/rendeyishi/article/details/53894643

<think>好的,我现在需要回答用户关于sessionid在Web开发中的作用及实现方式的问题。首先,我得回忆一下session和cookie的相关知识,确保自己理解正确。根据用户提供的引用资料,特别是引用[4],里面提到session是服务端的内存区域,每个session有唯一的sessionid,通过cookie返回给前端。每次请求时浏览器自动携带cookie中的sessionid,服务端根据这个id找到对应的session对象。 接下来,我要整理sessionid的主要作用。首先,用户身份识别是关键,每个用户登录后服务端生成唯一的sessionid,用来标识不同的用户。然后是状态保持,HTTP是无状态的,通过sessionid可以在多次请求中维持用户状态,比如保持登录状态。另外,引用[3]提到Spring-Session通过Filter和HttpServletRequestWrapper来管理session,这说明实现方式可能涉及拦截请求和自定义session管理。 在实现方式方面,服务端生成sessionid通常在用户第一次访问时创建,比如登录成功后。生成算法可能有UUID或者安全随机数,确保唯一性。存储位置方面,引用[3]和[4]指出session存在服务器的内存中,不过分布式系统可能需要集中存储如Redis。客户端存储则是通过cookie,设置Set-Cookie头部,之后浏览器自动发送sessionid。服务端验证部分,每次请求解析cookie获取sessionid,然后查找对应的session数据,如果无效或过期则要求重新登录。 还需要考虑安全性,比如防止session劫持,使用HTTPS、设置HttpOnly和Secure属性。另外,引用[5]提到开发时要注意session的有效期管理和存储大小,避免内存泄漏。可能用户还会关心session和cookie的区别,但问题主要围绕sessionid,所以可以简要提到它们的联系,如session依赖cookie传递sessionid。 最后,根据用户的要求生成相关问题,比如sessionid的安全性问题、分布式系统中的处理、与cookie的关系等。确保引用正确,比如引用[4]解释sessionid的生成和传递,引用[3]说明服务端管理session的方式。回答要结构清晰,分点说明,同时保持自然的中文表达,不使用Markdown格式。</think>### SessionID在Web开发中的作用及实现方式 #### 一、SessionID的核心作用 1. **用户身份识别** 服务端为每个会话分配唯一的$sessionID$,用于标识不同用户的会话状态。例如,用户登录后,服务端生成$sessionID$并将其绑定到用户数据[^4]。 2. **状态保持** HTTP协议本身无状态,通过$sessionID$可在多次请求中关联用户数据。例如,购物车内容、登录状态等均依赖$sessionID$维持。 3. **安全控制** $sessionID$可结合加密算法(如HMAC)验证请求合法性,防止伪造会话[^3]。 --- #### 二、实现方式详解 1. **服务端生成与存储** - **生成时机**:用户首次访问或登录时创建$sessionID$,例如: $$ sessionID = \text{安全随机算法(如UUID)} $$ - **存储位置**:服务端内存(如Tomcat)、数据库或Redis等集中存储(分布式场景)[^3]。 2. **客户端存储** - **Cookie传递**:服务端通过`Set-Cookie`头部将$sessionID$写入浏览器: ```http Set-Cookie: JSESSIONID=abc123; Path=/; HttpOnly; Secure ``` - **URL重写**:若浏览器禁用Cookie,可将$sessionID$嵌入URL(如`/page;jsessionid=abc123`)[^2]。 3. **服务端验证** - 每次请求解析Cookie或URL中的$sessionID$。 - 根据$sessionID$查找对应的会话数据,若失效则要求重新认证[^4]。 --- #### 三、关键技术与安全性 1. **Session劫持防护** - 使用HTTPS加密传输,防止$sessionID$被窃听。 - 设置Cookie属性:`HttpOnly`(阻止JS访问)、`Secure`(仅HTTPS传输)。 2. **分布式Session管理** - 通过Redis或Spring-Session实现跨服务会话共享。 - 设计Filter拦截请求,自定义Session存储逻辑(如引用[3]中的`HttpServletRequestWrapper`)。 ---
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值