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?
<% Cookie  cookies = request. getcookies ();
If (cookies. lenght = 0 | cookies = NULL)
// No Access
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 ");
For (INT I = 0; I <cookie. length; I ++)
Out. println ("Cookie name:" + Cookies [I]. getname () + "cookie value:" +
Cookie [I]. getvalue ());
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.
|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.
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?
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.
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 %> ">
<C: URL> you can rewrite a URL for session management.
<A href = "<C: URL value = '/content/sitemap. jsp'/>"> View sitemap </a>
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?
Context supports cookies. Set cookie = "false" and force resolution of sessionid only from URL.
Set to true if you want cookies to be used for session identifiercontext
Communication if supported by the client (this is the default). Set
Communication, and rely only on URL rewriting by the application.