Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 77 78 79 80 81 82 < 83 > 84 85 86 87 88 89 .. 166 >> Next

224 Item 25
the same values in HttpSession, bad things will happen! In the fictional scenario where we discussed the "switched shopping carts," where lingerie items appeared in the hardware store shopping cart, it just so happened that both e-commerce sites resided on the same server and the visits happened during the same HTTP session.
"Isn't this probability slim?" you may ask. We don't think so. In the present Internet environment, it is not uncommon for e-commerce sites to exist on the same server without the end user knowing about it. In fact, it is not uncommon for an Internet hosting company to host more than one e-commerce site on the same server without the developers of the applications knowing about it!
What does this mean for you as a programmer? When using the HttpSession class, try to make certain that you will not collide with another application. Avoid using common names storing types in HttpSession with the putValue() method. Instead of name and shoppingcart, it may be useful to put your organization, followed by the name of the application, followed by the description of the item you are storing. For example, if you are ACME.COM, and you are developing the e-commerce application for the Stockman Hardware example, perhaps com.acme.StockmanHardware. shoppingcart would be a better choice for storing your data.
Keeping the idea of collisions in mind, look at Listing 25.2, which is used for a shopping cart "checkout" to finalize a transaction on the "Lace Lingerie" e-commerce site. Can you find anything that could cause unexpected behavior to happen? As you can see in the code listing in line 16, the programmer is using a better naming convention for the shopping cart. However, in a new scenario, when the user finishes his purchase at Lace Lingerie and returns to Stockman Hardware, his shopping cart is empty. How could this happen?
01 public void checkout(PrintWriter out, HttpSession session)
02 {
03 /*
04 * Call the chargeToCreditCard() method, passing the session
05 * which has the user's credit card information, as well as the
06 * shopping cart full of what he bought.
07 */
08 chargeToCreditCard(session);
09
10 out.println("<H2>");
11 out.println("Thank you for shopping at Lace Lingerie Online!")
12 out.println("</H2>");
13 out.println("<B>The following items have been charged to ");
14 out.println("your credit card:</B><BR>");
15 Vector cart =
16 session.getValue("com.acme.lacelingerie.shoppingcart");
17
18 Iterator it = cart.iterator();
19
20 while (it.hasNext())
21 {
22 out.println("<LI>" + it.next());
Listing 25.2 A checkout()portion of a Web site
When Servlet HttpSessions Collide 225
23 }
24
25 out.println("<H2>Have a nice day!</H2>");
26
27 session.invalidate();
28 }
Listing 25.2 (continued)
The problem lies in line 27 in Listing 25.2. As we showed in Table 25.1, calling the invalidate!)method of the HttpSession interface eliminates the session and all of the objects stored in the session. Unfortunately, this will affect the user's session for every application on the server. In our e-commerce shopping scenario, if the user returns to another online store on the server that keeps any information in an HttpSession, that data will be lost.
What is the solution? Avoid the invalidate() method in HttpSession. If you are worried about leaving sensitive data in the HttpSession object, a better solution is shown in Listing 25.3.
01 public void checkout(PrintWriter out, HttpSession session)
02 {
03 /*
04 * Call the chargeToCreditCard() method, passing the session
05 * which has the user's credit card information, as well as the
06 * shopping cart full of what he bought.
07 */
08 chargeToCreditCard(session);
09
10 out.println("<H2>");
11 out.println("Thank you for shopping at Lace Lingerie Online!")
12 out.println("</H2>");
13 out.println("<B>The following items have been charged to ");
14 out.println("your credit card:</B><BR>");
15
16 Vector cart =
17 session.getValue("com.acme.lacelingerie.shoppingcart");
18
19 Iterator it = cart.iterator();
20
21 while (it.hasNext())
22 {
23 out.println("<LI>" + it.next());
24 }
25
Listing 25.3 Better alternative for checkout() (continued)
226 Item 25
26 out.println("<H2>Have a nice day!</H2>");
27
28 /*
29 * Delete all Information related to this transaction,
30 * because It Is confidential and/or sensitive!
31 */
32 session.removeValue("com.acme .lacelingerie.customername");
33 session.removeValue("com.acme .lacelingerie.shoppingcart");
34 session.removeValue("com.acme .lacelingerie.creditcard");
35 session.removeValue("com.acme .lacelingerie.bodydimensions");
36
37 }
Listing 25.3 (continued)
In lines 32 to 35 of Listing 25.3, the programmer deleted all of the objects specific to his application from the HttpSession. This can be a better alternative to the invalidate!) method.
What other collision pitfalls could you encounter with this class? If you look back at the code in Listing 25.1, note the else clause in lines 20 to 31. The code assumed that since the isNew()method returned false on line 13, the user had previously visited that site. Now we know better. When isNew() returns false, it means that there exists a session between the browser and the server that has persisted over a matter of time. It does not mean that the user has established a session with the current servlet. The better way to write the block of code in Listing 25.1 is shown in Listing 25.4.
Previous << 1 .. 77 78 79 80 81 82 < 83 > 84 85 86 87 88 89 .. 166 >> Next