Session,cookie,jsessionid,url rewrite

In some polls and the like, we tend to ask everyone to vote only for the principle of fairness, in some web development there are similar situations, we usually use cookies, such as the following code:

<% Cookie[]cookies = Request.getcookies ();

if (Cookies.lenght = = 0 | | | cookies = NULL) {

Dostufffornewbie ();

has not been visited

}else{

Dostuffforreturnvisitor (); I've already visited it.

}

% >

This is very easy to understand, to detect the existence of a cookie, if there is a description has been run to write the cookie code, but after running the above code, whenever the results are executed dostuffforreturnvisitor (), Through the Control Panel-internet options-Settings-view file but always do not see the generated cookie file, strange, the code is clearly not a problem, but since there is a cookie, then show it.

Cookie[]cookies = Request.getcookies ();

if (Cookies.lenght = = 0 | | | cookies = NULL)

Out.println ("Have not visited this website");

}else{

for (int i = 0; i < cookie.length; i++) {

OUT.PRINTLN ("Cookie name:" + cookies[i].getname () + "cookie value:" +

Cookie[i].getvalue ());

}

}

Operation Result:

Cookie Name:jsessionid Cookie Value:kwjhug6jjm65hs2k6

Why is there a cookie, as we all know, HTTP is a stateless protocol, every time a customer reads a Web page, the server opens a new session, and the server does not automatically maintain the customer's contextual information, then how to implement the shopping cart in the online store, Session is a mechanism to save context information, it is for each user, the value of the variable is stored on the server side, through the sessionid to distinguish between different customers, the session is based on cookie or URL rewrite, the default use of cookies to achieve, The system creates an output cookie called Jsessionid, which we call a session cookie to distinguish between persistent cookies, which is what we normally call cookies, notice the session Cookies are stored in the browser memory, not written to the hard disk, which is the jsessionid we have just seen, we usually do not see jsessionid, but when we disable the browser cookie, The Web server passes SessionID in a URL rewrite, so we can see strings like sessionid=kwjhug6jjm65hs2k6 in the address bar.

Understanding the principle, we can easily distinguish between persistent cookies and session cookies, the online discussion on the security of the two is also clear, session cookie for a session, sessions end The cookie disappears, and the persistent cookie is just a piece of text (usually encrypted) that exists on the client's hard drive, and may be subject to cookie spoofing and cross-site scripting attacks against cookies, which are not as secure as session cookies.

Usually the session cookie is not used across windows, and when you open a new browser window into the same page, the system will give you a new SessionID, so that the purpose of our information sharing is not reached, At this point we can first save the SessionID in the persistent cookie, and then read it in a new window, we can get the previous window SessionID, so through the session cookie and persistent The combination of cookies allows us to implement a cross-window session tracking (conversation tracking).

In some Web development books, the session and cookie are often simply used as two kinds of parallel HTTP transmission information, session cookies located on the server side, the persistent cookie is located on the client, But the session is based on a cookie, understand the relationship between the two and the difference, we will not be difficult to choose the right technology to develop Web service.

Differences and linkages between cookies and session mechanisms

Specifically, the cookie mechanism uses a scheme that maintains state on the client. It is the storage mechanism of session state on the client side, and he needs the user to open the cookie support of the clients. The purpose of cookies is to resolve the problem of stateless defects in the HTTP protocol.

The session mechanism uses a solution that maintains state between the client and the server. At the same time, we also see that because of the server-side hold state of the scheme in the client also need to save an identity, so the session mechanism may need to use the cookie mechanism to achieve the purpose of preserving the identity. The session provides a convenient way to manage global variables

Session is for each user, the value of the variable is saved on the server, with a sessionid to distinguish which user session variable, this value is accessed by the user's browser when the server is returned, when the customer disables the cookie, This value may also be set to be returned to the server by get.

As far as security is concerned: when you visit a site that uses a session and create a cookie on your own machine, it is recommended that the session mechanism on the server side be more secure. Because it does not arbitrarily read the information stored by the customer.

Orthodox cookie distribution is implemented by extending the HTTP protocol, and the server prompts the browser to generate the appropriate cookie by adding a special line of instructions to the HTTP response header. However, purely client-side scripts such as JavaScript or VBScript can also generate cookies. And the use of cookies by the browser in accordance with certain principles in the background automatically sent to the server. The browser checks all stored cookies and, if a cookie declares a scope greater than or equal to the location of the resource to be requested, sends the cookie to the server on the HTTP request header of the requesting resource.

From a Web server standpoint, all HTTP requests are independent of the previous request. This means that each HTTP response relies entirely on the information state management mechanism contained in the corresponding request to overcome some of the limitations of HTTP and to allow the relationship between network clients and server-side maintenance requests. The period during which this relationship is maintained is called a session.

