session的信息放在那（tomcat）

Posted 2023-04-06

sessionID是干什么用的。
能详细描述一下吗
Session的信息放在服务器的什么地方

IE中:
有效的窗品包括
1.Session对象只在建立Session对象的窗口中有效。
2.在建立Session对象的窗口中新开链接的窗口

无效的窗口包括
1.直接启动IE浏览器的窗口
2.不是在建立Session对象的窗口中新开链接的窗口

NetScape中：
只要一个窗口有了某个Session对象，则全部窗口对此Session都有效
Session是什么呢？简单来说就是服务器给客户端的一个编号。当一台WWW服务器运行时，可能有若干个用户浏览正在运正在这台服务器上的网站。当每个用户首次与这台WWW服务器建立连接时，他就与这个服务器建立了一个Session，同时服务器会自动为其分配一个SessionID，用以标识这个用户的唯一身份。这个SessionID是由WWW服务器随机产生的一个由24个字符组成的字符串，我们会在下面的实验中见到它的实际样子。

这个唯一的SessionID是有很大的实际意义的。当一个用户提交了表单时，浏览器会将用户的SessionID自动附加在HTTP头信息中，（这是浏览器的自动功能，用户不会察觉到），当服务器处理完这个表单后，将结果返回给SessionID所对应的用户。试想，如果没有SessionID，当有两个用户同时进行注册时，服务器怎样才能知道到底是哪个用户提交了哪个表单呢。当然，SessionID还有很多其他的作用，我们会在后面提及到。

除了SessionID，在每个Session中还包含很多其他信息。但是对于编写ASP或ASP.NET的程序与来说，最有用的还是可以通过访问ASP/ASP.NET的内置Session对象，为每个用户存储各自的信息。例如我们想了解一下访问我们网站的用户浏览了几个页面，我们可能在用户可能访问到每个的页面中加入：

<%
If Session("PageViewed") = ""Then
Session("PageViewed") = 1
Else
Session("PageViewed") = Session("PageViewed") + 1
End If
%>
通过以下这句话可以让用户得知自己浏览了几个页面：

<%
Response.Write("You have viewed " & Session("PageViewed") & " pages")
%>

可能有些有些读者会问：这个看似像是数组的Session(“..”)是哪里来的？需要我定义吗？实际上，这个Session对象是具有ASP解释能力的的WWW服务器的内建对象。也就是说ASP的系统中已经给你定义好了这个对象，你只需要使用就行了。其中Session(“..”)中的..就好像变量名称，Session(“..”)=$$中的$$就是变量的值了。你只需要写上句话，在这个用户的每个页面中都可以访问..变量中的值了。

其实ASP一共内建了7个对象，有Session、Application、Cookie、Response、Request、Server等。在其他的服务器端脚本语言如JSP、php等中也有其类似的对象，只是叫法或者使用方法上不太一样。

ASP Session的功能的缺陷
目前ASP的开发人员都正在使用Session这一强大的功能，但是在他们使用的过程中却发现了ASP Session有以下缺陷：

进程依赖性：ASP Session状态存于IIS的进程中，也就是inetinfo.exe这个程序。所以当inetinfo.exe进程崩溃时，这些信息也就丢失。另外，重起或者关闭IIS服务都会造成信息的丢失。
Session状态使用范围的局限性：刚一个用户从一个网站访问到另外一个网站时，这些Session信息并不会随之迁移过去。例如：新浪网站的WWW服务器可能不止一个，一个用户登录之后要去各个频道浏览，但是每个频道都在不同的服务器上，如果想在这些WWW服务器共享Session信息怎么办呢？
Cookie的依赖性：实际上客户端的Session信息是存储与Cookie中的，如果客户端完全禁用掉了Cookie功能，他也就不能享受到了Session提供的功能了。
鉴于ASP Session的以上缺陷，微软的设计者们在设计开发 ASP.NET Session时进行了相应的改进，完全克服了以上缺陷，使得ASP.NET Session成为了一个更加强大的功能。

Web.config文件简介
有的ASP.NET程序员说：Web.config文件？我从来没有听说过啊，可是我写的程序不是也能很正常的运转吗？是的，你说得没错，没有Web.config文件程序是可以正常运行的。但是，如果你做了一个大型的网站，需要对整个网站做一些整体配置，例如整个网站的页面使用何种语言编写的、网站的安全认证模式、Session信息存储方式等，这时你就需要使用Web.config文件了。虽然Web.config文件中的某些选项是可以通过IIS配置的，但是如果在Web.config中也有相应的设置就会覆盖掉IIS中的配置。而且，Web.config文件的最大的便利之处就是可以在ASP.NET页面中通过调用System.web名字空间访问Web.config中的设置。

Web.config有两种，分别是服务器配置文件和Web应用程序配置文件，他们都名为Web.config。在这个配置文件中会保存当前IIS服务器中网页的使用哪种语言编写的、应用程序安全认证模式、Session信息存储方式的一系列信息。这些信息是使用XML语法保存的，如果想对其编辑，使用文本编辑器就行了。

其中服务器配置文件会对IIS服务器下所有的站点中的所有应用程序起作用。在.NET Framework 1.0中，服务器的Web.config文件是存在：\WinNT\Microsoft.NET\Framework\v1.0.3705中的。

