session深刻探讨

简介

       session,会话,实际上是一个容易让人误解的词。它总跟web系统的会话挂钩,利用session,javaweb项目实现了登陆状态的控制。坊间流传,关闭浏览器,就是关闭了web系统的会话。其实浏览器对于会话有本身的定义,而web系统对于会话也有本身的定义。在tomcat中,session一般是指实现了HttpSession接口的实现类。而且不存在关闭浏览器就会关闭tomcat的HttpSession这种情况。 java

       session自己并不难,若是只是作登陆校验之类的功能,并不须要深刻了解,但难的是session和cookie的结合使用,在不一样状况下浏览器对cookie的控制行为所涉及到的诸多细节,我搜查了不少资料,查看过tomcat源码,亦是没有找到全面的概述。固然我并未看过、也不知道去哪里看比较全面的关于浏览器对cookie的控制资料,若是有知道的大神,还望留言连接。本文题目,之因此说是探讨,而不是了解或者介绍,由于我本身也卡在了某个点上,因为时间关系,我不能花太多时间去研究,但又不忍心就此放弃,因此先记录下来,往后有机会再研究,这期间若有大神指点,也许能让我茅塞顿开。web

(本文来自开源中国,做者:千里明月 ,连接:https://my.oschina.net/u/3490860/blog/write/2986928)apache

session本质

        我用的是javaweb项目,所以这里的session特指HttpSession。先来看下tomcat源码中对session的设计,在org.apache.catalina.session包下,有以下设计:跨域

平时所用到的HttpSession的实现类就是这个standardSession。可是所获取的HttpSession实例确是外观类StandardSessionFacade,其屏蔽了许多方法,但也加强了安全性。HttpSession提供了一些方法,来控制session或者获取session的状态,如获取session的id,获取session的建立时间,设置session的attribute,使session失效等。值得一提的是session的attribute实际上是一个线程安全的hashMap:浏览器

/**
     * The collection of user data attributes associated with this Session.
     */
    protected ConcurrentMap<String, Object> attributes = new ConcurrentHashMap<>();

可是,建立session、根据id获取session的方法并不在这里,而是在一个管理器中,其设计以下:tomcat

ManagerBase是实现了Manager接口的抽象类,实现了管理session的功能。其实现子类PersistentManagerBase拓展了将session持久化的功能。可是这里不须要讲到其子类。看ManagerBase中的一段代码:安全

/**
     * The set of currently active Sessions for this Manager, keyed by
     * session identifier.
     */
    protected Map<String, Session> sessions = new ConcurrentHashMap<>();

由此可知,所谓的session,其实就是一个用线程安全的hashMap存储起来的实现了Session接口的standardSession对象,在hashmap中以其id为key,自身为value。服务器

再看获取session的方法,一目了然:cookie

@Override
    public Session findSession(String id) throws IOException {
        if (id == null) {
            return null;
        }
        return sessions.get(id);
    }

最重要的是看其createSession方法:session

@Override
    public Session createSession(String sessionId) {

        if ((maxActiveSessions >= 0) &&
                (getActiveSessions() >= maxActiveSessions)) {
            rejectedSessions++;
            throw new TooManyActiveSessionsException(
                    sm.getString("managerBase.createSession.ise"),
                    maxActiveSessions);
        }

        // Recycle or create a Session instance
        Session session = createEmptySession();

        // Initialize the properties of the new session and return it
        session.setNew(true);
        session.setValid(true);
        session.setCreationTime(System.currentTimeMillis());
        session.setMaxInactiveInterval(getContext().getSessionTimeout() * 60);
        String id = sessionId;
        if (id == null) {
            id = generateSessionId();
        }
        session.setId(id);
        sessionCounter++;

        SessionTiming timing = new SessionTiming(session.getCreationTime(), 0);
        synchronized (sessionCreationTiming) {
            sessionCreationTiming.add(timing);
            sessionCreationTiming.poll();
        }
        return session;
    }

这个方法是在何时调用的呢?当浏览器访问系统时,request会解析请求中携带的jssesionid,用它去找到存在于应用中的session,可是若是没有找到,那么就会调用session的建立方法,而且生成一个新的jssessionid,返回session。

总而言之,session是存在于线程安全的map中的值,能够经过id找到,也可使用invalidate方法销毁,但毫不会是浏览器关闭,就能对它进行销毁的。

cookie简介

        提到session,那么cookie是不得不说的。至于cookie是什么,我就很少说了,你们都懂。直接看其内容吧:

这是一次http请求中(http://localhost:8080/test1),包含的请求和响应信息,是对一个系统的初次访问,用的是谷歌浏览器。

请求头中,包含的Cookie信息,并无上文提到的jsessionid, 那是由于这是对系统的初次访问,系统还没生成session。可是访问以后,系统就会生成一个session,并且,会在响应流中设置响应头Set-Cookie,其值为JESSIONID=xxx。这样浏览器对localhost:8080和cookie的联系就有了记忆,浏览器会将其存储起来,可在调试工具中看到:

那么再次访问http://localhost:8080/test1, 浏览器会主动在请求头添加包括jsession的cookie信息

系统根据这个jsessionid找到session,也就不会在响应头中添加Set-Cookie信息。

这里说一下cookie中的两个重要属性:

  1. domain表示的是cookie所在的域,默认为请求的地址,如网址为www.test.com/test/test.aspx,那么domain默认为www.test.com。而跨域访问,如域A为t1.test.com,域B为t2.test.com,那么在域A生产一个令域A和域B都能访问的cookie就要将该cookie的domain设置为.test.com;若是要在域A生产一个令域A不能访问而域B能访问的cookie就要将该cookie的domain设置为t2.test.com。

  2. path表示cookie所在的目录,默认为/,就是根目录。在同一个服务器上有目录以下:/test/,/test/cd/,/test/dd/,现设一个cookie1的path为/test/,cookie2的path为/test/cd/,那么test下的全部页面均可以访问到cookie1,而/test/和/test/dd/的子页面不能访问cookie2。这是由于cookie能让其path路径下的页面访问。

疑点

        下面,就该说下个人疑点了。

状况1:

        可是当我在8081的一个方法中,重定向到8080的一个路径时,发现了奇怪的现象。

8081系统的方法以下:

@GetMapping("/test")
    public void get1(HttpServletRequest request, HttpServletResponse response) throws IOException {
        HttpSession session = request.getSession();
        String id = session.getId();
        System.out.println(id);
        response.sendRedirect("http://localhost:8080/test1");
    }

8080系统的被重定向路径以下:

@GetMapping("/test1")
    public void get11(HttpServletRequest request, HttpServletResponse response) throws IOException {
        HttpSession session = request.getSession();
        String id = session.getId();
        System.out.println(id);
    }

一、初次访问localhost:8081/test 获得两次请求的信息,一次是重定向的,一次是8080的

这说明对8081系统的初次访问,是没有发送jsessionid信息的,而8081系统生成了一个id为CAAB6AED34716A0394705BDE8CAC0042的session并设置到了响应头,再次访问8081时理应会带上这么一个id。

二、

这个对8080系统的请求中带有jsessionid为CAAB6AED34716A0394705BDE8CAC0042的cookie信息,要知道,咱们对8080的访问也是初次的,那么为何会带上jsessionid呢?并且这个jsessionid明显是在8081系统中生成并设置到响应头的的jsessionid。这个现象我用谷歌和edge浏览器分别尝试过,都是这样。那么是否是说明,浏览器把这个重定向到localhost:8080的请求当成是同域的请求了 。

暂且放下这个疑惑,继续往下验证。因为这个请求是对8080的系统的访问,因为是初次访问,系统根本没有id为CAAB6AED34716A0394705BDE8CAC0042的session,所以只好生成一个新的session,在响应头中增长Set-Cookie。

三、再次访问localhost:8081/test,这时根据上文说的,“再次访问8081时理应会带上这么一个id”,也就是在cookie中带上JSESSION=CAAB6AED34716A0394705BDE8CAC0042,  可是,我发现它带的倒是在系统8080中生成的BA0D2C939ADEC087C0A5F0C9B3354891 !!!

这就致使了8081找不到session又再次生成了一个新的session,循环往复,每次对8081的访问都会产生新的session。而这状况,我以为很明显,是浏览器把对8081的访问当成是于8080同源的了。

基于此推论,我模拟了另外一种实验状况,去掉重定向的功能

状况2:

在本地开两个web服务,端口分别是8080,8081。

localhost:8081/test

@GetMapping("/test")
    public void get1(HttpServletRequest request, HttpServletResponse response) throws IOException {
        HttpSession session = request.getSession();
        String id = session.getId();
        System.out.println(id);

    }

localhost:8080/test1

@GetMapping("/test1")
    public void get11(HttpServletRequest request, HttpServletResponse response) throws IOException {
        HttpSession session = request.getSession();
        String id = session.getId();
        System.out.println(id);
    }

一、第一次访问8081/test

没有cookie,服务器设置set-cookie,正常。

二、第二次访问8081/test

cookie与上次的set-cookie一致,正常。

三、第一次访问8080/test1

浏览器把8081/test的cookie发过去了。8080的服务器找不到这个jsessionid,又从新设置了jsessionid,等到再次访问8081/test时,你们也能猜到会发生什么了吧。

推论

至此,我斗胆推论,浏览器会对同一ip不一样端口的服务访问认定是能够进行cookie共享的,两个cookie的domain是一致的。而这种cookie的截图也必定程度上印证了个人想法:

cookie的domain彷佛只认定域名,无关端口。

可是根据浏览器的同源策略,同域名不一样端口的访问也应该是跨域的啊。除非浏览器的域跟cookie的domain在概念上是有区别的,对于这点,我没找到确切的官方资料,但网上大神是这么说的——

解决方案

        基于上面的未查阅官方资料而作出的不严谨的推论,我想,只要彻底避免同域的状况就能够避开这个问题。因而我把8081和8080系统分别部署在两个机器上。因为不一样ip,这样不管如何,两个cookie都不会是同domain的了。果真,结果是没有问题的。

不足

        虽然这个解决方案避开了同域的问题,可是没有完全解决,毕竟同域的系统相互之间的访问也是有必要的,为此但愿能得到更多的建议或者资料,补充这方面知识的不足,让我完全解决这个问题。

 

老板说我长得很帅,给我发红包了!我以为你们都很帅,我要分享给你们,欢迎扫码领红包——

相关文章
相关标签/搜索