JSESSIONID, session, cookie

Source: Internet
Author: User
Tags send cookies set cookie

 

 

The so-called session can be understood as follows: When a session is held with the server, for example, after a successful login, the server opens a memory interval for the user to store some content of the user's session, for example, user name. You need something to indicate that the memory range is yours rather than others'. This is session ID (JSESSIONID is only the name of session ID in Tomcat. In other containers, not necessarily JSESSIONID .), This memory interval can be understood as session.
Then, the server will send the session ID back to your browser and put it into your browser's cookies (this cookie is a memory cookie, which is different from the general one, it will disappear with the close of the browser ).
After that, only your browser is not closed. Every time you send a request to the server, the server will take out the session ID from the cookies you sent, then, based on the session ID, go to the corresponding memory to retrieve the data you previously stored.
However, if you log out, the server will clear your memory region, so if you log on again, a new session will be generated.

This is an insurance measure because session requires cookie support by default, but some client browsers disable Cookies [and JSESSIONID is stored in cookies,

If the cookie is disabled, that is to say, the server cannot obtain the corresponding session ID based on the JSESSIONID.

You cannot get the data stored in the session .] In this case, you need to specify the session ID on the server in the URL.

The format is similar to "JSESSIONID = 5f4771183629c9834f8382e23be13c4c. You can use a method (forget the name of the method) to process the URL string.

This method will determine whether your browser has enabled the cookie. If he thinks that the cookie should be added, the cookie will be added.

The session has a certain scope and has a time limit.

JSESSIONID is generated by the server because the cookie is the information sent from the server to the client. No matter whether JSESSIONID can be modified, it should not be modified. If you modify it, it will lose the meaning of the jessionid. If you modify it, how can you find the corresponding session on the server? If no data is found, isn't the data you stored in that session lost?
Log in and exit. I think a JSESSIONID will be generated again. If the application is exited, data in the application scope will be lost. What's more, this session is smaller than the application scope? Since all sessions have disappeared, what is the use of this JSESSIONID?

In some situations such as voting, we usually require that each person only vote for one vote because of the principles of fairness. In some web development, similar situations are also found. At this time, we usually use cookies to implement such a vote, for example, the following code:
<% Cookie [] cookies = request. getcookies ();
If (cookies. lenght = 0 | cookies = NULL)
Dostufffornewbie ();
// No Access
}

Else
{
Dostuffforreturnvisitor (); // already accessed
}

%>

This is an easy-to-understand principle. Check the existence of a cookie. If the existence of a cookie indicates that the Code that has been written to the cookie has been run. However, after the above Code is run, dostuffforreturnvisitor () is executed whenever the result is returned (), you can use control panel-Internet option-settings-to view the file but cannot see the generated cookie file. It is strange that the code is clearly correct. However, if there is a cookie, it will be displayed.
Cookie [] cookies = request. getcookies ();
If (cookies. lenght = 0 | cookies = NULL)
Out. println ("has 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 ());
}
}

Running result:
Cookie name: JSESSIONID cookie value: kwjhug6jjm65hs2k6 why is there a cookie? We all know that HTTP is a stateless protocol. Every time a customer reads a web page, the server opens a new session, in addition, the server does not automatically maintain the customer's context information, so how can we implement the shopping cart in the online store? session is a mechanism to save the context information for every user, the value of the variable is stored on the server side. sessionid is used to distinguish different customers. Session is based on cookie or URL rewriting. Cookie is used by default, the system will create an output cookie named JSESSIONID, which is called session
Cookie to distinguish persistent cookies, which we usually call cookies. Note that session cookies are stored in the browser memory and are not written to the hard disk, this is the JSESSIONID we just saw. We usually don't see JSESSIONID. However, when we disable the cookie in the browser, the web server will use URL rewriting to pass the sessionid, we can see strings such as sessionid = kwjhug6jjm65hs2k6 in the address bar.
After understanding the principles, we can easily distinguish the differences between persistent cookies and session cookies. The discussions on the security of the two on the Internet are clear. session cookies are for a session, session Cookie disappears, while the persistent cookie is only a piece of text (usually encrypted) stored on the client's hard disk ), in addition, Cookie spoofing and cross-site scripting attacks against cookies are not as secure as session cookies.
Generally, session cookies cannot be used across windows. When you open a new browser window to enter the same page, the system will give you a new sessionid, in this way, we cannot achieve the purpose of information sharing. At this time, we can first save the sessionid in the persistent cookie, and then read it out in the new window to get the sessionid of the previous window, in this way, session cookie and persistent cookie are combined to achieve cross-window session tracking ).
In some web development books, session and cookie are usually used as two parallel HTTP transmission methods. session cookies are on the server side, and persistent cookies are on the client side, however, session is based on cookies. It is not difficult to select the appropriate technology to develop Web services by understanding the relationship and difference between the two.

