Session and Cookie

Session is stored on the server side, generally in order to prevent in the server's memory (for high-speed access), Sessinon when the user access the first access to the server created, need to be aware that only access to the JSP, servlet and other programs will be created session, only access to HTML, Static resources such as image do not create a session, and call Request.getsession (true) to force a session to be generated.

　　When does the session expire?

1. The server clears a session that has not been active for a long time from the server memory, and the session expires. The default expiration time for a session in Tomcat is 20 minutes.

2. Call the Invalidate method of the session.

session Requirements for browsers:

Although the session is saved on the server and is transparent to the client, it still needs the support of the client browser for its normal operation. This is because the session needs to use a cookie as the identification mark. The HTTP protocol is stateless, and the session cannot determine whether it is the same client based on an HTTP connection, so the server sends a cookie named Jsessionid to the client browser. Its value is the ID of the session (that is, the return value of Httpsession.getid ()). The session is based on the cookie to identify whether it is the same user.

The cookie is automatically generated by the server, and its MaxAge property is typically-1, which means that only the current browser is valid, and the browser windows are not shared, and the browser is disabled. Therefore, when the server is accessed by two browser windows of the same machine, two different sessions are generated. However, new windows that are opened by links, scripts, and so on in the browser window (that is, not by double-clicking on Windows that are open by desktop browser icons). Such sub-Windows share a parent window's cookie, so a session is shared.

Note: The newly opened browser window will generate a new session, except for the child window. The child window will share the session of the parent window. For example, when you right-click on a link and select Open in New window in the popup shortcut menu, the child window can access the session of the parent window.

What if the client browser disables the cookie feature or does not support cookies? For example, most mobile browsers do not support cookies. The Java Web provides another solution: URL-Address rewriting.

URL address Rewriting is a solution that does not support cookies for clients. The principle of URL address rewriting is to rewrite the ID information of the user session to the URL address. The server is able to parse the rewritten URL to get the session ID. This allows you to use the session to record user status even if the client does not support cookies. The HttpServletResponse class provides a encodeurl (String URL) implementation for URL address rewriting, which automatically determines whether the client supports cookies. If the client supports cookies, the URL is output intact. If the client does not support cookies, the ID of the user session is rewritten into the URL.

　　Note: Tomcat determines whether the client browser supports cookies based on whether the request contains cookies. Although the client may support cookies, no cookie will be brought with the first request (because there is no cookie to carry), and the address after the URL address is rewritten is still jsessionid. The server has already written a cookie in the browser when the second visit is made, so the address in the URL address rewrite will not be jsessionid.

Cookies are always stored in the client, and can be divided into memory cookies and hard disk cookies by the storage location in the client.

The memory cookie is maintained by the browser, stored in memory, and disappears after the browser is closed, and its presence time is short. The hard disk cookie is saved on the hard drive, there is an expiration time, unless the user manually cleans up or expires, the hard disk cookie is not deleted and its presence time is long. Therefore, by time of existence, it can be divided into non-persistent cookies and persistent cookies.

Use

Because the HTTP protocol is stateless, that is, the server does not know what the user did last time, which seriously hinders the implementation of the interactive Web application. In a typical online shopping scene, users browsed through several pages, bought a box of biscuits and two bottles of drinks. At the end of checkout, due to the stateless nature of HTTP, the server does not know what the user is buying without additional means. So a cookie is one of the stateless "extras" that can be used to bypass HTTP. The server can set or read the information contained in the cookie to maintain the status of the user and the server session.

In the shopping scene just now, when the user buys the first item, the server sends a cookie to the user while sending the webpage, which records the information of the product. When a user accesses another page, the browser sends the cookie to the server, and the server knows what he has previously purchased. The user continues to buy drinks, and the server adds new product information to the original cookie. At checkout, the server reads the cookie that is sent.

Another typical application of cookies is when a website is logged in, the site often asks the user for a user name and password, and the user can tick "next automatic login". If checked, the next time you visit the same website, users will find that they have logged in without entering their username and password. This is precisely because the server sent a cookie containing the login credentials (an encrypted form of the user name plus a password ) to the user's hard disk the previous time you logged on. On the second login, (if the cookie is not yet expired) The browser sends the cookie, the server verifies the credentials, and the user does not have to enter a user name and password to log in.

Limitations of Cookies

1. The cookie is appended to each HTTP request, so the traffic is virtually increased.

2. Security is problematic because the cookie in the HTTP request is passed in plaintext. (except with HTTPS)

3. The size of the cookie is limited to around 4KB. is not enough for complex storage requirements. ^[2]

use and disable Cookies

The user can change the browser settings to use or disable cookies. At the same time, some browsers bring in or install the Developer Toolkit to allow users to view, modify or delete cookies from specific websites.

Recognition Function

If you install multiple browsers on a single computer, each browser will store cookies in a separate space. Because the cookie not only can confirm the user, but also can contain the information of the computer and the browser, so a user log in with a different browser or a different computer, will get different cookie information, on the other hand, for the same computer with the same browser on the multi-user group, Cookies do not differentiate their identities unless they are logged in with a different user name.

people who oppose cookiesprivacy, security and advertisingCookies, to some extent, have seriously compromised the privacy and security of users. One way is for some companies to visit websites they've never visited (through search engines) for some purpose (such as market research), which contain a picture called web bugs that is transparent and has only one pixel size (to hide). Their role is to write cookies to all computers that have visited this page. E-commerce Websites then read the cookie information and look for websites that write these cookies, and then send spam messages to those senior people that contain advertisements for the relevant products on the site.stealing cookies and scripting attacks

Although cookies are not as dangerous as computer viruses, they still contain sensitive information: usernames, computer names, browsers used and websites that have been visited. Users do not want this content to leak out, especially when it contains private information.

• Cookie thief: A hacker who collects user cookies and sends them to attackers. The attacker will use cookie information to access the user account through legal means.

• Cookie poisoning: It is generally considered that cookies have not been modified during storage and return to the server, and the attacker will modify the cookie before it is returned to the server for its own purposes. For example, the cookie in a shopping site contains the amount that the customer is owed, and the attacker changes the value to a lesser payment. This is a cookie poisoning.

Alternatives to Cookies

In view of the limitations of cookies and the voices of opponents, there are several alternative methods:

• The Brownie program, an open source project, was initiated by SourceForge. Brownie has been used to share access in different domains, while cookies are conceived as access in a single domain. The programme has ceased to develop.

• P3P to allow users to gain more control over their privacy rights. It is similar to a cookie when browsing a website.

• When transferring data to and from the server, it is also possible to avoid using cookies by adding a unique query string after the address to allow the server to identify legitimate users.

• Transferred from: http://my.oschina.net/u/576942/blog/211863

Session and Cookie