Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to analyze Java Session

2025-01-21 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/02 Report--

How to analyze Java Session, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

The following will discuss in detail how session works and answer common questions when applying the session mechanism in Java web application.

I. the term session

In my experience, the abuse of the word session is probably second only to transaction, and what is more interesting is that transaction and session have the same meaning in some contexts.

Session, which is often translated into conversation in Chinese, originally means a series of actions / messages with a beginning and end, such as the process from picking up the phone to dialing to hanging up the phone can be called a session. Sometimes we can see the words "during a browser session,". The word session here uses its original meaning, which refers to the period from the opening of a browser window to the closing of the ①. The most confusing is the phrase "user (client) during a session", which may refer to a series of actions of the user (usually a series of actions related to a specific purpose, such as the process from logging in to selecting goods to checking out such an online shopping process, sometimes referred to as a transaction), but sometimes it may only refer to a connection, or it may mean ①. The difference can only be inferred from the context of ②.

However, when the word session is associated with a network protocol, it often implies two meanings: "connection-oriented" and / or "keep state". "connection-oriented" means that both parties establish a communication channel before communicating, such as making a phone call, and the communication cannot begin until the other party answers the phone, as opposed to writing a letter. When you send the letter, you cannot confirm whether the address of the other party is correct, and the communication channel may not be established, but for the sender, the communication has already begun. " "keep it in shape" means that the party of the communication can associate a series of messages so that they can be interdependent, such as a waiter who can recognize a regular customer who comes again and remember that the customer owed a dollar to the store last time. Examples of this category are "one TCP session" or "one POP3 session" ③.

In the era of vigorous development of web server, the semantics of session in the context of web development has a new extension, which refers to a kind of solution ④ used to maintain the state between the client and the server. Sometimes session is also used to refer to the storage structure of this solution, such as "keep xxx in session" ⑤. Because various languages for web development provide support for this solution to some extent, session is also used to refer to the solution of that language in the context of a particular language, for example, the javax.servlet.http.HttpSession provided in Java is often referred to as session ⑥.

In view of this confusion can not be changed, the use of the word session in this article will also have different meanings according to the context, please pay attention to distinguish.

In this paper, Chinese "browser session" is used to express meaning ①, "session mechanism" is used to express meaning ④, "session" is used to express meaning ⑤, and concrete "HttpSession" is used to express meaning ⑥.

II. HTTP Protocol and State maintenance

The HTTP protocol itself is stateless, which is consistent with the original purpose of the HTTP protocol. The client simply requests the server to download certain files. Neither the client nor the server needs to record each other's past behavior. Each request is independent, just like the relationship between a customer and a vending machine or an ordinary (non-membership) hypermarket.

But smart (or greedy? ) soon found that providing some dynamic information generated on demand would make web more useful, just like adding on-demand functionality to cable TV. On the one hand, this demand forces HTML to gradually add client-side behaviors such as forms, scripts and DOM, on the other hand, CGI specifications appear on the server side to respond to client-side dynamic requests. As a transport carrier, HTTP protocol also adds features such as file upload and cookie. Among them, the role of cookie is to solve the stateless defect of HTTP protocol. The later session mechanism is another solution to keep the state between the client and the server.

Let's use a few examples to describe the differences and relationships between cookie and session mechanisms. I often go to a coffee shop that offers a free cup of coffee with five cups of coffee, but there is little chance of consuming five cups of coffee at once, so there is a need for some way to record the amount a customer spends. Imagine that there are no more than the following options:

1. The clerk in this store is very good and can remember the amount spent by each customer. As soon as the customer enters the coffee shop, the clerk will know what to do with it. This is the support status of the protocol itself.

2. Send a card to the customer, which records the amount of consumption, usually with an expiration date. Each time, if the customer shows this card, the consumption will be associated with previous or future consumption. This is done by keeping the state on the client side.

3. Send the customer a membership card with no information except the card number. If the customer shows the card every time, the clerk will find the corresponding record in the record book of the store and add some consumption information. This is done by keeping the state on the server side.

Because the HTTP protocol is stateless and does not want to be stateful for various reasons, the latter two schemes become realistic choices. Specifically, the cookie mechanism adopts the scheme of maintaining state on the client side, while the session mechanism adopts the scheme of maintaining state on the server side. At the same time, we also see that because the scheme of keeping state on the server side also needs to save an identity on the client side, the session mechanism may need to save the identity with the help of the cookie mechanism, but in fact it has other options.

Third, understand the cookie mechanism

The basic principle of the cookie mechanism is as simple as the above example, but there are still several problems that need to be solved: how to distribute the "membership card"; the contents of the "membership card"; and how customers use the "membership card".

