For most of my Seaside presentations the audience is primarily people who have experience with some other web framework. Since we are generally pitching Seaside as being better, it helps to have some understanding of the alternatives (better than X because …). Since I’ve been using Smalltalk almost exclusively for over 10 years, I don’t have real experience with the alternatives that I’m discussing. (Actually, my first experience with web frameworks was VisualWave in VisualWorks, but there aren’t a lot of people who need to hear a presentation on why the should take a look at moving from VisualWave to Seaside.)
In an effort to better understand Seaside and have some integrity when making the marketing pitch, I do try to study some of the other frameworks out there. One of the areas of discussion is how to save session data (hidden fields, cookies, and URL rewriting) and whether to send the domain model data to the client or whether to save the data on the server and send a database key to the client. Part of my standard talk is to discuss the security risks of sending model data to the client and the obvious potential for hacking the data before returning it to the server. “What if Dell stored the price of that new notebook computer in a cookie? Wouldn’t it be nice if you could just edit the price before you click the ‘Add to Cart’ button?”
Mostly while I’m aware of these alternatives, I’ve never really seen them used so don’t have many bad examples to parade before the audience. Occasionally, however, I do stumble across an excellent example of a problem. One example is in the book Advanced Professional Web Design, Techniques and Templates (CSS &XHTML) by Clint Eccher (Charles River Media 2007). Chapter 3,titled “Understanding E-Commerce Functionality,” has a discussion of different credit card processing options.
One of the easier approaches for taking credit card payments is to get an account with PayPal and then on your product catalog pages put links to a PayPal shopping cart. In the link is embedded the information that PayPal needs to display a shopping cart with product descriptions and prices. The key point here is that the price is in the URL and it is trivial to copy the original URL, edit it in a text editor, and then paste it into the address bar of a web browser. (Note that the problem here appears to be with PayPal’s design, not with Eccher’s book which seems to be accurately describing a generally-accepted way of doing credit card processing.)
For example, here is Eccher’s sample link to the book Secret Software (I’ve modified the link slightly to remove the name of the actual on-line store that used this approach). Clicking on the link should open a new web page on PayPal’s secure server with a shopping cart showing the item with information from the URL. As an exercise, copy the link (right-click in most browsers) and paste it into a text editor. Find the part of the URL containing “amount=17.95” and change it to “amount=1.97” (that is, delete one character). Then copy the entire link and past it into the address bar of a new URL. Your shopping cart should look like the following:
I have no idea what would happen if you clicked ‘Proceed to checkout’ since I am not interested in giving a valid credit card. I expect that the information sent from PayPal to the store would include the price paid, and the store would have the option of checking it against the catalog before filling the order.
Anyway, it was a fun example.