javawebsessionid

① java web的怎么通过sessionid得到session

在回答问题之前，跟你简单介绍Session的工作原理：

不需要写手动写SessionID:

代码如下：

HttpSessionsesion=Request.getSesion();

if(session!=null){

//如果sessionID不等于空版，则说明是权第二次访问

//写第二次访问时的代码

}else{

//写第一次访问的代码

}

javaweb怎么通过sessionid得到session这个我们不需要了解，就是第二次客户端发出请求时，将sessionid也发给了服务器，服务器根据这个唯一的ID找到相应的session(session都是保存在服务器的数据库中，每个session用唯一一个ID所标识），就像是数据库中根据关键字查找数据一样，找到之后就可以直接用这个session里面的数据了。

② java session怎么来的

HTTP协议 （ http://www.w3.org/Protocols/ ）是“一次性单向”协议。
服务端不能主动连接客户端，只能被动等待并答复客户端请求。客户端连接服务端，发出一个HTTP Request，服务端处理请求，并且返回一个HTTP Response给客户端，本次HTTP Request-Response Cycle结束。
我们看到，HTTP协议本身并不能支持服务端保存客户端的状态信息。于是，Web Server中引入了session的概念，用来保存客户端的状态信息。
这里用一个形象的比喻来解释session的工作方式。假设Web Server是一个商场的存包处，HTTP Request是一个顾客，第一次来到存包处，管理员把顾客的物品存放在某一个柜子里面（这个柜子就相当于Session），然后把一个号码牌交给这个顾客，作为取包凭证（这个号码牌就是Session ID）。顾客（HTTP Request）下一次来的时候，就要把号码牌（Session ID）交给存包处（Web Server）的管理员。管理员根据号码牌（Session ID）找到相应的柜子（Session），根据顾客（HTTP Request）的请求，Web Server可以取出、更换、添加柜子（Session）中的物品，Web Server也可以让顾客（HTTP Request）的号码牌和号码牌对应的柜子（Session）失效。顾客（HTTP Request）的忘性很大，管理员在顾客回去的时候（HTTP Response）都要重新提醒顾客记住自己的号码牌（Session ID）。这样，顾客（HTTP Request）下次来的时候，就又带着号码牌回来了。
我们可以看到，Session ID实际上是在客户端和服务端之间通过HTTP Request和HTTP Response传来传去的。
我们看到，号码牌（Session ID）必须包含在HTTP Request里面。关于HTTP Request的具体格式，请参见HTTP协议（http://www.w3.org/Protocols/ ）。这里只做一个简单的介绍。
在Java Web Server（即Servlet/jsP Server）中，Session ID用jsessionid表示（请参见Servlet规范）。
HTTP Request一般由3部分组成：
（1）Request Line
这一行由HTTP Method（如GET或POST）、URL、和HTTP版本号组成。
例如，GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
GET http://www.google.com/search?q=Tomcat HTTP/1.1
POST http://www.google.com/search HTTP/1.1
GET http://www.somsite.com/menu.do;jsessionid=1001 HTTP/1.1
（2）Request Headers
这部分定义了一些重要的头部信息，如，浏览器的种类，语言，类型。Request Headers中还可以包括Cookie的定义。例如：
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Accept-Language: en-us
Cookie: jsessionid=1001
（3）Message Body
如果HTTP Method是GET，那么Message Body为空。
如果HTTP Method是POST，说明这个HTTP Request是submit一个HTML Form的结果，
那么Message Body为HTML Form里面定义的Input属性。例如，
user=guest
password=guest
jsessionid=1001
主意，如果把HTML Form元素的Method属性改为GET。那么，Message Body为空，所有的Input属性都会加在URL的后面。你在浏览器的URL地址栏中会看到这些属性，类似于
http://www.somesite/login.do?user=guest&password=guest&jsessionid=1001
从理论上来说，这3个部分（Request URL，Cookie Header, Message Body）都可以用来存放Session ID。由于Message Body方法必须需要一个包含Session ID的HTML Form，所以这种方法不通用。
一般用来实现Session的方法有两种：
（1）URL重写。
Web Server在返回Response的时候，检查页面中所有的URL，包括所有的连接，和HTML Form的Action属性，在这些URL后面加上“;jsessionid=XXX”。
下一次，用户访问这个页面中的URL。jsessionid就会传回到Web Server。
（2）Cookie。
如果客户端支持Cookie，Web Server在返回Response的时候，在Response的Header部分，加入一个“set-cookie: jsessionid=XXXX”header属性，把jsessionid放在Cookie里传到客户端。
客户端会把Cookie存放在本地文件里，下一次访问Web Server的时候，再把Cookie的信息放到HTTP Request的“Cookie”header属性里面，这样jsessionid就随着HTTP Request返回给Web Server。
我们来看Tomcat5的源代码如何支持jsessionid。
org.apache.coyote.tomcat5.CoyoteResponse类的toEncoded()方法支持URL重写。
String toEncoded(String url, String sessionId) {
…
StringBuffer sb = new StringBuffer(path);
if( sb.length() > 0 ) { // jsessionid can't be first.
sb.append(";jsessionid=");
sb.append(sessionId);
}
sb.append(anchor);
sb.append(query);
return (sb.toString());
}
我们来看org.apache.coyote.tomcat5.CoyoteRequest的两个方法configureSessionCookie()
doGetSession()用Cookie支持jsessionid.
/**
* Configures the given JSESSIONID cookie.
*
* @param cookie The JSESSIONID cookie to be configured
*/
protected void configureSessionCookie(Cookie cookie) {
…
}
HttpSession doGetSession(boolean create){
…
// Creating a new session cookie based on that session
if ((session != null) && (getContext() != null)
&& getContext().getCookies()) {
Cookie cookie = new Cookie(Globals.SESSION_COOKIE_NAME,
session.getId());
configureSessionCookie(cookie);
((HttpServletResponse) response).addCookie(cookie);
}
…
}
Session的典型应用是存放用户的Login信息，如用户名，密码，权限角色等信息，应用程序（如Email服务、网上银行等系统）根据这些信息进行身份验证和权限验证

③ java如何获取sessionid

这个功能老版本servlet规范中有，新版本中好像被屏蔽了。可以换一种做法，写一个session监听。创建时将session
id与session对象构造一个hashMap放到
application中去，销毁时从application中移除。然后你就可以获取了。

④ javaweb为什么浏览器的地址栏会出现sessionid

是为了让web服务器能记住你！
第一次访问：请求中不会有sessionid，响应中会有sessionid，这是服务器发给你的身份标识；
第二次访问：你的浏览器会自动把这个sessionid发给服务器，服务器就能认出你是上次访问过的那个用户；
第三次和以后都是这样；
当浏览器关闭后，这个sessionId就会失效；
sessionid就是在浏览器一次开闭过程中，让服务器能记住你的一种机制;
因为不同的http请求之间是没有关联的，服务器为了分辨哪些请求来自同一台电脑，就有了session机制,

⑤ java web应用如何实现单点登录

• 实现方式一：父域 Cookie

• 实现方式二：认证中心

• 实现方式三：LocalStorage跨域

• 补充：域名分级

在 B/S 系统中，登录功能通常都是基于 Cookie 来实现的。当用户登录成功后，一般会将登录状态记录到 Session 中，或者是给用户签发一个 Token，无论哪一种方式，都需要在客户端保存一些信息（Session ID 或 Token ），并要求客户端在之后的每次请求中携带它们。在这样的场景下，使用 Cookie 无疑是最方便的，因此我们一般都会将 Session 的 ID 或 Token 保存到 Cookie 中，当服务端收到请求后，通过验证 Cookie 中的信息来判断用户是否登录 。

单点登录（Single Sign On, SSO）是指在同一帐号平台下的多个应用系统中，用户只需登录一次，即可访问所有相互信任的应用系统。举例来说，网络贴吧和网络地图是网络公司旗下的两个不同的应用系统，如果用户在网络贴吧登录过之后，当他访问网络地图时无需再次登录，那么就说明网络贴吧和网络地图之间实现了单点登录。

单点登录的本质就是在多个应用系统中共享登录状态。如果用户的登录状态是记录在 Session 中的，要实现共享登录状态，就要先共享 Session，比如可以将 Session 序列化到 Redis 中，让多个应用系统共享同一个 Redis，直接读取 Redis 来获取 Session。

当然仅此是不够的，因为不同的应用系统有着不同的域名，尽管 Session 共享了，但是由于 Session ID 是往往保存在浏览器 Cookie 中的，因此存在作用域的限制，无法跨域名传递，也就是说当用户在 app1.com 中登录后，Session ID 仅在浏览器访问 app1.com 时才会自动在请求头中携带，而当浏览器访问 app2.com 时，Session ID 是不会被带过去的。实现单点登录的关键在于，如何让 Session ID（或 Token）在多个域中共享。

实现方式一：父域 Cookie

在将具体实现之前，我们先来聊一聊 Cookie 的作用域。

Cookie 的作用域由 domain 属性和 path 属性共同决定。domain 属性的有效值为当前域或其父域的域名/IP地址，在 Tomcat 中，domain 属性默认为当前域的域名/IP地址。path 属性的有效值是以“/”开头的路径，在 Tomcat 中，path 属性默认为当前 Web 应用的上下文路径。

如果将 Cookie 的 domain 属性设置为当前域的父域，那么就认为它是父域 Cookie。Cookie 有一个特点，即父域中的 Cookie 被子域所共享，换言之，子域会自动继承父域中的Cookie。

利用 Cookie 的这个特点，不难想到，将 Session ID（或 Token）保存到父域中不就行了。没错，我们只需要将 Cookie 的 domain 属性设置为父域的域名（主域名），同时将 Cookie 的 path 属性设置为根路径，这样所有的子域应用就都可以访问到这个 Cookie 了。不过这要求应用系统的域名需建立在一个共同的主域名之下，如 tieba..com 和 map..com，它们都建立在 .com 这个主域名之下，那么它们就可以通过这种方式来实现单点登录。

总结：此种实现方式比较简单，但不支持跨主域名。

实现方式二：认证中心

我们可以部署一个认证中心，认证中心就是一个专门负责处理登录请求的独立的 Web 服务。

用户统一在认证中心进行登录，登录成功后，认证中心记录用户的登录状态，并将 Token 写入 Cookie。（注意这个 Cookie 是认证中心的，应用系统是访问不到的。）

应用系统检查当前请求有没有 Token，如果没有，说明用户在当前系统中尚未登录，那么就将页面跳转至认证中心。由于这个操作会将认证中心的 Cookie 自动带过去，因此，认证中心能够根据 Cookie 知道用户是否已经登录过了。如果认证中心发现用户尚未登录，则返回登录页面，等待用户登录，如果发现用户已经登录过了，就不会让用户再次登录了，而是会跳转回目标 URL ，并在跳转前生成一个 Token，拼接在目标 URL 的后面，回传给目标应用系统。

应用系统拿到 Token 之后，还需要向认证中心确认下 Token 的合法性，防止用户伪造。确认无误后，应用系统记录用户的登录状态，并将 Token 写入 Cookie，然后给本次访问放行。（注意这个 Cookie 是当前应用系统的，其他应用系统是访问不到的。）当用户再次访问当前应用系统时，就会自动带上这个 Token，应用系统验证 Token 发现用户已登录，于是就不会有认证中心什么事了。

这里顺便介绍两款认证中心的开源实现：

Apereo CAS 是一个企业级单点登录系统，其中 CAS 的意思是”Central Authentication Service“。它最初是耶鲁大学实验室的项目，后来转让给了 JASIG 组织，项目更名为 JASIG CAS，后来该组织并入了Apereo 基金会，项目也随之更名为 Apereo CAS。

XXL-SSO 是一个简易的单点登录系统，由大众点评工程师许雪里个人开发，代码比较简单，没有做安全控制，因而不推荐直接应用在项目中，这里列出来仅供参考。

总结：此种实现方式相对复杂，支持跨域，扩展性好，是单点登录的标准做法。

实现方式三：LocalStorage 跨域

前面，我们说实现单点登录的关键在于，如何让 Session ID（或 Token）在多个域中共享。

父域 Cookie 确实是一种不错的解决方案，但是不支持跨域。那么有没有什么奇淫技巧能够让 Cookie 跨域传递呢？

很遗憾，浏览器对 Cookie 的跨域限制越来越严格。Chrome 浏览器还给 Cookie 新增了一个 SameSite 属性，此举几乎禁止了一切跨域请求的 Cookie 传递（超链接除外），并且只有当使用 HTTPs 协议时，才有可能被允许在 AJAX 跨域请求中接受服务器传来的 Cookie。

不过，在前后端分离的情况下，完全可以不使用 Cookie，我们可以选择将 Session ID （或 Token ）保存到浏览器的 LocalStorage 中，让前端在每次向后端发送请求时，主动将 LocalStorage 的数据传递给服务端。这些都是由前端来控制的，后端需要做的仅仅是在用户登录成功后，将 Session ID （或 Token ）放在响应体中传递给前端。

在这样的场景下，单点登录完全可以在前端实现。前端拿到 Session ID （或 Token ）后，除了将它写入自己的 LocalStorage 中之外，还可以通过特殊手段将它写入多个其他域下的 LocalStorage 中。

————————————————

版权声明：本文为CSDN博主「风水道人」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/jcmj123456/article/details/114296482

前端通过 iframe+postMessage() 方式，将同一份 Token 写入到了多个域下的 LocalStorage 中，前端每次在向后端发送请求之前，都会主动从 LocalStorage 中读取 Token 并在请求中携带，这样就实现了同一份 Token 被多个域所共享。

总结：此种实现方式完全由前端控制，几乎不需要后端参与，同样支持跨域。

补充：域名分级

从专业的角度来说（根据《计算机网络》中的定义），.com、.cn 为一级域名（也称顶级域名），.com.cn、.com 为二级域名，sina.com.cn、tieba..com 为三级域名，以此类推，N 级域名就是 N-1 级域名的直接子域名。

从使用者的角度来说，一般把可支持独立备案的主域名称作一级域名，如 .com、sina.com.cn 皆可称作一级域名，在主域名下建立的直接子域名称作二级域名，如 tieba..com 为二级域名。

⑥ Java中session是怎样定义的，它的作用域在哪

首先要明确一个概念，session并不是java独有的，而是基于http的（jsp、asp.net、php等等技术都会涉及到session），下面我来讲解一下sessin的具体内容：

session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。
当程式需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为session id，如果已包含一个session id则说明以前已为此客户端创建过session，服务器就按照session id把这个session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个和此session相关联的session id，session id的值应该是个既不会重复，植蝗菀妆徽业焦媛梢苑略斓淖址???飧?ession id将被在本次响应中返回给客户端保存。
保存这个session id的方式能采用cookie，这样在交互过程中浏览器能自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于SEEESIONID，而。比如weblogic对于web应用程式生成的cookie，JSESSIONID=!-145788764，他的名字就是JSESSIONID。
由于cookie能被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面，附加方式也有两种，一种是作为URL路径的附加信息，表现形式为http://...../xxx;jsessionid=ByOK ... 99zWpBng!-145788764另一种是作为查询字符串附加在URL后面，表现形式为http://...../xxx?jsessionid=ByOK ... 99zWpBng!-145788764
这两种方式对于用户来说是没有差别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程式参数区分开来。
为了在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。
另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。
这种技术目前已较少应用，笔者接触过的非常古老的iPlanet6(SunONE应用服务器的前身)就使用了这种技术。实际上这种技术能简单的用对action应用URL重写来代替。
在谈论session机制的时候，常常听到这样一种误解“只要关闭浏览器，session就消失了”。其实能想象一下会员卡的例子，除非顾客主动对店家提出销卡，否则店家绝对不会轻易删除顾客的资料。对session来说也是相同的，除非程式通知服务器删除一个session，否则服务器会一直保留，程式一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器他将要关闭，因此服务器根本不会有机会知道浏览器已关闭，之所以会有这种错觉，是大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个session id就消失了，再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上，或使用某种手段改写浏览器发出的HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。
恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就能认为客户端已停止了活动，才会把session删除以节省存储空间。