Cookies are small pieces of text that the server stores on the local machine and are sent to the same server with each request. The IETF RFC 2965 HTTP State Management mechanism is a generic cookie specification. The Web server sends cookies to the client using HTTP headers, and in the client terminal, the browser parses the cookies and saves them as a local file, which automatically binds any requests from the same server to these cookies.

The contents of the cookie mainly include: name, value, expiration time, path and domain. The path together with the domain constitutes the scope of the cookie. If you do not set an expiration time, the cookie will be closed for the duration of the browser session. This cookie, which is the lifetime of the browser session, is referred to as a session cookie. Session cookies are generally not stored on the hard disk but are kept in memory, although this behavior is not regulated. If the expiration time is set, the browser will save the cookie to the hard disk, turn it off and open the browser again, and the cookies remain valid until the set expiration time expires. Cookies stored on the hard disk can be shared between different browser processes, such as two IE windows. For cookies stored in memory, different browsers have different ways of handling them.

Session mechanism. The session mechanism is a server-side mechanism that uses a hash-like structure (or perhaps a hash table) to hold information.

When a program needs to create a session for a client's request, the server first checks to see if the client's request contains a session ID (called the session ID.), and if it is included, it has previously created a session for this client. The server will follow the session ID to retrieve the session (not retrieved, a new one), if the client request does not include session ID, then create a session for this client and generate a session ID associated with this session, The value of session ID should be a string that is neither duplicated nor easy to be found, and the session ID will be returned to the client in this response to save.

This session ID can be saved by using a cookie, so that the browser can automatically play the logo to the server during the interactive process. Generally the name of this cookie is similar to Seeesionid. However, a cookie can be artificially banned, and there must be other mechanisms that can still pass the session ID back to the server when the cookie is banned.

A technique that is often used is called URL rewriting, which attaches the session ID directly behind the URL path. There is also a technique called form-hidden fields. Is that the server automatically modifies the form, adding a hidden field so that the session ID can be passed back to the server when the form is submitted. Like what:

<form name= "Testform" action= "/xxx" >

<input type= "hidden" name= "Jsessionid" value= "byok3vjfd75apnrf7c2hmdnv6qzcebzwowibyenlerjq99zwpbng!-145788764" >

<input type= "Text" >

</form>

What is URL rewriting?

The server can also pass the SessionID value through URL rewriting, so it is not entirely dependent on cookies. If the client cookie is disabled, the server can automatically save the session value by rewriting the URL, and the process is transparent to the programmer.

You can try it, even if you do not write cookies, use Request.getcookies (), the length of the cookie array is also 1, and the name of this cookie is jsessionid, and there is a long binary string, Is the value of the SessionID.

Essentially URL rewriting is by adding parameters to the URL connection and including the session ID as a value in the connection. However, for this to work, you need to add the session ID for each connection in your servlet response section.

How does a session rewrite with a URL be implemented?

JSP implementation

Adding a session ID to a connection can be simplified using a pair of methods: Response.encodeurl () causes the URL to contain the session ID, and if you need to use redirection, you can use Response.encoderedirecturl () to URL to encode. The Encodeurl () and Encoderedirectedurl () methods first determine whether the cookie is supported by the browser, and if so, the URL of the parameter is returned as is, and the session ID is maintained by the cookie.

code example:

Do not use URL rewriting: <a href=http://wwww.myserver.com/servelet/user;username=awaysrain>link</a>

Use URL rewriting: encoded by the Encodeurl () method in the HttpServletResponse interface.

String Myurl = Response.encodeurl (Http://wwww.myserver.com/servelet/user);

<a href= <%=myURL%> _fcksavedurl= "<%=myURL%>" _fcksavedurl= "<%=myURL%>" _fcksavedurl= "<%= Myurl%> ">

JSTL implementation

<c:url> to rewrite URLs for session management

<a href= "<c:url value= '/content/sitemap.jsp '/>" >view sitemap</a>

Struts implementation:

Struts configuration file: Set properties redirect, Contextrelative

<forward name= "Listarticlesforblog"

Path= "/template/listarticlesforblog.jsp"

Redirect= "true"

Contextrelative= "true"/>

The last thing to compare is:

In the case where the browser allows cookies, the browser is not required to turn off cookies

How is URL rewriting implemented?

Http://tomcat.apache.org/tomcat-5.5-doc/config/context.html

The context supports the cookies parameter. Set cookies= "false" to force resolution SessionID only from URL.

Original Address http://justsee.iteye.com/blog/831730

Session,cookie,jsessionid,url rewrite