Cracking the HTML Persistence Barrier
Two Completely New Methods. A JAVA program frees itself from the launching page, persists forever, and breaks into Javascript on every following page.
You can find the original exploratory article here.
We’re going to look at a shopping cart program which generates HTML persistence by two completely new
methods. The first technique loads an applet repeatedly to create a form of HTML memory that does not
use cookies or Active Server Pages. The second method develops a pseudo-constructor for an abstract class
to form a frame, complete with event handling, that cannot be closed without the programmer’s permission.
We will then adapt this structure to break through some security limits. Let’s discuss first how useful these
two techniques can be, when used in a normal manner.
Any existing web site can be transformed instantly into a commercial site by the simple addition of 9 lines
of boilerplate code. This launches a frame which persists for as long as is desired, no matter where you
browse, and which keeps a running total of purchases, from page to page within a site. If another merchant
uses the same cart, then a separate frame is launched. There are no delays when purchases are made,
because everything occurs on the client browser. Except for a one-time initial download of the applet and
its classes (14K, or 8K compressed), there are also no delays when jumps are made from one commercial
page to another, because the applet itself (less than 1K in size), and its memory, are simply transferred
without a reload.
An optional database of price updates is downloaded from the server, cached on the
browser, and also carried from page to page – again, there are no delays, except for the initial download.
Orders are finalized by sending them to a central server; this means that the merchant’s site can be dumb –
it can even be located on a host such as geocities. The purchaser can wait to finalize his order, because the
shopping cart travels with him. When he does finally choose to check out his cart, then he still has the
option of changing his mind – he can restore the cart, and send out another finalization.
Examine the cart – which for now respects security limits - at http://209.87.142.42/shopcart/Page1.htm. It
uses JDK 1.1, and thus requires Explorer 4 or 5. Early Netscape Versions 4.0x are not aware of JDK 1.1,
and thus will not work; Versions 4.5 and higher are fine. Try pressing Reset when the cart comes up; on
Explorer, the cart will even survive a Shift-Reset. You can press Reset fast and repeatedly, and you
probably won’t crash the cart.
How is it done? JAVA applets are in an active state for as long as the HTML page in which they are loaded
is on the browser screen. When a jump is made to another page, then the applets that were loaded on the
previous page become inactive. However, unless there is a shortage of memory, they are not unloaded.
Whenever the browser returns to an applet's page, then the particular applet for that page is not usually
reloaded, but rather it is changed from an inactive state back again to an active state. Variables that were set
in a previous active stage are remembered during times of inactivity, and can be accessed when an applet
again becomes active.
Next ->
Lane Friesen
lanelise@dowco.com
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
