Session mechanism in the details

Session mechanism

In addition to using cookies, Web applications often use Session to record client status. A session is a mechanism used by the server to record the status of the client. It is simpler to use than the cookie, which in turn increases the storage pressure on the server.

Image: owasp

What is Session?

A session is another mechanism to record the status of the client, the difference is that the cookie is stored in the client browser, and the session is saved on the server. When the client browser accesses the server, the server records the client information in some form on the server. This is Session. When the client browser visits again, it only needs to find the status of the client from the Session.

If the cookie mechanism is to determine the identity of the client by checking the “pass” on the client, then the Session mechanism is to confirm the identity of the client by checking the “client list” on the server. Session equivalent to the program created on the server a customer file, customer visit only need to check the customer file table on it.

To achieve user login

The corresponding Session class javax.servlet.http.HttpSession category. Each visitor corresponds to a Session object, all of the client’s state information is stored in this Session object. The Session object is created when the client requests the server for the first time. A session is also a key-value property pair that reads and writes customer state information using the getAttribute(Stringkey) and setAttribute(String key, Objectvalue) methods. Servlet through the request.getSession() method to obtain the client’s Session.

Pay attention to the Session Session directly saved Person object and Date class object, to use than Cookie convenient.

When multiple clients execute a program, the server saves multiple client sessions. Get Session also do not need to declare the access to the Session. Session mechanism determines that the current client will only get their own Session, and will not get someone’s Session. The client’s sessions are also independent of each other, not visible to each other.

Tip: Session is easier to use than Cookie, but too many sessions stored in the server’s memory can put pressure on the server.

Session lifecycle

Session saved on the server. In order to obtain higher access speed, the server generally Session in memory. Each user will have a separate session. If the Session content is too complicated, memory overflow may occur when a large number of clients access the server. Therefore, the information in the Session should be as concise as possible.

A session is created automatically when the user first accesses the server. Need to pay attention to only visit JSP, Servlet and other procedures will create a Session, visit only static resources such as HTML, IMAGE and will not create a Session. If you have not generated a Session, you can also use request.getSession (true) to force the session to be generated.

After the Session is generated, as long as the user continues to access the server, the server updates the last access time of the Session and maintains the session. Each time a user accesses the server, regardless of whether the session is read or written, the server considers the user’s session “active” once.

Session is valid

Because there will be more and more users to access the server, so Session will be more and more. To prevent memory overflow, the server will not an active session for a long time from the memory to delete. This is the Session’s timeout. If more than the timeout did not visit the server, the Session will automatically expire.

The timeout of the session is the maxInactiveInterval property, which can be obtained through the corresponding getMaxInactiveInterval() and modified by setMaxInactiveInterval(longinterval).

Session timeout can also be modified in web.xml. In addition, Session can be invalidated by calling Session’s invalidate () method.

Session on the browser requirements

Although the Session is stored on the server and is transparent to the client, its normal operation still requires client-side browser support. This is because Session requires the use of cookies as an identifier. The HTTP protocol is stateless. The Session cannot determine whether it is the same client based on the HTTP connection. Therefore, the server sends a cookie named JSESSIONID to the client browser whose value is the Session id (ie, HttpSession.getId() the return value). Session based on the cookie to identify whether the same user.

The cookie is automatically generated by the server, its maxAge property is generally -1, which means that only the current browser is valid, and the browser window is not shared, close the browser will lapse.

Therefore, when two browser windows of the same machine access the server, two different sessions are generated. Except for new windows opened by links, scripts, etc. in the browser window (ie, not double-click on an open window such as a desktop browser icon). Such sub-window will share the parent window’s Cookie, it will share a Session.

Note: The new browser window will generate a new Session, except the child window. Child window will share the parent window Session. For example, right-clicking on a link and selecting “Open in a new window” in the pop-up shortcut menu will allow the child window to access the parent’s Session.

What if the client browser disables cookies or does not support cookies? For example, most mobile browsers do not support cookies. Java Web Another solution provided: URL address rewriting.

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 can parse the rewritten URL for the Session’s id. This allows you to use the Session to record user status even though the client does not support cookies.