Bytes ----------------------------------------------------------------------------------------------------------------------

Differences and connections between cookie and session mechanisms

Specifically, the cookie mechanism adopts the client-side persistence scheme. It is the storage mechanism of session status on the user end. It requires the cookie support from the user to open the client. Cookie is used to solve the stateless defects of HTTP.
The session mechanism adopts a solution that maintains the status between the client and the server. At the same time, we also see that because the server-side persistence scheme also needs to save an identifier on the client, the session mechanism may need to use the COOKIE Mechanism to save the identifier. Session provides a convenient way to manage global variables.

The session is for every user. The value of the variable is stored on the server and a sessionid is used to identify which user session variable is used, this value is returned to the server when the user's browser accesses it. When the customer disables the cookie, this value may also be set to get to return to the server.

In terms of security: When you access a site that uses sessions and create a cookie on your host, it is recommended that the session mechanism on the server be safer. because it does not read the information stored by the customer.

The orthodox cookie distribution is implemented by extending the HTTP protocol. The server adds a special line of instructions to the HTTP response header to prompt the browser to generate the corresponding cookie according to the instructions.

From the network server perspective, all HTTP requests are independent of previous requests. That is to say, each HTTP Response completely relies on the information status management mechanism contained in the corresponding request to overcome some HTTP restrictions and allow the network client and server to maintain the relationship between requests. The period in which this relationship is maintained is called session ).

Cookies are small pieces of text stored by the server on the local machine and are sent to the same server as each request. Ietf rfc 2965 HTTP state management mechanism is a common cookie specification. The network server uses the HTTP header to send cookies to the client. On the client terminal, the browser parses these cookies and saves them as a local file. It will automatically upload these cookies to any requests on the same server.

Bytes ----------------------------------------------------------------------------------------------------

 

Differences and relationships between cookie and session mechanisms

Specifically, the cookie mechanism adopts the client-side persistence scheme, while the session mechanism adopts the server-side persistence scheme. At the same time, we can also see that because the server-side persistence scheme also needs to save an identifier on the client, the session mechanism may need to use the COOKIE Mechanism to save the identifier, but in fact it has other options.

COOKIE Mechanism. The orthodox cookie distribution is implemented by extending the HTTP protocol. The server prompts the browser to generate the corresponding cookie by adding a special line in the HTTP response header. However, pure client scripts such as JavaScript or VBScript can also generate cookies. Cookies are automatically sent to the server in the background by the browser according to certain principles. The browser checks all stored cookies. If the declared range of a cookie is greater than or equal to the location where the requested resource is located, the cookie is attached to the HTTP request header of the requested resource and sent to the server.
Cookie content mainly includes: name, value, expiration time, path and domain. The path and the domain form the scope of the cookie. If no expiration time is set, it indicates that the Cookie's life cycle is the browser session period. When the browser window is closed, the cookie disappears. This cookie is called a session cookie. Session cookies are generally stored in the memory instead of on the hard disk. Of course, this behavior is not standardized. If the expiration time is set, the browser will save the cookie to the hard disk, close it, and open the browser again. These cookies are still valid until the preset expiration time is exceeded. Cookies stored on hard disks can be shared among different browser processes, such as two IE Windows. For Cookies stored in the memory, different browsers have different processing methods.
Session mechanism. The session mechanism is a server-side mechanism. The server uses a structure similar to a hash (or a hash) to save information.

