「java全局会话」java会话管理

今天给各位分享java全局会话的知识，其中也会对java会话管理进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、快速切入：Spring框架核心概念总览
• 2、java语言中，四种会话跟踪技术分别是什么？
• 3、java什么是会话技术
• 4、登录那点事
• 5、JAVA中怎么使用session

快速切入：Spring框架核心概念总览

简而言之，Spring是企业级Java的开源开发框架。Spring框架的核心功能可用于开发任何java应用程序。Spring框架的核心模块如下：

任何由 Spring IoC 容器初始化的普通 Java 类都称为 Spring Bean。我们使用 spring 应用程序上下文来获取 Spring Bean 实例。 Spring IoC Container 管理 Spring Bean 范围/作用域的生命周期并在 bean 中注入任何所需的依赖项。

Spring bean的不同作用域：

对于任何 Java 应用程序，都有两个不同的作用域，称为单例（Singleton）和原型（Prototype）

主要有三种不同的作用域（或范围），即 请求（request）、会话（session）和全局会话（global-session） ，专门针对基于 Spring 的 Java Web 应用程序。

Singleton 是任何 bean 的默认作用域。这意味着每个 IoC 容器将创建单个 bean 实例。因此，单例 bean 不是线程安全的。

要设置 spring bean 的范围，我们可以在 标签中使用scope属性。 @scope 用于基于注释的 DI。

Spring 容器是 Spring 框架的核心。容器将创建对象，把它们连接在一起，配置它们，并管理它们从创建到销毁的完整生命周期。 Spring 容器使用依赖注入 (DI) 来管理组成应用程序的组件。

有两种不同类型的容器：

BeanFactory 容器 ：这是 Spring 容器的核心。 org.springframework.beans.factory.BeanFactory 是一个接口，充当 IoC 容器，它实例化、配置和管理许多 bean。应用示例如下：

ApplicationContext 容器 ：org.springframework.context.ApplicationContext 接口也充当 IoC 容器，但 ApplicationContext 接口建立在 BeanFactory 接口之上，以提供一些BeanFactory 额外的功能，例如与 Spring 的 AOP 的简单集成、消息资源处理（对于 I18N )、事件传播、Web 应用程序的应用层特定上下文（例如 WebApplicationContext）。所以使用 ApplicationContext 比使用 BeanFactory更好些。示例代码如下：

对于基于注解的依赖注入，使用@Autowired 注解。标有@Component/@Service/@Repository 等的类可以注入到标有@Autowired 的属性中

@Autowired 应用于:

1）基于构造器和setter的区别

2）context:annotation-config 和 context:component-scan 的区别

3）@Component、@Controller、@Repository @Service 注解的区别

如果一个类用@Component/@Controller/@Service/@Repository 注解标记，那么Spring DI 容器可以在组件扫描机制期间识别该类。但是，对于服务层类使用@Service 是个好主意，并且@Controller 应该在spring mvc web 控制器中使用。 @Repository 用于将 DAO 导入 DI 容器。此外，任何未经检查的异常都将被转换为 Spring DataAccessException。

4）ViewResolver 与 MultipartResolver

ViewResolver 用于按名称解析视图。该接口由 InternalResourceViewResolver 实现 ;

MultipartResolver 用于处理 web 应用程序中的文件上传。

5）Spring MVC 中的验证

org.springframework.validation.Validator 接口支持 spring MVC 验证。验证表单的一些实用方法是 ValidationUtils 类中的 rejectIfEmptyOrWhitespace() 和 rejectIfEmpty()。示例如下：

Spring MVC 中验证表单的另一种方法是:

HandlerInterceptor 接口充当 spring MVC 拦截器。它在服务请求之前和之后拦截。如果您实现了 HandlerInterceptor 接口，则 preHandle()、postHandle() 和 afterCompletion() 是要覆盖的方法。但是，为了避免覆盖，您可以使用 HandlerInterceptorAdapter 类。

实现 ServletContextAware 和 ServletConfigAware 接口并覆盖以下方法：

数据库事务是一组被视为关联工作单元的操作。事务的主要原则是提交所有操作或在失败的情况下回滚所有操作。在交易中提交数据时，我们需要确保交易协议/称为 ACID（原子性-一致性-隔离-持久性）的属性：

全局事务 vs 本地事务：

脏读、幻读和不可重复读：

隔离与传播：

在旧版本的 spring 和 hibernate 集成中，需要 HibernateDAOSupport 和 HibernateTemplate。但是，较新版本的 Spring 不建议使用这两个类（这里仅做了解）。

