- 浏览: 273165 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
muyufenghua:
public static <T super B> ...
浅谈Java泛型中的extends和super关键字 -
wantodare:
class Test1 {
{
a=1;
}
pr ...
Java对象初始化详解 -
wubo2qml:
问下如何进行列中数字大小的比较。我看了几个过滤器,最接近的是S ...
利用Filter进行HBase查询 -
blackproof:
rowkey是A_B我知道要的A集合,也知道要的B范围不用自定 ...
利用Filter进行HBase查询 -
bin_1715575332:
文章不错,尤其了后半部分讲解一些原理。
利用Filter进行HBase查询
Improved Session Tracking
September 22, 2006
I recently discovered a better way to handle session tracking in web applications while dealing with complaints from the users of our application about session interference problems. Session tracking refers to the process of reassociating session data stored on the server with an incoming HTTP request. I will give an overview of existing session tracking strategies and explain their drawbacks. Following that discussion, I will present my solution.
A web container can use a couple of methods to associate an HTTP session with a sequence of user requests, all of which involve passing an identifier between the client and the server. Java servers typically use a token named JSESSIONID, while PHP uses PHPSESSID. The identifier can be maintained on the client as a cookie (known as cookie-based sessions) or the web container can include the identifier in every URL that is returned to the client (known as URL rewriting or encoding). Cookie-based sessions are particularly problematic with the Mozilla line of browsers since cookies which are set to expire at the end of the browsing session (session-scoped cookies) are shared amongst all windows and tabs for a single user profile. Internet Explorer (IE) segregates each window as a different browser session. Since IE doesn't have tabs to consider (at least prior to IE7), it doesn't have this isolation problem with session-scoped cookies. For browsers that do share session-scoped cookies, it is not possible to have multiple HTTP sessions without them interfering with each other.
When the application uses cookie-based sessions, depending on how session data is used, the user may see unexpected behavior when attempting to establish a new session in a separate window (or tab). A sample use case would be when the user wants to create a new session using different login credentials. If the application does not check for the presence of the existing session when the user tries to establish this new session, instead allowing the normal authentication logic to execute, the user may end up with a schizophrenic user principal that has a cocktail of roles and user information. Another approach the application could take is to automatically terminate the outstanding session, which leaves the original window (or tab) in an expired state, only to be discovered the next time the user activates a link or form in that window (or tab). In this case, the two tabs are stealing sessions from one another. The last method the application could take in handling the request is to restrict access to the login page if there is an outstanding session, preventing the user from establishing a second login all together. While this third scenario is the safest bet, none of these options are ideal for the user.
The alternative to cookie-based sessions is URL rewriting. In this strategy, every link or form is processed by the application, which inserts a session token into the URL, either as a query string parameter (PHP) or as a proprietary URL syntax (Java). Multiple tabs and windows no longer pose a problem with concurrent sessions because all the information necessary to reestablish the HTTP session during subsequent requests is stored in the URL, and hence completely isolated. If a request is made using a URL without this token, the application creates a brand new HTTP session and rewrites all the URLs sent in the response with this new identifier. While this strategy may sound like a sure winner over cookie-based session tracking, it has one rather severe security flaw. Since the information that identifies the user's session is now part of the URL, the session is completely portable. The URL can be copied from the browser location bar into and e-mail and sent over the internet to a recipient, who can then copy that URL into a browser window and access the session. You don't have to be a security expert to realize the risk in this scenario. This example doesn't even consider the less obvious risk of picking off session tokens in the URL sent over an insecure network with a traffic sniffer. Using this strategy out of the box is not recommended for anything other than development.
Fortunately, there is a third approach that would allow the use of URL rewriting in a secure manner. (To ensure maximum security in general, SSL should always be used). The trick is to lock a session to its originator. However, none of the request headers sent by the browser can satisfy the requirement of distinguishing one browser from all others. The most logical candidate, the remote IP address, does not work since it can be shared by users behind a firewall or proxy. After thinking about the Urchin Tracking Module (UTM) used by Google Analytics, it finally dawned on me that it is possible to uniquely identify a browser by using a cookie to assign a differentiating visitor identifier. This concept is similar to a MAC address for an ethernet card. The very first time that the application's URL is requested by a browser, interceptor code (for instance a servlet filter) calculates a long random string (the more random the better) and assigns this value to a permanent cookie in the browser. To make the cookie permanent, set it to expire several years in the future. The interceptor code also places this token into the newly created session to signify its originator. In Java, this is done by consulting the isNew() method on the HttpSession object and only binding the originator token to the session if this flag is true. On all subsequent requests for that session identifier, the value in the cookie is compared to the originator token in the session. If the two differ, the user is redirected appropriately, either to an error page or by stripping the session identifier from the URL, forcing the user to create a new session and thus login once again.
Even though a cookie is used in this strategy, it is a permanent one, and it is intended to be shared between tabs and windows. If you look at your browser's cookies, you will see that Google Statistics uses this approach to uniquely identify your browser so that it may track unique page hits with a cookie named __utma.
The proposed solution does, of course, require the use of cookies. If your application employs the URL rewriting strategy in order to avoid the use of cookies, this solution isn't going to work for you. As discussed above, such an approach is dangerous since it allows the URLs to be portable. Granted, when using SSL, the URL itself is ciphered, so at least it cannot be captured while going over the wire. From the outside, the only data that is visible to the world is the hostname and port. Cookies can also be marked as secure so that they are obscured as well.
As a final note, it may be necessary to ensure that the JSESSIONID cookie is removed from the client in order for the servlet container to prefer the URL rewriting approach.
Source:http://www.interaktonline.com/products/eclipse/jseclipse/installation-update/
September 22, 2006
I recently discovered a better way to handle session tracking in web applications while dealing with complaints from the users of our application about session interference problems. Session tracking refers to the process of reassociating session data stored on the server with an incoming HTTP request. I will give an overview of existing session tracking strategies and explain their drawbacks. Following that discussion, I will present my solution.
A web container can use a couple of methods to associate an HTTP session with a sequence of user requests, all of which involve passing an identifier between the client and the server. Java servers typically use a token named JSESSIONID, while PHP uses PHPSESSID. The identifier can be maintained on the client as a cookie (known as cookie-based sessions) or the web container can include the identifier in every URL that is returned to the client (known as URL rewriting or encoding). Cookie-based sessions are particularly problematic with the Mozilla line of browsers since cookies which are set to expire at the end of the browsing session (session-scoped cookies) are shared amongst all windows and tabs for a single user profile. Internet Explorer (IE) segregates each window as a different browser session. Since IE doesn't have tabs to consider (at least prior to IE7), it doesn't have this isolation problem with session-scoped cookies. For browsers that do share session-scoped cookies, it is not possible to have multiple HTTP sessions without them interfering with each other.
When the application uses cookie-based sessions, depending on how session data is used, the user may see unexpected behavior when attempting to establish a new session in a separate window (or tab). A sample use case would be when the user wants to create a new session using different login credentials. If the application does not check for the presence of the existing session when the user tries to establish this new session, instead allowing the normal authentication logic to execute, the user may end up with a schizophrenic user principal that has a cocktail of roles and user information. Another approach the application could take is to automatically terminate the outstanding session, which leaves the original window (or tab) in an expired state, only to be discovered the next time the user activates a link or form in that window (or tab). In this case, the two tabs are stealing sessions from one another. The last method the application could take in handling the request is to restrict access to the login page if there is an outstanding session, preventing the user from establishing a second login all together. While this third scenario is the safest bet, none of these options are ideal for the user.
The alternative to cookie-based sessions is URL rewriting. In this strategy, every link or form is processed by the application, which inserts a session token into the URL, either as a query string parameter (PHP) or as a proprietary URL syntax (Java). Multiple tabs and windows no longer pose a problem with concurrent sessions because all the information necessary to reestablish the HTTP session during subsequent requests is stored in the URL, and hence completely isolated. If a request is made using a URL without this token, the application creates a brand new HTTP session and rewrites all the URLs sent in the response with this new identifier. While this strategy may sound like a sure winner over cookie-based session tracking, it has one rather severe security flaw. Since the information that identifies the user's session is now part of the URL, the session is completely portable. The URL can be copied from the browser location bar into and e-mail and sent over the internet to a recipient, who can then copy that URL into a browser window and access the session. You don't have to be a security expert to realize the risk in this scenario. This example doesn't even consider the less obvious risk of picking off session tokens in the URL sent over an insecure network with a traffic sniffer. Using this strategy out of the box is not recommended for anything other than development.
Fortunately, there is a third approach that would allow the use of URL rewriting in a secure manner. (To ensure maximum security in general, SSL should always be used). The trick is to lock a session to its originator. However, none of the request headers sent by the browser can satisfy the requirement of distinguishing one browser from all others. The most logical candidate, the remote IP address, does not work since it can be shared by users behind a firewall or proxy. After thinking about the Urchin Tracking Module (UTM) used by Google Analytics, it finally dawned on me that it is possible to uniquely identify a browser by using a cookie to assign a differentiating visitor identifier. This concept is similar to a MAC address for an ethernet card. The very first time that the application's URL is requested by a browser, interceptor code (for instance a servlet filter) calculates a long random string (the more random the better) and assigns this value to a permanent cookie in the browser. To make the cookie permanent, set it to expire several years in the future. The interceptor code also places this token into the newly created session to signify its originator. In Java, this is done by consulting the isNew() method on the HttpSession object and only binding the originator token to the session if this flag is true. On all subsequent requests for that session identifier, the value in the cookie is compared to the originator token in the session. If the two differ, the user is redirected appropriately, either to an error page or by stripping the session identifier from the URL, forcing the user to create a new session and thus login once again.
Even though a cookie is used in this strategy, it is a permanent one, and it is intended to be shared between tabs and windows. If you look at your browser's cookies, you will see that Google Statistics uses this approach to uniquely identify your browser so that it may track unique page hits with a cookie named __utma.
The proposed solution does, of course, require the use of cookies. If your application employs the URL rewriting strategy in order to avoid the use of cookies, this solution isn't going to work for you. As discussed above, such an approach is dangerous since it allows the URLs to be portable. Granted, when using SSL, the URL itself is ciphered, so at least it cannot be captured while going over the wire. From the outside, the only data that is visible to the world is the hostname and port. Cookies can also be marked as secure so that they are obscured as well.
As a final note, it may be necessary to ensure that the JSESSIONID cookie is removed from the client in order for the servlet container to prefer the URL rewriting approach.
Source:http://www.interaktonline.com/products/eclipse/jseclipse/installation-update/
发表评论
-
Servlet 3.0新特性
2011-03-11 13:12 1377Servlet 3.0中最主要的两个新特性总结如下: 改变了 ... -
Java中wait与notify方法的使用
2010-05-22 14:09 9492在java多线程编程中 ... -
MySql批量插入数据
2010-04-05 15:55 10672在实际的开发过程中,特别是大型的分布式应用系统,往往会涉 ... -
去掉对Spring BeanFacotry的getBean方法的依赖
2009-12-27 23:52 2738在使用Spring时,有时会碰到这种情况: 引用需要在 ... -
通过HttpServletRequestWrapper解决Tomcat请求乱码问题
2009-11-16 23:08 2281应用一:解决tomcat下中文乱码问题(先来个简单的) 在t ... -
相对路径获取Tomcat Web容器中的资源
2009-08-20 21:36 14457最近做项目碰到个问题,我需要利用velocity模版来渲染 ... -
Jboss是数据源配置
2009-08-16 15:38 2042配置Jboss的数据源非常简单,可以从$JBOSS_HOME\ ... -
Jboss 4.x 端口及其修改
2009-08-07 14:49 2848注:本文中所述内容适合于Jboss 4.x系列应用服务器。 ... -
JBOSS共享安装
2009-08-07 14:36 1945本文内容适合于Jboss 4.x系列应用服务器。 在项目中, ... -
Tomcat热部署
2009-06-24 20:33 3814使用过tomcat的人都知道 ... -
jsessionid存在的问题及其解决方案
2009-06-24 00:29 3179jsessionid是Java Web Server( ... -
tomcat数据库连接池设置
2009-06-23 16:56 14441.Tomcat中的设置 2.我的工作目录在c:\eclip ... -
ORA-12514:TNS:监听程序当前无法识别连接描述符中请求的服务
2009-06-23 16:47 25281. 首先查看tnsnames.ora ... -
webwork type等于redirect时的参数传递
2009-06-23 02:09 2161Webwork在使用result类型为redirect时,将会 ... -
js跨域问题小结
2009-06-11 15:43 1739js跨域问题小结 javascript出于安全方面的考虑,是不 ... -
Spring共享上下文机制
2009-05-19 15:53 3864对于Spring应用程序上下文的引用基本有两种形式 ... -
webwork result type之redirect&redirect-action
2009-05-09 17:49 3234可能大家都知道在webwork里面如果想重定向到另外一个 ... -
使用javascirpt获取JSON格式的日期
2009-05-08 14:00 1997在用json-lib里的net.sf.json.JSONO ... -
JQuery JSON异步请求中文乱码问题
2009-05-08 13:48 15867最近在用Jquery的getJSON方法进行AJAX异步调 ... -
webwork-2.1.7与Spring2.0整合
2009-05-03 14:00 1471这里使用随webwork2.2发布的ActionAutowir ...
相关推荐
标题《Improved Recurrent Neural Networks for Session-based Recommendations》指向了一项与基于会话推荐系统相关的研究工作,该工作通过改进递归神经网络(RNN)模型来提升性能。RNN是一种深度学习模型,特别适用...
Visual tracking remains a highly active area of research in Computer Vision and the performance under complex scenarios has substantially improved, driven by the high demand in connection with real-...
人脸识别分类器,基于lbp的lbpcascade_frontalface_improved.xml
### OpenCV Blob: An Improved Adaptive Background Mixture Model for Real-Time Tracking with Shadow Detection #### 引言 背景减法是图像序列中实时分割移动区域的基本步骤,在自动化视觉监控、人机界面以及极...
**wget-improved:一个增强版的前端开源库** 在前端开发中,经常需要与服务器进行数据交互,获取静态资源或动态内容。`wget-improved`是`wget`命令的一个优化版本,特别针对Node.js环境进行了改良,以适应前端...
Improved Denoising Diffusion Probabilistic Models Improved Denoising Diffusion Probabilistic Models(DDPM)是一类生成模型,它最近被证明可以生成高质量的样本。 DDPMs 通过学习反向扩散过程的方差,可以以...
Covariance matrices have recently been a popular choice for versatile tasks like recognition and tracking due to their powerful ...ing demonstrating improved performance compared to covariance tracking.
### Vi Improved: Key Vim Knowledge Points #### **一、引言** `vi_improved.pdf`作为学习Vim编辑器的必备书籍之一,被视为官方参考书目。本书内容详尽且条理清晰,适合初学者和进阶用户查阅。下面将根据本书的...
**vim_iMproved** 《vim_iMproved》是一本由vim编辑器的作者精心编写的书籍,旨在深入探讨和解析vim的使用技巧和高级功能。vim,全称Vi IMproved,是从经典的vi编辑器发展而来的强大学习工具,尤其在程序员和系统...
It is an improved version of the vi editor distributed with most UNIX systems. Vim is often called a "programmer's editor," and so useful for programming that many consider it an entire IDE. It's ...
2018 Improved Techniques for Learning to Dehaze and Beyond_ A Collective Study
当前的人脸特征点定位跟踪方法因其计算量大,实时特性欠佳。给出了一种基于改进Viola-Jones算法和Kalman滤波器预测机制的定位及跟踪算法。该算法通过使用改进的Viola-Jones算法对本次人脸特征点进行定位,同时使用...
improved_wgan_training, 在"Improved Training of Wasserstein GANs" 中,用于复制实验的代码 改进 Wasserstein GANs的训练在 "改进 Wasserstein GANs的训练"中复制实验的代码。先决条件python,NumPy,TensorFlow...
《Vi-iMproved使用学习全集》是一本深入探讨Vim编辑器的全面教程,旨在帮助用户掌握这一强大工具的所有核心功能和高级技巧。Vim,全称Vi IMproved,是经典的Vi编辑器的增强版,它在保留Vi原有特性的同时,引入了更多...
Optimizing Java Practical Techniques for Improved 完整版,不是early release