Orthodox cookie distribution is achieved by extending the HTTP protocol, and the server prompts the browser to generate the corresponding cookie according to the instructions by adding a special instruction to the response header of the HTTP. However, pure client script such as JavaScript or VBScript can also generate cookie.

The use of cookie is automatically sent to the server by the browser in the background according to certain principles. The browser checks all stored cookie, and if the scope declared by a cookie is greater than or equal to the location of the resource to be requested, the cookie is attached to the HTTP request header of the requesting resource and sent to the server. It means that McDonald's membership card can only be shown in a McDonald's restaurant. If a branch restaurant issues its own membership card, then when entering the restaurant, you should show not only the McDonald's membership card, but also the restaurant's membership card.

The content of cookie mainly includes: name, value, expiration time, path and domain.

The domain can specify a domain, such as .google.com, which is equivalent to the signboard of the main store, such as Procter & Gamble, or you can specify a specific machine under a domain, such as www.google.com or froogle.google.com, which can be compared with Piaoliu.

The path is the URL path that follows the domain name, such as / or / foo, etc., which can be compared with a floating counter.

The combination of path and domain constitutes the scope of cookie.

If the expiration time is not set, the lifetime of the cookie is during the browser session, and the cookie disappears as long as the browser window is closed. A cookie whose lifetime is a browser session is called a session cookie. Session cookie is generally not stored on the hard disk but in memory, of course, this behavior is not specified by the specification. If the expiration time is set, the browser will save the cookie to the hard drive, close it and open the browser again, and the cookie will remain valid until the set expiration time is exceeded.

Cookie stored on the hard disk can be shared between different browser processes, such as two IE windows. For cookie stored in memory, different browsers have different ways to handle it. For IE, windows opened by pressing Ctrl-N (or from the file menu) on an open window can be shared with the original window, while newly opened IE processes cannot share the memory cookie; of an open window in other ways. For Mozilla Firefox0.8, all processes and tabs can share the same cookie. Generally speaking, windows opened with javascript's window.open will share memory cookie with the original window. The browser's handling of session cookie, which only recognizes cookie but does not recognize people, often causes great trouble to web application developers who adopt session mechanism.

Here is an example of how goolge sets the response header of cookie

HTTP/1.1 302 Found

Location: http://www.google.com/intl/zh-CN/

Set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:

Expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com

Content-Type: text/html

This is part of the HTTP communication record captured by HTTPLook, the HTTP Sniffer software.

The browser automatically sends out cookie when it visits goolge's resources again.

Using Firefox, you can easily observe the value of existing cookie.

Using HTTPLook with Firefox makes it easy to understand how cookie works.

IE can also be set to ask before accepting cookie

This is a dialog box that asks to accept cookie.

IV. Understand the session mechanism

The session mechanism is a server-side mechanism, and the server uses a structure similar to a hash table (that is, perhaps a hash table) to hold information.

When a program needs to create a session for a client's request, the server first checks whether the client's request contains a session ID-called session id. If it already contains a session id, it means that the session has been created for this client before. The server retrieves the session according to session id (if it cannot be found, a new one may be created). If the client request does not contain session id The value of creating a session for this client and generating a session id,session id associated with this session should be a string that is neither repetitive nor easy to find rules to fake, and the session id will be returned to the client in this response.

The session id can be saved using cookie, so that the browser can automatically play the identity to the server according to the rules during the interaction. Generally speaking, the name of this cookie is similar to SEEESIONID, and. For example, weblogic for web applications generated cookie,JSESSIONID= ByOK3vjFD75aPnrF7C2HmdV6QZcEbzWoWiBYEnLerjQ99zWpBng colors 145788764, its name is JSESSIONID.

Because cookie can be artificially disabled, other mechanisms must be in place to pass session id back to the server when cookie is disabled. A technique that is often used is called URL rewriting, which appends the session id directly to the URL path. There are also two ways to append it. One is as additional information to the URL path, which is expressed in the form of http://...../xxx;jsessionid=.

ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBngcolor 145788764

The other is appended to URL as a query string in the form of http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764

There is no difference between the two methods for users, but the server handles it differently when parsing, and the first method is also helpful to distinguish the information of session id from the normal program parameters.

In order to maintain state throughout the interaction, this session id must be included after the path that each client may request.

Another technique is called form hidden fields. The server automatically modifies the form to add a hidden field so that the session id can be passed back to the server when the form is submitted. For example, the following form

Will be rewritten before being passed to the client

This technology is rarely used now, and it is used by the very old iPlanet6 (the predecessor of the SunONE application server) that the author has come into contact with.