通常我们从 HibernateDAOSupport 扩展我们的 DAO 类，并且 getHibernateTemplate() 方法将可用于Hibernate会话中的 CRUD 操作。由于这不是推荐的方法，所以我们在 DAO 中注入会话工厂（SessionFactory）。下面的代码片段会给你一些关于 HibernateDAOSupport 和 HibernateTemplate 的想法:

DAO 是一种设计模式，以最大限度地减少应用程序和后端之间的耦合；

ORM 处理如何将对象映射到对象关系数据库中，从而减少数据库和应用程序之间的耦合。

如果您在没有 DAO 的情况下使用 ORM，那么您的应用程序将变得依赖于 ORM，因此很难从一个 ORM（例如Hibernate）移动到另一个 ORM（例如 NoSQL）。

Spring DAO 是使用@Repository 注解实现的。 Spring 存储库扩展 JPARepository 并传递 JPA 实体及其主键。

最后，关于Spring框架相关的概念就简要介绍到这里，希望这能给你进入并深入Spring技术栈一个简单入口，而不会被Spring技术生态所惊吓（Spring现在都成软件开发技术的全家桶了，啥都有）——日进一步，锲而不舍，终将大成！

java语言中，四种会话跟踪技术分别是什么？

答：会话作用域ServletsJSP页面描述

page否是代表与一个页面相关的对象和属性。一个页面由一个编译好的Javaservlet类(可以带有任何的include指令，但是没有include动作)表示。这既包括servlet又包括被编译成servlet的JSP页面

request是是代表与Web客户机发出的一个请求相关的对象和属性。一个请求可能跨越多个页面，涉及多个Web组件(由于forward指令和include动作的关系)

session是是代表与用于某个Web客户机的一个用户体验相关的对象和属性。一个Web会话可以也经常会跨越多个客户机请求

application是是代表与整个Web应用程序相关的对象和属性。这实质上是跨越整个Web应用程序，包括多个页面、请求和会话的一个全局作用域

java什么是会话技术

关于java中的会话技术需要理解以下几点：

首先需要认识会话：用户打开浏览器，访问Web服务器上多个资源，然后关闭浏览器，整个过程称之为一次会话。

为什么需要会话技术：http协议是非连接的，浏览器取完页面的内容以后就断掉了。当用同一个浏览器去访问同一个appa的另外一个页面的时候，另外一个页面能知道原来session里面的内容，会话机制因此出现。

常用的会话技术有：Cookies、Session和Url重写。

Cookies：由容器创建并且保存在客户端，客户端后续访问服务器的请求都将返回该Cookie             ，明确地请求与会话关联，又Cookies携带SessionId到服务器端。

Session：Session本质上是服务器端的一块内存，可以往里面放内容。并赋SessionId，                   与Cookies携带的SessionId对应。

Url重写：如果浏览器不支持cookies，需要自己编程使用URL重写的方式实现（这样session永远有效），方式如下：

response.encodeURL();

登录那点事

client：提供用户名和密码或者是其他的认证凭证

server：验证client提供的认证凭证，记录登录状态

过程：访问系统时，client必须输入用户名和密码，server进行验证，验证通过后server建立一个叫做session的东西，然后把sessionId通过cookie发送给浏览器，下次登录的时候会带着cookie一起发过来，server从cookie中拿到sessionId就知道已经登录啦。

 cookie和session的作用就是保持client和server的交互状态，这样一来可以将无状态的通信转化成有状态的交互，也就是让server有了“记忆”能力。

现在有三个服务，需要输入三次用户信息，但是如果有成百上千的服务呢？HOW???

参考上面简单登录的原理：服务端如何有了“记忆”能力呢：在client和server之间引入了一个中间层（cookie或者是session）。（题外话：计算机世界的99%的问题都可以通过一个引入一个中间层来解决）

所有我们可以想到一个可行的解决方案：对这个“中间层”做共享。

比如说先登录了A，就有了一个cookie，然后在用cookie去登录其他的系统。但是这样明显是有问题的：

1，cookie不能跨域，比如说a.com产生的cookie是不能传递给b.com的

2，就算cookie可以传递，但是其他系统并没有session来校验这个cookie。

解决方案：

1.cookie做共享可以挂到同一个一级域名下，比如A叫a.corp.com，B叫b.corp.com，C叫c.corp.com，这样cookie不就能共享了嘛