When the program needs to create a session for a client request, the server first checks whether the client request contains a session ID (called session ID ), if it already exists, it indicates that a session has been created for this client. Then, the server retrieves and uses this session according to the session ID (a new session will be created if it cannot be retrieved ), if the client request does not contain the session ID, the client creates a session and generates a session ID associated with the session. The session ID value should be unique, this session is not easy to find regular strings to be counterfeited.
The ID will be returned to the client in this response and saved.
The cookie can be used to save the session ID. In this way, the browser can automatically display the ID to the server according to the Rules during the interaction. Generally, the cookie name is similar to seeesionid. However, if a cookie can be artificially disabled, there must be other mechanisms so that the session ID can still be passed back to the server when the cookie is disabled.
A frequently used technology called URL rewriting is to directly append the session ID to the end of the URL path. Another technique is form hidden fields. The server automatically modifies the form and adds a hidden field so that the session ID can be passed back to the server when the form is submitted. For example:
<Form name = "testform" Action = "/XXX">
<Input type = "hidden" name = "JSESSIONID" value = "byok3vjfd75apnrf7c2hmdnv6qzcebzwowibyenlerjq99zwpbng! -145788764 ">
<Input type = "text">
</Form>
In fact, this technology can be simply replaced by rewriting the URL of the action application.

 

 

What is URL rewriting?

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

You can try to use the request even if no cookie is written. getcookies (); the length of the retrieved cookie array is also 1, and the cookie name is JSESSIONID. There is also a long binary string, which is the value of sessionid.

In essence, URL rewriting adds parameters to a URL Connection and includes the session ID as the value in the connection. However, to make this take effect, you need to add the session ID for each connection in the servlet Response Section.

How can I use URL for session rewriting?

JSP implementation

Adding session IDs to a connection can be simplified using one pair of Methods: response. encodeurl () enables the URL to contain the session ID. If you need to use redirection, you can use response. encoderedirecturl () to encode the URL. The encodeurl () and encoderedirectedurl () methods first determine whether the cookie is supported by the browser. If yes, the parameter URL is returned as is, and the session ID is returned through cookies.
To maintain.

Sample Code:

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

Use URL rewriting: Use the encodeurl () method in the httpservletresponse interface for encoding.

String myurl = response. encodeurl (http://wwww.myserver.com/servelet/user );

<A href = <% = myurl %> _ fcksavedurl = "<% = myurl %>" _ fcksavedurl = "<% = myurl %>" _ fcksavedurl = "<% = myurl %> ">

Jstl implementation

<C: URL> you can rewrite a URL for session management.

<A href = "<C: URL value = '/content/sitemap. jsp'/>"> View sitemap </a>

Struts implementation:

In the struts configuration file: Set the redirect and contextrelative attributes.

<Forward name = "listarticlesforblog"

Path = "/template/listarticlesforblog. jsp"

Redirect = "true"

Contextrelative = "true"/>

The last question is:

When the Browser allows cookies, the browser is not required to disable cookies.

How to Implement URL rewriting?

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

Context supports cookies. Set cookie = "false" and force resolution of sessionid only from URL.

Cookies

Set to true if you want cookies to be used for session identifiercontext

Communication if supported by the client (this is the default). Set

False if you want to disable the use of cookies for session identifier

Communication, and rely only on URL rewriting by the application.

 

 

 

 

Related Article

Cloud Intelligence Leading the Digital Future

Alibaba Cloud ACtivate Online Conference, Nov. 20th & 21st, 2019 (UTC+08)

Register Now >

Starter Package

SSD Cloud server and data transfer for only $2.50 a month

Get Started >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.