问道session_id或sessionid_v1.0.0

最新推荐文章于 2024-06-21 17:36:45 发布

原创最新推荐文章于 2024-06-21 17:36:45 发布 · 215 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#session原理 #session_id #会话 #服务端存储 #前后端交互

技术栈-安全-接口安全专栏收录该内容

2 篇文章

订阅专栏

本文深入探讨JSessionID的工作原理及应用场景，包括其在登录过程中的作用、如何通过浏览器获取及跟踪，以及在不同请求间的变化情况。同时，还介绍了禁用cookie时的URL重写策略。

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

v1.0.0
token、jwt、oauth2标准，统统都玩腻了？不是。那为什么突然调研session？因为也很重要呀。

文章目录

- 开始
- - - 登录原理
    - jsessionid

开始

登录原理

git clone https://gitee.com/lcg0124/bootdo

sql
启动
登录成功

jsessionid

使用Chrome浏览器，按F12,随便点一个接口，观察XHR，找到刚才访问的接口，找到请求头，找到cookie，记住cookie里的jsessionid

Cookie: csrftoken=v4a4CLBKD7CxSsPf66qmph2e2MPU6xmpPZ142dBg8Dh4q0pa0ynOeA9wwmHAtZOW;
JSESSIONID=e3baf1ce-3d08-4601-8f90-444b984638c1;
NG_TRANSLATE_LANG_KEY=%22en%22

再访问另一个接口，继续观察jsessionid：

Cookie: csrftoken=v4a4CLBKD7CxSsPf66qmph2e2MPU6xmpPZ142dBg8Dh4q0pa0ynOeA9wwmHAtZOW; 
JSESSIONID=e3baf1ce-3d08-4601-8f90-444b984638c1; 
NG_TRANSLATE_LANG_KEY=%22en%22

是一样的。
退出
再登录
再调接口，
访问一个裸奔的接口，也就是不需要授权就能访问的接口，观察发现没有jsessionid了：

Cookie: csrftoken=v4a4CLBKD7CxSsPf66qmph2e2MPU6xmpPZ142dBg8Dh4q0pa0ynOeA9wwmHAtZOW; 
NG_TRANSLATE_LANG_KEY=%22en%22

裸奔配置：

ShiroFilterFactoryBean shiroFilterFactoryBean(SecurityManager securityManager) {
ShiroFilterFactoryBean shiroFilterFactoryBean = new ShiroFilterFactoryBean();
        shiroFilterFactoryBean.setSecurityManager(securityManager);
        shiroFilterFactoryBean.setLoginUrl("/login");
        shiroFilterFactoryBean.setSuccessUrl("/index");
        shiroFilterFactoryBean.setUnauthorizedUrl("/403");
        LinkedHashMap<String, String> filterChainDefinitionMap = new LinkedHashMap<>();
filterChainDefinitionMap.put("/blog", "anon");
shiroFilterFactoryBean.setFilterChainDefinitionMap(filterChainDefinitionMap);
return shiroFilterFactoryBean;

到登录页面，查看验证码接口，是img的，观察jsessionid：

Cookie: csrftoken=v4a4CLBKD7CxSsPf66qmph2e2MPU6xmpPZ142dBg8Dh4q0pa0ynOeA9wwmHAtZOW; 
NG_TRANSLATE_LANG_KEY=%22en%22; 
JSESSIONID=51918ca9-0872-4373-8dc9-e871a11da7f8

与上文的id不一样了，再观察id的结构，——应该是个uuid。
说明uuid有被删除的可能，多次刷新登录页面，发现该uuid没有变，那么触发删除大概是在logout的时候了。
从英文单词可以看出它叫会话（session），那么关闭当前页面，重新打开，看下id会变不，发现没变，那么关闭浏览器再打开试试，注意，用同一个浏览器，还是查看图片验证码接口，发现id不见了：
在这里插入图片描述
是不是还没设置到cookie？于是观察响应头，果然：

哈？原来这个id是后台返回的呀。当然了，session嘛，当然是服务端session呀。
在任意请求添加这句代码：

System.out.println(String.format("jsessionid == %s", session.getId()));

out:
在这里插入图片描述
打开一个新tab页（id不变），或者换一个浏览器（不一样了）观察jsessionid。
登录成功，关闭浏览器，重新打开浏览器，直接访问首页，是不是登录失效了？为什么？既然叫session嘛，会话，会话取消了，就中断退出了呀。当然，这里还与过期时间有关，如果有印象的话，你应该记得过期日期是1970.
服务端是如何取得cookie里的jsessionid的？tomcat服务端可以操作cookie，并从中获得id，前提是cookie里有传，这一点也类似后来发展起来的无状态token访问。
禁用了cookie咋办？url重写，将jsessionid写到url。