General Guidelines

There are many other security issues to consider. Here are some general suggestions to follow:

•  When someone knows the URL for an application, he or she can just enter it into his or her browser. Make sure your application’s modules, individual procedures, and so forth are protected, or put something in the beginning of each module to check for user authentication (see the discussion about PL/SQL cartridges and cookies for an example).

•  The WAS Adminstrative Listener, by default, is available on the network along with the application. Watch this carefully. Don’t let it be too available to the general community. Change its default settings. Change its port. Change its access from username access to IP-restricted access. And don’t let it run when you don’t need it. You can shut it down and start it back up later (make sure you know how to restart before you shut it down).

•  I can’t tell you how many contracts I’ve worked on when I’ve tried to log in to the Oracle account SYSTEM with the default password MANAGER, and got right into this crucial DBA account, even on installations that have been in business for years. Change your default passwords!

•  Don’t make operational data immediately accessible through the Web. In other words, don’t let your cartridges have access to your only live copy of a database. Instead, store your original data source in a different user account; then create a second account that uses snapshots to copy data, and have your Web applications access the snapshots. Better still, for read-only Web applications, such as a data warehouse, put the original data on a different physical machine and use a periodic manual procedure to move data from the source to the Web database. This will guarantee that no hacker could possibly attack your source data through the Web applications.

Remember, while the WAS offers good security features, there is never any guaranteed protection. You can never eliminate the possibility of a successful attack, not with any system. You can only minimize it.

One final important note regarding security: Most successful hacks into an application do not come from computer wizardry but from classic con games. Someone calling your central operations center pretending to be working late on a project on a Sunday night and who demands to know the password to the SYSTEM account or his entire project will fail—this scenario is more likely to be a successful hack than someone sitting in his home office trying every password he can think of to get into your system. All the software security features in the world will not help you at all if your office procedures are not tight. Keep that in mind when establishing a security program for your application.

Developer/2000 and the Oracle WAS

The latest version of Developer/2000, version 2.0, includes some truly amazing features when combined with Developer/2000 Server (separately, Forms Server and Reports Server) and the WAS. These features allow developers to create applications as usual, but deploy them across the Web.

Forms

When forms runs on the Web, the form application itself is stored on the server. When a user requests a form, the Developer/2000 Java applet is downloaded to their browser and the Java applet communicates with the form application, which executes on the server, to exchange information with the application regarding display, user input, and so on. The Java applet is able to recreate the form in the user’s browser in a rather striking manner, looking virtually identical to the original application. This truly is an amazing benefit to developers, allowing cost-effective and rapid application deployment, which now consists of storing the application on the server and publishing its URL to your users.

Forms can be delivered across the Web because of the way that Oracle happened to originally build the Forms product. The logic that controls the display is loosely inte-grated with the logic of the application and its integration with the database. As a result, Oracle is able to separate these two components, sending the display management to the Developer/2000 Java applet that downloads to the user’s browser, and retaining the application’s executable on the server. As the application (the FMX) executes on the server, it sends “bundles” of interface commands from the Forms Server to the Forms Client for managing and directing the client’s form display. All triggers are processed on the server, and all user interface processing occurs on the Forms Client.

Since the Forms Client is a generic Java applet, you don’t need to download separate applets for each application or each form. The Forms Client is smart enough to download only those Java class files that it needs. As the Forms Client makes additional requests during the user session, additional class files are downloaded on an as-needed basis. This keeps the Forms Client thin and efficient.

To deploy a form on the Web, you need to generate the form for the operating system that the application server is running on, either UNIX or Windows NT. If your form has already been running on a client of UNIX or NT server, don’t make the mistake of thinking that this is good enough—you must generate the form on the server operating system. You don’t need to do anything to the FMB file, you just need to move the FMB to the environment that is being used on your server, and generate the FMX file there.

For your users to access your form, you must create a static HTML file with hyperlinks to click to start your application. These hyperlinks should point to your FMX files, including any relative addressing required, just like any other hyperlink URL for a local file or application. Note that for these links to function you need to make sure FORMS45_PATH and TK23_ICON (or FORMS50_PATH and TK30_ICON) contain the directory where your FMX files are stored, or the hyperlinks won’t find your application.