2，将session也做共享，从内存里面拿出来，放入一个大家都能访问的中间层里面，比如说redis。（题外话：又是中间层）

像下面这样：

可以解决多系统登录的问题么？可以解决！！！ 但是

1，要共享cookie就必须让所有的系统都在同一个域名下

2，多用户账号的存在。比如张三登录了A，然后去登录B，通过这种方式的话B需要去校验张三这个用户的合法性，此张三可能未必是彼张三！各个业务系统必须自己去维护自己系统的用户，而且用户信息还不止一个。

HOW？？？？

Single Sign One ：单点登录

消除多用户信息的问题，不用各个业务系统自己去维护用户信息，建立一个统一的用户认证中心（中间层：又是我哈哈哈），所有用户的认证工作都交给这个认证中心来完成。各个子业务只需要负责实现自己的业务即可，不在需要关心用户、认证等细节。

大致流程如下：

用户第一次访问A系统：，这个时候如果A发现用户没有登录的话，那他需要做的一项操作就是重定向认证中心：。

其中就是认证中心的登录地址，redirect=就是登录完成后需要跳转到的地址。在认证中心登录之后认证中心会做以下几件事情：

1，建立一个session

2，发放ticket

3，重定向到你的地址，并在浏览器种下cookie信息。注意这个cookie是认证中心服务器的cookie哦。如：ssoid=1,domain=sso.com

需要注意的有两点：

1，进行了两次重定向。第一次是重定向到SSO的服务器，第二次是重定向我们的后端服务器。

2，流程完成后再浏览器种了两个cookie，一个是sso服务器的cookie，一个是子系统A的cookie。

接下来我们访问B系统：

这个时候会有三个cookie：

1，认证中心的cookie    domain:   sso.com  

2，A系统的cookie    domain： a.corp.com

3, B系统的cookie     domain： b.corp.com

本质上就是保存了一个认证中心的cookie和多个子系统的cookie。一般我们称SSO的cookie的对应的会话成为全局会话，各自子系统cookie对应的会话称为局部会话。

概述

CAS（Central Authentication Service） 是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法（属于 Web SSO）。

CAS 开始于 2001 年， 并在 2004 年 12 月正式成为 JA-SIG 的一个项目。

特性

1、  开源的、多协议的 SSO 解决方案；Protocols：Custom Protocol、CAS、OAuth、OpenID、RESTful API、SAML1.1、SAML2.0 等。

2、  支持多种认证机制：Active Directory、JAAS、JDBC、LDAP、X.509 Certificates 等；

3、  安全策略：使用票据（Ticket）来实现支持的认证协议；

4、  支持授权：可以决定哪些服务可以请求和验证服务票据（Service Ticket）；

5、  提供高可用性：通过把认证过的状态数据存储在 TicketRegistry 组件中，这些组件有很多支持分布式环境的实现，如：BerkleyDB、Default 、EhcacheTicketRegistry、JDBCTicketRegistry、JBOSS TreeCache、JpaTicketRegistry、MemcacheTicketRegistry 等；

6、  支持多种客户端： Java、 .Net、 PHP、 Perl、 Apache, uPortal 等。

体系结构 

从结构上看，CAS 包含两个部分：CAS Server 和 CAS Client，CAS 需要独立部署，主要负责对用户的认证工作，CAS Server 会处理用户名 / 密码等凭证 (Credentials)。

负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。CAS Client一般与 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。过滤从客户端过来的每一个 Web 请求，同时， CAS Client 会分析 HTTP 请求中是否包请求 Service Ticket

术语

 Ticket Granting ticket (TGT) ：可以认为是CAS Server根据用户名密码生成的一张票，存在server端

Ticket-granting cookie (TGC) ：其实就是一个cookie，存放用户身份信息，由server发给client端

Service ticket (ST) ：由TGT生成的一次性票据，用于验证，只能用一次。相当于server发给client一张票，然后client拿着这是个票再来找server验证，看看是不是server签发的。就像是我给了你一张我的照片，然后你拿照片再来问我，这个照片是不是你。。。没错，就是这么无聊。

安全性

TGC安全性：

对于一个 CAS 用户来说，最重要是要保护它的 TGC，如果 TGC 不慎被 CAS Server 以外的实体获得，Hacker 能够找到该 TGC，然后冒充 CAS 用户访问所有授权资源。从基础模式可以看出， TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。TGT 的存活周期默认为 120 分钟。

ST安全性：

