Sessions and cookies are used in web development to preserve the user's interaction with the backend server. They have their own shortcomings and advantages. Moreover, their advantages and application scenarios are antagonistic.
CookiesFull Description: When a user accesses a server through HTTP, this server will return some Key/value key values to the client browser, and add some restrictions to the data, and when the conditions are met, the next time the user accesses the server, the data will be fully back to the server. Short Description: The cookie is like the "identity card" issued to the user when the server is accessed, and the server will be able to identify the information when the next visit brings it back. Version: There are two versions of the current Cookie, version 0 and version 1, which correspond to two identifiers for setting the corresponding headers, namely "Set-cookie" and "Set-cookie2". There are a couple of different versions of the property items.
It is important to note that: The Java Web servlet does not support the Set-cookie2 response header, and in practice, some Set-cookie2 property items can be set in Set-cookie.
How does a cookie work? The actual creation of the cookie is done in the Org.apache.catalina.connector.Response class, calling the Generatecookiestring method to construct the cookie object as a string, and the format of the string is constructed as a username = "Junshan"; version= "1"; max-age=1000. Then name the string Set-cookie added to Mimeheaders.
It is important to note that: The name of the cookie object cannot be duplicated with the header item, or it will result in an error. When we created the cookie, we created a mimeheaders with the name Set-cookie. Each time you call Addcookie, a header is created. Also, when HTTP returns a stream of characters, all entries in the header are written sequentially, without any modification. So the browser parses the header item separately when it accepts the data returned by HTTP. When we request a URL path, the browser passes the eligible cookie to the server in the request header based on this URL, and the server obtains all the cookies through request.getcookies ().
Precautions for using cookies1. If the cookie is not set for its lifetime, the cookie is destroyed by default when the browser is closed. 2, the cookie is not allowed by default, Chinese characters, if we want to add a cookie with Chinese content, we need to use Java.net.URLEncoder to first encode the language, followed by the addition of cookies. When reading a cookie, it needs to be decoded using Java.net.URLDecoder. 3. Different browsers have restrictions on the storage of cookies, which are usually limited by the number of cookies and the total size of the cookie. The limit for cookies, like Firefox, is that each domain name can have only 50 cookie values, and the total size cannot exceed 4,097 characters. 4, the cookie in the HTTP header, so the usual gzip and deflate for HTTP body compression can not compress cookies, if the amount of cookies is very large, to do a cookie compression, compression method is to treat multiple k/v of the cookie as ordinary text , do text compression. It is important to note that the cookie specification stipulates that the cookie can only save the ASCII code as 34~126 visible characters, so the result after compression is transcoded, can be Base32 or Base64 encoding.
SessionFull description: From the client browser to connect to the server, to the client browser and the server disconnected, such as a session, the role of sessions is to track the user's session information. Short Version Description: Session tracks user information during browser and server connection.
How does the session work? The server creates the HttpSession object on the premise that it has the session ID. The first trigger passes the Request.getsession () method. When the current Seesion ID does not have a corresponding HttpSession object, the server creates a new one and adds the object to the Org.apache.catalina.Manager session container. The manager class manages the lifetime of all sessions, the session expires, the server shuts down, the session is serialized to disk, and so on. As long as this HttpSession object exists, the user can obtain the object according to the session ID, and then the state is maintained. The session object obtained from the request is saved in the Org.apache.catalina.Manager class, and its implementation class is Standardmanager, by Requestedsessionid from the Standardmanager session set Remove the Sandardsession object from the collection. A client corresponds to a Standardsession object that holds the session value we created. When the Servelt container restarts or shuts down, Standardmanager is responsible for persisting the Standardsession object without expiration, which persists all standardsession objects to "Sessions.ser" In the file of the filename, when the servlet restarts, it re-reads the file, resolves all the session objects, and stores them again in the session collection.
DescriptionProperties within a session range can be shared across multiple page jumps. Once you close the browser, the session ends, and the properties within the session range are lost. The session object is an instance of HttpSession, which has two common methods: GetAttribute () and setattribute (). The value of the session's property can be any serializable Java object.
Security ComparisonCookies: The data is stored in the client, all of which can be accessed and even artificially modified and added, so cookies are not safe in this regard. Session: The data is stored on the server side, only through a cookie to pass a SessionID, so the session is more suitable for storing the user's privacy and important information. such as login password.
Security Solutions: Distributed session FrameworkUsing cookies is a good solution to the distributed deployment of your application, because cookies store values in the client's browser, and each time a user accesses the most recent value back to the server that processes the request. Therefore, there is no problem that the same user's request will be processed on the same server and cause the cookie to be inconsistent. However, excessive use of cookies can also cause problems: client-side restrictions, cookie management confusion, security concerns, and so on. So
Distributed Session FrameworkBirth. Unified use of Subscriber push configuration allows for efficient and centralized management of resources, eliminating the ability to configure cookies for each application, simplifying the management of cookies. Use a unified service subscriber to subscribe to the session and cookie entries that the app can use when the app starts, and these configured sessions and cookies can limit which sessions and cookies the app can use, Even control session and cookie can be read or writable. This gives you precise control over which sessions and cookies the app can manipulate, effectively controlling the security of the session and the number of cookies. Another very important question is how to deal with the problem of sharing cookies across domain names. Cookie is a domain name restrictions, a domain name under a cookie can not be accessed under another domain name, if you want to achieve a login between the two domains valid, need to achieve session synchronization, need another jump application, this application can be accessed by one or more domain names. Its main function is to get SessionID from a domain name and then sync this sessionid to another domain name. This sessionid is actually a cookie, equivalent to Jsessionid, so, after 12 steps of operation, a domain name can be taken to another domain without landing the session.
Talk about cookies and session
