Home » Tip Bank » XML » XML with Java

Language: Security
Expertise: Beginner

Mar 19, 1997

Question:
I have an applet with dialog boxes, text fields and buttons. What can I do with the user input? How do I get it out of the applet? What else can I do with this data?

Answer:
Perhaps the applet is a query for information. Then you need to find out what the user wanted and display it. But perhaps the user is entering information that you want, an order or a request for more information by, perish the thought, mail or phone. Then you need to get that information out of the applet into your possession. That is the focus of this question.

There is one thing an applet can't do--save information onto the user's local disk. For example, you couldn't write an applet that lets the user do some calculation (say taxes, account records or retirement calculations) and then save the information on the user disk, so that it can be reloaded next time they visit your site and run the applet again. Some people view this as a limitation, but quite obviously it is a security measure. If an applet could save information on the user's disk, it could also overwrite existing files and create executable files with viruses in them. If you need to store user profiles, they must be stored on your server.

Any information that an applet saves must be saved on the site from which the Java applet originates. How do you get it from the user's computer to your server? In a word, with sockets. A socket is a network connection between the applet and a server program running on your server. Let's suppose your applet takes an order from the customer. You naturally want to capture the information so you can fulfill the order.

The applet needs to open a socket to a server socket that is constantly running on your computer. You may have a server socket program such as an SQL interface that is ready to accept queries and transactions. If not, you can either write your own server program, or you can use the Common Gateway Interface (CGI) that is a standard part of the Hypertext Transport Protocol (HTTP), the protocol of your Web server. It is actually quite easy to write a simple server program using Java--much simpler than the same chore with C. But it takes quite a bit of expertise to turn the simple prototype into a reliable and secure production program, so it seems wiser to deal with CGI, byzantine as it may be. Netscape and other vendors are working on adding security (such as the secure socket layer) to their browsers, and they will will focus their efforts on CGI.

To send your customer's order information back to the server, your Java applet needs to contact a CGI script. That script must reside on the same Web server as the Java applet. A CGI script receives data that are sent back from the viewer of a Web page, and it can optionally send a response back to the user. CGI scripts can be written in just about any programming language. For historical reasons, Perl is commonly used, but you can certainly write a Java application (not an applet) if there is a Java interpreter running on the server.

Up to now, CGI scripts were used mainly to process HTML forms, not to interact with Java applets, and they work well with forms. So why don't you just take your customer's order with an HTML form? There are advantages to using a Java applet. The applet can compute totals, taxes and shipping charges. It can check if an item is in stock or if a credit card is valid. All this is much more tedious with forms--you'd have go generate a maze of forms to cover each situation.

Unfortunately, right now CGI does not interact particularly well with applets, and you have to program the interaction by hand. You have two methods of getting information from the Java program to the CGI script. For a small amount of information, the command line argument is simpler. Suppose you want to find out whether an article is in stock. If the script that can check stock is called /cgi-bin/order.pl, then you need to execute the following Java code:

   Query q = "STOCK:" + item_name; // depends on your CGI script

   URL u = new URL("www.where.com/cgi-bin/order.pl?" + q);

   DataInputStream in = new DataInputStream(u.openStream());

   String s = in.readLine(); // contains the first line of the answer

The CGI script then sends the answer back in some agreed format. This can be text format and need not be HTML, so it can be designed to be easy to parse. If you need to send more complex information, you need a two-way socket connection, as follows:

     Socket s = new Socket("www.where.com/cgi-bin/order.pl", 80);

          // 80 is the standard port number for http

     DataOutputStream out = new DataOutputStream(s.getOutputStream());

     DataInputStream in = new DataInputStream(s.getInputStream());

     String outData = . . .;

          // whatever you want to send to the script

          // can be many lines

     out.writeBytes("POST " + script + " HTTP/1.0\r\n");

     out.writeBytes("Content-type: " + ctype + "\r\n");

     out.writeBytes("Content-length: " + sdata.length() + "\r\n");

     out.writeBytes("\r\n");     // end of header

     out.writeBytes(outData);



          // now listen to response



     String inData = new String();

     String line = null;

     while ((line = datain.readLine()) != null)

        inData += line + "\n";

Now you know how to establish a two-way communication. You still need to design a protocol for the information to be sent back and forth, and, of course, you need to worry how to interface between the CGI script and the database on the server side. Java, at least in its initial release, does not solve these problems.