ST（Service Ticket）是通过 Http 传送的，因此网络中的其他人可以 Sniffer 到其他人的 Ticket。CAS 通过以下几方面来使 ST 变得更加安全：

1、  ST 只能使用一次

CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会清除服务端缓存中的该 Ticket，从而可以确保一个 Service Ticket 不被使用两次。

2、  ST 在一段时间内失效

CAS 规定 ST 只能存活一定的时间，然后 CAS Server 会让它失效。默认有效时间为 5 分钟。

3、  ST 是基于随机数生成的

ST 必须足够随机，如果 ST 生成规则被猜出，Hacker 就等于绕过 CAS 认证，直接访问对应的服务。

流程

上图是3个登录场景，分别为：第一次访问、第二次访问、以及登录状态下第一次访问mail.qiandu.com。

第一次访问

标号1： 用户访问，经过他的第一个过滤器：org.jasig.cas.client.authentication.AuthenticationFilter（cas提供，在web.xml中配置）。主要作用：判断是否登录，如果没有登录则重定向到认证中心

标号2： 发现用户没有登录，则返回浏览器重定向地址。

首先可以看到我们请求，之后浏览器返回状态码302，然后让浏览器重定向到cas.qiandu.com并且通过get的方式添加参数service，该参数目的是登录成功之后会要重定向回来，因此需要该参数。并且你会发现，其实server的值就是编码之后的我们请求的地址。

标号3： 浏览器接收到重定向之后发起重定向，请求cas.qiandu.com。

标号4： 认证中心cas.qiandu.com接收到登录请求，返回登陆页面。

上图就是标号3的请求，以及标号4的响应。请求的URL是标号2返回的URL。之后认证中心就展示登录的页面，等待用户输入用户名密码。

标号5： 用户在cas.qiandu.com的login页面输入用户名密码，提交。

标号6 ：服务器接收到用户名密码，则验证是否有效，验证逻辑可以使用cas-server提供现成的，也可以自己实现。

上图就是标号5的请求，以及标号6的响应了。当cas.qiandu.com即csa-server认证通过之后，会返回给浏览器302，重定向的地址就是Referer中的service参数对应的值。后边并通过get的方式挟带了一个ticket令牌，这个ticket就是ST（数字3处）。同时会在Cookie中设置一个CASTGC，该cookie是网站cas.qiandu.com的cookie，只有访问这个网站才会携带这个cookie过去。

Cookie中的CASTGC：向cookie中添加该值的目的是当下次访问cas.qiandu.com时，浏览器将Cookie中的TGC携带到服务器，服务器根据这个TGC，查找与之对应的TGT。从而判断用户是否登录过了，是否需要展示登录页面。TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。点击这里了解Java如何操作Cookie。

TGT：Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST）

TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他可以找到TGT。

ST：Service Ticket （小令牌），是TGT生成的，默认是用一次就生效了。也就是上面数字3处的ticket值。

标号7 ：浏览器从cas.qiandu.com哪里拿到ticket之后，就根据指示重定向到，请求的url就是上面返回的url。

标号8 ：在过滤器中会取到ticket的值，然后通过http方式调用cas.qiandu.com验证该ticket是否是有效的。

标号9 ：cas.qiandu.com接收到ticket之后，验证，验证通过返回结果告诉该ticket有效。

标号10 ：接收到cas-server的返回，知道了用户合法，展示相关资源到用户浏览器上。

第二次访问

标号11 ：用户发起请求，访问。会经过cas-client，也就是过滤器，因为第一次访问成功之后中会在session中记录用户信息，因此这里直接就通过了，不用验证了。

标号12 ：用户通过权限验证，浏览器返回正常资源。

访问mail.qiandu.com

标号13 ：用户在正常上网，突然想访问mail.qiandu.com，于是发起访问mail.qiandu.com的请求。

标号14 ：mail.qiandu.com接收到请求，发现第一次访问，于是给他一个重定向的地址，让他去找认证中心登录。

上图可以看到，用户请求mail.qiandu.com，然后返回给他一个网址，状态302重定向，service参数就是回来的地址。

标号15 ：浏览器根据14返回的地址，发起重定向，因为之前访问过一次了，因此这次会携带上次返回的Cookie：TGC到认证中心。

标号16 ：认证中心收到请求，发现TGC对应了一个TGT，于是用TGT签发一个ST，并且返回给浏览器，让他重定向到mail.qiandu.com

可以发现请求的时候是携带Cookie：CASTGC的，响应的就是一个地址加上TGT签发的ST也就是ticket。