而Web应用程序配置文件Web.config则保存在各个Web应用程序中。例如：当前网站的根目录\Inetpub\wwwroot，而当前的Web应用程序为MyApplication，则Web应用程序根目录就应为：\Inetpub\wwwroot\MyApplication。如果你的网站有且只有一个Web应用程序，一般说来应用程序的根目录就是\Inetpub\wwwroot。如果想添加一个Web应用程序，在IIS中添加一个具有应用程序起始点的虚拟目录就行了。这个目录下的文件及目录将被视为一个Web应用程序。但是，这样通过IIS添加Web应用程序是不会为你生成Web.config文件的。如果想创建一个带有Web.config文件的Web应用程序，需要使用Visual Studio.NET，新建一个Web应用程序项目。

Web应用程序的配置文件Web.config是可选的，可有可无。如果没有，每个Web应用程序会使用服务器的Web.config配置文件。如果有，则会覆盖服务器Web.config配置文件中相应的值。

在ASP.NET中，Web.config修改保存后会自动立刻成效，不用再像ASP中的配置文件修改后需要重新启动Web应用程序才能生效了。 参考技术A Session的信息放在服务器。
sessionID就相当于一台机器对应服务器这台机器session的一个账号。
用个我们老师的例子：sessionID就相当与病例，服务器就相当于医院。 参考技术B Session用来追踪每个用户的会话，使用服务器生成的SessionID进行标识，用以区分用户。Session存放在服务器的内存中，SessionID存放在服务器内存和客户机的Cookie里面。这样，当用户发出请求时，服务器将用户Cookie里面记录的SessionID和服务器内存中的SessionID进行比对，从而找到这个用户对应的Session进行操作。所以，如果客户机禁止Cookie的话，Session也不能使用，但是对于JSP来说(.NET不熟悉)，会使用URL重写的技术，在URL里面附加上SessionID，从而实现用户身份的标识。本回答被提问者采纳

跨域跨服务器调用时候session丢失的问题

最近新进一个公司，做的项目是手机支付系统。由于涉及到金钱相关的，所以安全性要求特别的高。项目分了很多个子系统，在部署（测试）的时候是每个Tomcat上面只放一个子系统。比如现在有5个子系统，那么就会对应5个Tomcat启动了放在linux上面的。为什么这么做？试想如果在上线以后，如果其中一个系统有问题要重启服务器，5个子系统都放在一起的话，那不是全部都会跟着重启了！现在说说我们遇到的问题了。

用户登录后，在管理子系统，有一个充值连接，会跳到充值子系统去充值。这样跨JVM的跳转只能用redirect来跳，但是用户自己的登录状态就会丢失了（登录session丢失）。后来改为forward跳转到自己的jsp页面，然后在form提交到充值子系统去充值。在本地开发测试的时候session是不会丢失的，但是发布到linux下面的Tomcat就会丢失。找了各种原因都以为是操作系统差异的问题。

后来发现一个这样的区别，开发测试是两个IP不同的端口号的跳转，发布到linux上面测试是同一个IP不同的端口号的跳转。这样涉及到对浏览器session和cookies的了解程度拉。

首先session是存放在容器里面的，而且一次会话的session会生成一个jsessionid，在管理session的时候是根据jsessionid去寻找，能找到就不会创建新的session，找不到才创建新的session，确定这才是一次新的会话。而cookies是存放在客户端的文件。jsessionid也会放到cookies里面。

两个IP、两个端口就会有两个session、两个cookies这样session是会丢失的。首先在管理子系统第一次登录会生成一个jsessionid，在一个cookies里面去是找不到这个session的。就会创建登录成功的session。然后跳转到充值子系统，也会在充值子系统生成一个jsessionid，到另一个cookies里面去找这个session也是找不到的，也会创建一个session。以前的session就这样丢失拉。

一个IP、两个端口就会有两个session、一个cookies这样session也是会丢失的。首先在管理子系统第一次登录会生成一个jsessionid，在cookies里面去是找不到这个session的。就会创建登录成功的session。然后跳转到充值子系统，也会在充值子系统生成一个jsessionid，到同样这个cookies里面去找这个session也是找不到的，也会创建一个session覆盖以前的session。

解决把法就是不让jsessionid自动生成，放到cookies里面。而是在url里面传递jsessionid，不用靠cookies。说通俗点这个就叫url重写。

这样在管理系统第一次登录会生成一个jsessionid，创建登录session。当到充值系统的时候我会把jsessionid传过去那边也会生成一个session。意思就是两个容器各自生成了各自的session，但是共用的同一个jsessionid。这样每次到容器里面去取session内容都是根据同一个jsessionid去取，如果创建过的话。里面肯定是能拿到的。但是里面的内容各自创建的又不一样。这样session就不会丢失老！！！

要让url重写有很多方法，比如：

<c:url value=""/>

response.encodeRedirectUrl("");
response.encodeUrl("");

等多种方法。但要让cookies里面的jsessionid不被使用就需要浏览器完全禁用cookies等。还有个简单的方法就是在Tomcat里面配置：

tomcat_home/conf/context.xml里面把<Context>改为<Context cookies = "false">这样就好拉！！！

然后url就会自动变成这个样子：

http://127.0.0.1:8080/login.do;jsessionid=66B0A8E2B78940C7B1BB16ABB8E0D3E9?method=toLogin