In fact, this technique can be simply replaced by applying URL rewriting to action.

When talking about the session mechanism, we often hear the misconception that "as long as you close the browser, session disappears." In fact, you can imagine the example of membership card, unless the customer takes the initiative to sell the card to the store, otherwise the store will not easily delete the customer's information. The same is true for session, unless the program tells the server to delete a session, otherwise the server will always retain it. The program usually sends an instruction to delete the session when the user does log off. However, the browser never actively notifies the server that it is going to shut down before shutting down, so the server will never have a chance to know that the browser has been closed. The reason for this illusion is that most session mechanisms use session cookie to save the session id, but after closing the browser, the session id disappears, and the original session cannot be found when you connect to the server again. If the cookie set by the server is saved to the hard disk, or if you use some means to rewrite the HTTP request header issued by the browser and send the original session id to the server, you can still find the original session by opening the browser again.

It is precisely because closing the browser will not cause the session to be deleted, forcing the server to set an expiration time for the seesion. When the expiration time is longer than the last time the client uses session, the server can think that the client has stopped its activity and delete the session to save storage space.

5. Understand javax.servlet.http.HttpSession

HttpSession is the Java platform specification for the implementation of the session mechanism, because it is only an interface, specific to each web application server provider, in addition to supporting the specification, there will still be some subtle differences that are not specified in the specification. Here we use BEA's Weblogic Server8.1 as an example to demonstrate.

First of all, Weblogic Server provides a series of parameters to control its HttpSession implementation, including the switch option of using cookie, the switch option of using URL rewrite, the setting of session persistence, the setting of session failure time, and various settings for cookie, such as setting cookie name, path, domain, cookie lifetime and so on.

In general, session is stored in memory, when the server process is stopped or restarted, the memory session will also be emptied, if the persistence feature of session is set, the server will save session to the hard disk, when the server process restarts or this information will be used again, Weblogic Server supports persistence methods including file, database, client cookie save and replication.

Replication is not strictly persistent, because the session is actually kept in memory, but the same information is copied to server processes within each cluster, so that session can still be obtained from other processes even if one server process stops working.

The setting of cookie lifetime affects whether the cookie generated by the browser is a session cookie. The default is to use the session cookie. Those who are interested can use it to test the misunderstanding we mentioned in section 4.

The path to cookie is a very important option for web applications, and Weblogic Server's default handling of this option makes it significantly different from other servers. We will have a special discussion later.