标号17 ：浏览器根据16返回的网址发起重定向。

标号18 ：mail.qiandu.com获取ticket去认证中心验证是否有效。

标号19 ：认证成功，返回在mail.qiandu.com的session中设置登录状态，下次就直接登录。

标号20 ：认证成功之后就反正用想要访问的资源了。

配置filter

  我们需要在应用的web.xml文件中配置四个Filter，这四个Filter必须按照固定的顺序来进行配置，而且它们必须配置在应用的其它Filter之前。它们的先后顺序要求如下：

1、AuthenticationFilter

casServerLoginUrl用来指定Cas Server登录地址，serverName或service用来指定认证成功后需要跳转地址。

2、TicketValidationFilter

      请求通过AuthenticationFilter的认证之后，如果请求中携带了参数ticket则将会由TicketValidationFilter来对携带的ticket进行校验。 TicketValidationFilter只是对验证ticket的这一类Filter的统称，其并不对应Cas Client中的一个具体类型。Cas Client中有多种验证ticket的Filter，

都继承自AbstractTicketValidationFilter，它们的验证逻辑都是一致的，都有AbstractTicketValidationFilter实现，不同的是使用的TicketValidator不一样。这里我们使用Cas10TicketValidationFilter，也可以使用Cas20ProxyReceivingTicketValidationFilter或Saml11TicketValidationFilter。

3、HttpServletRequestWrapperFilter

 HttpServletRequestWrapperFilter用于将每一个请求对应的HttpServletRequest封装为其内部定义的CasHttpServletRequestWrapper，该封装类将利用之前保存在Session或request中的Assertion对象重写HttpServletRequest的getUserPrincipal()、getRemoteUser()和isUserInRole()方法。

      这样在我们的应用中就可以非常方便的从HttpServletRequest中获取到用户的相关信息

4、AssertionThreadLocalFilter

AssertionThreadLocalFilter可以在应用的其它地方获取Assertion对象，找个过滤器会把Assertion对象存放到当前的线程变量中，我们在程序的任何地方都可以从线程变量中获取当前Assertion，就不需要再从Session或request中进行解析了。这个线程变量是由AssertionHolder持有的，我们在获取当前的        Assertion时也只需要通过AssertionHolder的getAssertion()方法获取即可

JAVA中怎么使用session

不考虑框架下，在JAVA中使用session

大概有以下几种使用方法：

1、前台设置：利用jsp的内置对象session进行设置。

%

session.setAttribute("username", username);

%

2、后台设置：

(1)Filter设置：

public class MyFilter implements Filter {

@Override

public void doFilter(ServletRequest arg0, ServletResponse arg1, FilterChain chain) throws IOException, ServletException {

//把请求和响应对象强制转换为HttpServlet域对象

HttpServletRequest request = (HttpServletRequest)arg0;

HttpServletResponse responce = (HttpServletResponse)arg1;

HttpSession session = request.getSession(false);

session.setAttribute("username", username);

}

}

(2)Servlet设置：

public class MyServlet extends HttpServlet {

//doGet()与doPost()任选

public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

//创建session对象

HttpSession session = request.getSession(false);

session.setAttribute("username", username);

}

}

扩展资料：

Session:在计算机中，尤其是在网络应用中，称为“会话控制”。Session

对象存储特定用户会话所需的属性及配置信息。

这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session

对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。

当用户请求来自应用程序的 Web 页时，如果该用户还没有会话，则 Web

服务器将自动创建一个 Session 对象。当会话过期或被放弃后，服务器将终止该会话。

Session

对象最常见的一个用法就是存储用户的首选项。例如，如果用户指明不喜欢查看图形，就可以将该信息存储在 Session 对象中。

有关使用

Session 对象的详细信息，请参阅“ASP 应用程序”部分的“管理会话”。注意 会话状态仅在支持 cookie 的浏览器中保留。

session的工作原理：

1、当一个session第一次被启用时，一个唯一的标识被存储于本地的cookie中。

2、首先使用session_start()函数，PHP从session仓库中加载已经存储的session变量。

3、当执行PHP脚本时，通过使用session_register()函数注册session变量。

4、当PHP脚本执行结束时，未被销毁的session变量会被自动保存在本地一定路径下的session库中，这个路径可以通过php.ini文件中的session.save_path指定，下次浏览网页时可以加载使用。

参考资料：百度百科 ------ session

java全局会话的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java会话管理、java全局会话的信息别忘了在本站进行查找喔。