For the setting of session, refer to [5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869.

VI. Frequently asked questions on HttpSession

(in this section, session means a mixture of ⑤ and ⑥)

1. When is session created

A common misunderstanding is that session is created when there is client access, but the fact is that it is not created until a server program calls statements like HttpServletRequest.getSession (true). Note that if JSP does not show the use of closing session, the JSP file will automatically add such a statement HttpSession session = HttpServletRequest.getSession (true) when compiled into Servlet; this is also the origin of the session object implied in JSP.

Because session consumes memory resources, if you don't plan to use session, you should turn it off in all JSP.

2. When will session be deleted

Summing up the previous discussion, session is deleted under the following circumstances. The program calls HttpSession.invalidate (); or b. The time interval between the last session id received from the client exceeds the timeout setting for session; or c. The server process is stopped (non-persistent session)

3. How to delete session when the browser is closed

Strictly speaking, this cannot be done. A little effort can be made by using the javascript code _ window.oncolose in all client pages to monitor the browser shutdown, and then send a request to the server to delete the session. But unconventional methods such as browser crashes or forcibly killing processes are still powerless.

4. What's going on with a HttpSessionListener

You can create such a listener to monitor session creation and destruction events, so that you can do some work when such events occur. Note that it is the create and destroy actions of session that trigger listener, not the other way around. Similar listener related to HttpSession are HttpSessionBindingListener,HttpSessionActivationListener and HttpSessionAttributeListener.

5. Must objects stored in session be serializable

It's not necessary. Object serializability is required only so that session can be replicated in the cluster or persisted or server can temporarily swap session out of memory if necessary. Placing a non-serializable object in Weblogic Server's session will receive a warning on the console. It is strange that a version of iPlanet that I have used will have an Exception when session destroys if there are non-serializable objects in the session.

6. How to correctly deal with the possibility that the client forbids cookie

Use URL rewriting for all URL, including hyperlinks, form action, and redirected URL, as described in [6]

Http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

7. Open two browser windows to access whether the application will use the same session or different session

See the discussion of cookie in the third section. For session, only id does not recognize people, so different browsers, different ways of opening windows and different ways of cookie storage will affect the answer to this question.

8. How to prevent session confusion caused by users opening two browser windows

This problem is similar to preventing a form from being submitted multiple times and can be solved by setting a token on the client. That is, each time the server generates a different id and returns it to the client and saves it in the session, the client must also return the id to the server when submitting the form. The program first compares whether the returned id is consistent with the value saved in the session. If it is inconsistent, it means that this operation has been submitted. You can refer to the section on the presentation layer pattern in the J2EE Core pattern. It should be noted that for windows opened with javascript window.open, generally do not set this id, or use a separate id, in case the main window can not be operated, it is recommended that you do not modify the window opened by window.open, so that you do not need to set up.

9. Why call session.setValue again after changing the value of session in Weblogic Server

The main purpose of doing this is to prompt you in a clustered environment that the value in Weblogic Server session has changed and you need to copy the new session value to other server processes.

10. Why is session missing

Excluding the normal failure of session, the possibility of the server itself should be minimal, although the author has encountered it on the Solaris version of iPlanet6SP1 with several patches; the possibility of browser plug-in is the second, and the author has also encountered problems caused by 3721 plug-ins; theoretically, firewalls or proxy servers may also have problems in cookie processing.

Most of the causes of this problem are program errors, and the most common is to access one application in another. We will discuss this problem in the next section.

7. Session sharing across applications

It often happens that a large project is divided into several small projects, and each small project is required to be developed as a separate web application in order not to interfere with each other, but in the end, it is suddenly found that some small projects need to share some information, or want to use session to implement SSO (single sign on), and save the user information of login in session. The most natural requirement is that applications can access each other's session.

However, according to the Servlet specification, the scope of session should be limited to the current application, and different applications cannot access each other's session. Each application server complies with this specification in practice, but the implementation details may vary, so the solution to cross-application session sharing is also different.

First of all, let's take a look at how Tomcat implements the isolation of session between web applications. From the cookie path set by Tomcat, the cookie path it sets for different applications is different, so different applications use different session id, so even if you visit different applications in the same browser window, the session id sent to the server can be different.

Based on this feature, we can infer that the memory structure of session in Tomcat is roughly as follows.

IPlanet, which the author has used before, also uses the same method, and it is estimated that there will not be much difference between SunONE and iPlanet. For this kind of server, the solution is very simple, and it is not difficult to put it into practice. Either let all applications share a session id, or let applications get the session id of other applications.

A simple way to share a session id in iPlanet is to set the cookie path of each application to / (it should actually be / NASApp, which acts as the root for the application).

/ NASApp

It should be noted that session with shared operations should follow some programming conventions, such as prefixing the session attribute name with the application's prefix so that setAttribute ("name", "neo") becomes setAttribute ("app1.name", "neo") to prevent namespace conflicts, resulting in overwriting each other.

There is no such convenient choice in Tomcat. With Tomcat version 3, we also have some means to share session. For version 4 and above Tomcat, the author has not yet found a simple way. You can only rely on the power of a third party, such as using files, databases, JMS, or client-side cookie,URL parameters or hidden fields.

Let's take another look at how Weblogic Server handles session.

From the screenshot, you can see that the path of cookie set by Weblogic Server for all applications is /. Does this mean that session can be shared by default in Weblogic Server? However, a small experiment can prove that even if different applications use the same session, each application can only access the properties they set. This indicates that the memory structure of session in Weblogic Server may be as follows

For such a structure, it should be impossible to solve the problem of session sharing on the session mechanism itself. In addition to resorting to the power of a third party, such as using files, databases, JMS, or client-side cookie,URL parameters or hidden fields, it is more convenient to put the session of one application into ServletContext, so that another application can get a reference to the previous application from ServletContext. The sample code is as follows

Application A

Context.setAttribute ("appA", session)

Application B

ContextA = context.getContext ("/ appA")

HttpSession sessionA = (HttpSession) contextA.getAttribute ("appA")

It is worth noting that this usage is not portable, because according to ServletContext's JavaDoc, the application server can be for security reasons for context.getContext ("/ appA"); returns a null value, which was adopted in Weblogic Server 8.1.

So why does Weblogic Server set the cookie path of all applications to /? It turns out that it is for SSO, and all applications that share this session can share authentication information. A simple experiment can prove this, modify the descriptor weblogic.xml of the application that first logged in, and change the cookie path to / appA access another application will re-require login, even if the reverse, first access the cookie path / application, and then access the modified path of this, although no longer prompted to log in, but the login user information will be lost. Note that FORM should be used for authentication when doing this experiment, because browsers and web servers have other ways to handle basic authentication, and the second request for authentication is not achieved through session.

The answer to the question on how to analyze Java Session is shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 284

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report