Using ROFM CGI

Contents
Introduction
Set Up
Use
Special Characters
Misc

Serving Your Own Database

The Basics

ROFM CGI allows you to find, get, add, modify and delete records in your databases. Most of these actions may be disabled; so it is easy to prevent users from (for instance) changing anything in a database. ROFM CGI will not even touch a database until you enter its name and permissions in ROFM's Security window. Forgetting to do this is a common mistake, but the resulting protection is well worth the hassle. For more information on security, see the Security section.

Before getting into details, let's follow a transaction from beginning to end. To start things off a user connects to your WWW server and receives a page containing a "form". The user fills out the form and pushes the Submit button. The user's browser packages up the data on the form and sends it to your server, which passes it along to ROFM CGI. The CGI parses the data, talks to your database (which must already be open in FileMaker Pro), formats a reply page and returns it to your server. Finally, the server sends the reply page to the user. Note: it is also possible to command ROFM CGI using links (URLs) instead of forms; that is a detail discussed elsewhere.

Forms may contain text boxes, menus, radio buttons and other such things for the user to fill out or select. These allow the user to specify what to search for, what field to sort by, and so on. Forms may also contain hidden information the user is not expected to change. This usually includes such things as the name of the database and what to do (e.g. find records or add a record). Be warned that hidden information is not truly secret; any user can view the a form as plain text ("source") and see and change anything they like. That is why it's important not to permit adding, modifying or deleting records in a database unless you really mean it!

Though forms may look complicated, at their heart they are very simple. Forms simply consist of a number of fields each of which has a name and a value. Text boxes, menus, radio buttons and hidden fields are all just different kinds of fields. The only information sent when a form is submitted are the field names and values. ROFM has no idea what the form looked like, nor what kind of fields were on it.

If a field's name begins with an underscore (_) then ROFM CGI treats it specially. Such fields are called parameters and are used to tell ROFM CGI what to do and how to do it. All other fields are database fields; each of these must have a name identical to a field in the database (but case doesn't matter). For more information about forms (and links, and alternate way to command ROFM CGI) see the section on forms.

Let's look at an example. Suppose a form contains the following fields:

<input type="hidden" name="_database" value="bb.db">
<input type="hidden" name="_action" value="Find">
<input type="hidden" name="_field" value="HTMLLink">
<input type="text" name="Author">

And the user has typed the value "Joe" into the "Author" field.

This tells ROFM CGI to talk to database "bb.db", finding all records for which the field "Author" contains a word beginning with "Joe". ROFM CGI then reads the field "HTMLLink" from each found record, formats it into a return page (as discussed next) and returns the result to the user.

Let's look at the return page more closely. The main body of the reply consists of data read from one field in the database, the one specified by the _field parameter. For searches this field is read from every found record (and is blank if no records are found) and the results are concatenated together, one after another. Typically this field is a calculation field that combines data from many other fields in the record to produce a nicely formatted result. For examples of this see the fields "HTMLSummary", "HTMLLink" and "HTMLRecord" in the sample database "bb.db".

The returned page may also include a header at the beginning and a footer at the end. Custom headers and footers may be created in ROFM CGI using the "Headers" and "Footers" window. These can then be specified by name using the _header and _footer parameters. If you do not specify a custom header or footer then a default (which you cannot change) is used. Headers and footers may contain more than just plain text; they may also include certain variables to display the current date, the number of records found, etc.

At this point I encourage you to skim the rest of this section of the manual and then try searching one of your own databases. Start by modifying a copy of "bbFind.html". Initially set it to return some existing field in your database. Once you have that working, try creating a simple calculation field in your database analogous to "HTMLSummary" or "HTMLLink" in "bb.db", and return that. Feel free to use whatever you can from the sample forms and database.

Finding and adding records are fairly straightforward to set up and fairly safe, since existing data cannot be corrupted or destroyed. Modification and deletion of records are significantly more difficult and dangerous. I strongly encourage you to postpone working with them until you have mastered Find and Add and carefully read all of this chapter of the manual.

Prepare Your Database

There are a few reserved field names you should know about. If any of the following fields exist in your database they will be set automatically on "Add". If you are already using these field names for another purpose then you must rename the existing fields!

client_address The IP address of the client's computer. This is not an email address, and is not even unique to a user (more than one user may be running from the same computer at the same time) so it is typically not very informative. This data is generated automatically by the CGI; do not put a "client_address" field in your Add form, as it will be ignored.
referer The URL of the Add form. Note that not all WWW clients supply referer information, so it is safest not to rely on this information. This data is generated automatically by the CGI; do not put a "referer" field in your Add form, as it will be ignored.
_username If present, then a "_username" field must be present on Modify and Delete forms, and the values must match. This field may be set using a "_username" field on Add records. The name begins with an underscore so that the data cannot be directly retrieved by ROFM CGI.
_password If present, then a "_password" field must be present on Modify and Delete forms, and the values must match. This field may be set using a "_password" field on Add records. The name begins with an underscore so that the data cannot be directly retrieved by ROFM CGI.

Every field you want to access via the CGI must obey certain rules:

They cannot be repeating fields. (You can probably set repeating fields, but no promises. You definitely cannot read them.)
The field name must not include special characters, such as spaces, tabs, "+", "=", ":" or "$".
The field name must not start with an underscore (_), except for a few reserved field names discussed above. The CGI cannot access fields whose names begin with underscore. This is a useful security feature because all other fields in the database may be read by anybody.

Create calculation fields to format the returned data. You will probably need several of the following types of fields:

A complete HTML-formatted copy of the record (see HTMLRecord in bb.db). This is useful for Add, Get and possibly Modify or Delete.
A text-formatted copy of the record (see TextRecord in bb.db). This is useful for emailing copies of newly added records.
A brief one-line summary of the record (see HTMLLink and HTMLSummary in bb.db). This is useful for Find and FindLinks.
A fancy HTML-formatted Modify form (see HTMLModifyRecord in bb.db). This is useful for supporting modification of records.

These fields may include HTML tags, pointers to images, pointers to other documents, even URLs that access this (or any other) CGI.

Modify and Delete forms must refer to the record by record ID number, a number that is unique to that record for the life of the database. Unfortunately, FileMaker Pro does not allow one to obtain this useful number within a calculation field. To get around this problem, fields may include the variable "__RecID" (which starts with two underscores). This string will be replaced by the record ID number before it is returned to the user. Warning: due to speed considerations this substitution does not (yet) occur for data returned by "Find" and "FindLinks".

Specify Security Information

You must tell ROFM CGI about each database you wish to serve. Select "Security..." from the "Configure" menu, then create a new entry for each of your databases. Specify the name of the database file (without directory information), and whether to permit reading information and adding records. Note that you can change the information any time the CGI is running; it will take effect as soon as you click the "Save" button. For additional security considerations see the section on security.

Create The Forms

Set up at least one form for each database and action. Forms for finding and adding records are usually text files like the ones supplied, though some users serve them from a database. I suggest using the sample forms as templates, modifying them to suit yourself. Be sure to examine "bbFind.html" because it is liberally commented. Forms for modifying and deleting records usually must be created in your database using a calculation field. For example see the field "HTMLModifyRecord" in the sample database "bb.db". Once you set up your calculation fields in the database to create modify and/or delete forms, you may access them via a search form such as "bbFindToEdit.html". For more general information about forms I suggest that you browse the World Wide Web and/or buy a good book (please don't ask me for recommendations). Most HTML editors contain tools to help you create forms.

Your forms should contain the following elements:

a Submit button, which must be named "Submit"
a Reset button
various parameter fields to control the behavior of the CGI. Any field whose name begins with an underscore (_) is a parameter field.
database fields: fields on the form corresponding to fields in the database. Every database field in the form must have exactly the same name as a field in the database (ignoring case).

If you misspell the name of a database field, or include one that does not exist in the database, you will get erratic behavior. Blank fields are ignored by the CGI (except for Modify), so you will only trigger the problem when the misnamed field is actually filled in. Such problems can be very frustrating and hard to track down, so please always test your forms by filling in every single field. If you can successfully submit the form with all field names filled you can be sure all database field names on the form are spelled correctly!

Data in double quotes must have certain characters encoded. Please see special characters for more details.

Constants (information the user cannot change) may be specified using a hidden input field or placed after the ? in the action, or any combination of the two. The form bbFind.html shows both. The format for specifying constant data after the ? is as follows:

<form action="ROFM.acgi?fieldName1=value&fieldName2=value..." method="post">

Data after the ? needs special encoding. Please see special characters for more details. In particular, note that to send & or = as data to the CGI you must encode them as %2526 and %253D, respectively.

If all data is constant you may also send requests to ROFM CGI using URLs. This is how the links returned by bbFind.html work, and is also handy for "fixed" searches (such as a link that always returns the most recent entry). But be careful when using URLs; they can only pass about 2k characters of data, whereas forms can pass over 20k characters. URLs are formatted as follows:

<a href="ROFM.acgi?_param1=value&_param2=value&...fieldName1=value&fieldName2=value...">text of link here</a>

For example (from Default.html):

<a href="ROFM.acgi?_action=Find&_database=bb.db&_field=HTMLLink">Get every record from the bulletin board</a>

The rules for encoding are similar to those for action data (as discussed above). In particular, note that the two characters "&" and "=" must be specially encoded as %2526 and %253D if they are used as data. Please see special characters for details.

Parameter Fields

Parameter fields are special fields in a form used to pass data to the CGI, rather than to the database. Every parameter field's name starts with underscore (_), and in fact any field whose name starts with underscore is assumed to be a parameter field. Many of these fields are optional, and some are relevant only for certain kinds of forms (and are ignored if present on other forms). The parameter fields are as follows:

_action (required) the action you wish to perform: Add, Delete, Find, FindLinks, Get, GetVersion or Modify.
- Add adds a record to the database. Empty fields on the form are ignored. This is useful for defaults: if the database auto-enters data in a field, it is only overwritten if the user specifies data for that field.
  The parameter _field specifies a database field that is read after the record is added. Typically this is a calculation field that formats the acknowledgment in the desired fashion. You may also email data from the newly added record via the _email... parameters.
- Delete deletes a record specified by _recID. You may specify _field to retrieve information from the record before it is deleted, as well as _email... to email notice of deletion. Note that a Delete form is usually not a text file, but instead is generated using a calculation field in the database. For example see HTMLModifyRecord (which allows deletion as well as modification) in the sample database bb.db.
- Find searches the database, returning the found data. Empty fields on the form are ignored (if all fields are empty then all records are found). You may sort the found data using _sortField and limit the number of records returned using the parameter _maxRecords.
- FindLinks like Find but formats the returned data as links to the records. Typically _field will point to a calculation field that is a summary of information about the record; it should not contain a link to the record, as the CGI supplies that itself. Use _linkField to specify the field to read when returning the complete record. Note: FindLinks is somewhat slow when returning large numbers of records; for best speed set _maxRecords lower or preformat the link (along with the rest of the data) inside FileMaker Pro and use Find instead of FindLinks. I hope to speed up FindLinks someday (but am waiting for an enhanced ACME Script Widgets).
- Get retrieves a single record. The record may also be emailed using the _email... parameters. The record is typically specified by record ID number using _recID. But record ID numbers can be a pain to use, so Get also supports a limited form of searching: you may omit _recID and specify exactly one database field with non-empty data; the first record (in creation order) that matches the search criterion is then returned. If you want to always retrieve the correct record using this search technique then you must be sure that the field being searched contains a unique value for each record.
- GetVersion returns ROFM CGI's version number. Takes no parameters. Does not interact with databases.
- Modify modifies a single record specified by _recID. All fields specified are modified, so blank fields are emptied. All standard parameters are accepted, for instance the modified record may be returned using _field and emailed using _email.... Note that a Modify form is usually not a text file, but instead is generated using a calculation field in the database. For example see HTMLModifyRecord in the sample database bb.db.
_database (required except for GetVersion) the name of the database file (not the full path, just the name of the file).
_field specifies a field in the database. Only data from this field is returned as a result of submitting the form. Typically the field is a calculation field that pre-formats the output data; it may include HTML tags including pointers to images, other documents, etc. The returned page is formatted as follows: _header + _recHeader + _field[1] + [_recHeader + _field[2] + ...] + footer, where _field[1] means data from the first record to be returned, etc., and the data in [] is only present if more than one field is to be returned.
_layout specifies the name of a layout in the database. If omitted, layout 0 (zero) is used, which contains all fields local to the database but no fields from related databases. Note that _layout can only specify a layout name, never a layout number. As a result, layout 0 may only be specified by specifying _layout = "" or omitting _layout entirely; _layout = "0" will attempt to find a layout named "0".
So what use is _layout? Its main purpose is to support access to data from relational databases. Layout 0 does not include any related fields from other databases; if you want to access relational data must either incorporate it into a local calculation field or else use a named layout that includes the related field (plus any other fields your form uses). Also, if your database has many fields, it might speed up access if you use named layouts that contain only the required fields. However, in general it is safer and easier to omit _layout unless required. Then you don't have to worry if the layout is missing a required field, a potential problem every time you modify your forms and databases.
_linkField (for FindLinks only; optional but strongly recommended) specifies the field to read when returning the complete record (by clicking on the link). If omitted, "_field" is used, but this is the same field used for the link already, so it's not likely to be useful.
_maxRecords (for Find and FindLinks only; optional) specifies the maximum number of records per page to return. If additional records are found then a "next page" link will retrieve additional records. If omitted or left blank then a non-user-settable default is used.
_recID (required for Delete and Modify, optional for Get) specifies the ID number of a record. Note that in a given database each record has a unique ID number that will never be assigned to another record. Unfortunately, this ID number cannot be accessed from within the database (e.g. in a calculation field), which makes formatting Delete and Modify commands a real hassle! ROFM CGI supports a workaround, however. When Get retrieves a record, all instances of "__recID" are replaced by the record's ID number; only Get performs this substitution.
_skipRecords (for Find and FindLinks only; optional) specifies the number of records to omit from the returned data. This is primarily intended for automatic use by the CGI to support multi-page searches. The default is, of course, 0.
_sortField (for Find and FindLinks only; optional) specifies the field by which to sort the found data. To sort in reverse order pre-pend a minus sign to the field name, for example "-Date" (there must be no space between the minus and the field name). Unsorted data is returned in record creation order. Sorting requires FileMaker Pro to sort all found records; this can take significant time if many records are found on a slower computer.
_footer (optional): the name of a custom footer define in the CGI. The text of the footer will be used to end the returned page. Footers should include </body> and end with </html>. See _header for a list of special strings that can appear in footers.
_header (optional): the name of a custom header defined in the CGI. The text of the header will be used as the beginning of the returned page. To edit custom headers, record prefixes and footers select the appropriate item from the "Configure" menu. Headers should start with <html><title> and include </title> and <body>. Headers and footers (but not record prefixes) accept the following variables (special strings that have data substituted for them before they are returned):
- __currDate is replaced with the current date (long format)
- __timeList is replaced with timing information of the form: "oper1, oper2, ...: time1, time2, ..., where the operations depend on the action (Find, etc.) and the times are in integer seconds.
- The following are only supported by Find and FindLinks
- __begNum is replaced by the number of the first record shown (where the first record found is 1)
- __endNum is replaced by the number of the last record shown (where the first record found is 1)
- __nFound is replaced by the number of records found
- __nShown is replaced by the number of records shown on this page
- __nextPage is replaced by a link that retrieves the next page of found records (if more than one page is needed)
The default header and footer vary according to the action but are typically pretty minimal. The default for Get is no header or footer at all, because you get more flexibility by including the header and footer information in the calculation field that formats the Get output.
_recPrefix (for FindLinks only; optional): the name of a custom record prefix defined in the CGI. The text of the prefix will be pre-pended to each record returned. The default is <LI>.
_emailBody (for Add, Delete, Get and Modify; optional): the name of a field in the database containing the body text for the email message. If omitted, a default is used.
_emailTo (for Add, Delete, Get and Modify; optional): the name of a field in the database containing one or more email addresses separated by commas. If omitted, or if the specified field is empty, no email is sent. Emailing data requires that Eudora 1.5 (free) or Eudora Pro (commercial) be available, and preferably running. Note that the meaning of _emailTo changed in version ROFM CGI 4.3 and that _emailToPtr was eliminated.
_emailSubject (for Add, Delete, Get and Modify; optional): the name of a field in the database containing the subject for the email message. If omitted, a default is used.

Tips for Best Performance

Turn off smart quotes in FileMaker Pro (this is one of the preferences), and eliminate any curly quotes and double-quotes that are in the database. Many WWW browsers display such characters strangely, despite some or all of them being in the ISO Latin 1 character set.
To serve graphic images, you may store the images as GIF or JPEG files, and serve standard HTML links to the files, e.g. <img src="....GIF">.
Make sure you have enough real memory to fit your WWW server, ROFM CGI and FileMaker Pro all at the same time. If you don't have enough real memory you will not get adequate performance, because some of these applications will have to be paged out during each access to the database. I find that 16Mb is adequate on a PowerMac if virtual memory is on (all applications require more memory if virtual memory is off!).
Make sure that FileMaker Pro is in the background, and preferably hidden. If it is in the foreground performance will degrade significantly. Unfortunately, putting it in the background can occasionally cause trouble. If a field you are searching has not yet been indexed, or (sometimes) if the database is simply very, very large, FileMaker Pro will put up a dialog box while searching. If FileMaker Pro is in the background when it puts up this dialog box, it will halt until it is brought into the foreground, and all attempts to access it from ROFM CGI will time out. This bug is seen in FileMaker Pro 3.0v1 and 3.0v2. It is hoped that eventually Claris will fix this problem.
Add bogs down if you have a very large number of fields on the form. Try to avoid forms with 50 or more fields (this is usually nicer for the user, as well).
Add takes significantly longer if you have many calculation fields that whose results are stored (and hence must be calculated immediately). Unfortunately, the default for FileMaker Pro calculation fields is "stored". Click the "Storage Options..." button to change this setting (it's the last check-box in that dialog). Most calculation fields for ROFM should be unstored; the only exceptions are fields that may be searched, and fields that are returned as the result of a Find or FindLinks (because many records may be returned at once, and calculating them on the fly can slow things down).
Emailing records adds some time. Eudora 3.0 appears to be reasonable, but older versions took 5 seconds on a PowerMac 7100 (despite not waiting for the mail to be sent). Please be sure that Eudora is already running, or the first time a record is emailed ROFM will have to wait while Eudora launches.
Find results are formatted more quickly than FindLinks results. You can use Find in place of FindLinks by including the URL to the record in the data returned by Find (as demonstrated by the sample form bbFind.html and calculation field HTMLLink). The improvement is negligible if the search only returns 10 records, but noticeable for 50 or more records.
Sorting slows things down a bit, especially on slower computers. Note that all found records must be sorted even if there are too many to return on a page. This will slow things down for every page of a multi-page search. Avoid sorting if you expect to find a very large number of records.
If your server is timing out waiting for a reply and you can live with the lack of speed, increase the server's time limit. But this should not be happening with adequate memory and a reasonable computer, so first see if you can't fix the problem before working around it!
Using a faster language for the CGI would give better performance; I probably will not have time, but would be happy to offer advice if somebody is willing to tackle it. Also, AppleScript itself should get faster over time (the current version is not even PowerPC native).

Troubleshooting

If the "next page" link fails (especially for searches involving special characters), you are probably using the wrong version of ROFM CGI. ROFM CGI version 4.2 and later should be used with WebSTAR 2, QuidProQuo 2, and other browsers that do not hex-decode the HTTP search arguments. Version 4.1-B should be used with WebSTAR 1, QuidProQuo 1 and other browsers that hex-decode the HTTP search arguments.

The error: "ROFM CGI is not allowed to access database ..." indicates that the database has not been entered in ROFM CGI's Security window. Only databases listed in the security window may be accessed.

A complaint about needing "FaceSpan Extension" at startup probably indicates that QuickTime and/or (if you have a PowerMac) QuickTime PowerPlug are not installed. It can also occur if some component of AppleScript 1.1 is missing (if in doubt about this you can easily install AppleScript from your system installer disks).

If ROFM CGI pauses while starting up and then gives an error "Finder got an error: Apple Event timed out" and if you are using MacOS 7.5 or 7.6 then the file "Finder Scripting Extension" is probably missing from your Extensions folder (in your System Folder). Run the Extensions Manager control panel to make sure this file is present and enabled. This file is a standard component of MacOS 7.5 and 7.6, but is not part of MacOS 8.

The error: ''you must specify a database" may mean that you put data after a "$" instead of a "?" in your <form action...> field or URL. The character was a "$" for ROFM CGI 4.0, but is a "?" in 4.1 and beyond (as well as older versions of ROFM).

If your search form returns all records in the database, no matter what you enter into the various fields, you probably have two fields with the same name in your form. Thanks for Jon L. Gardner for reporting this.

The error: "database ... does not understand the 'exists' message" is caused by a bug in Apple's ObjectSupportLib. The solution is to obtain ObjectSupportLib 1.2 (or newer) from Apple, Version 1.2 was released after System 7.6, but presumably will be included with MacOS 7.6.1 and beyond.

If an operation return just a header and footer with no data from the record(s), make sure that you have specified _field. If you don't specify _field then no data from the database is returned (this can be a feature).

Email has very poor error handling. If the email address is bad or the server cannot be found, Eudora will display a dialog box and stop responding to apple events. The best you can do for now is to check "Say OK to alerts after 2 minutes" in the "Getting Attention" settings panel. I am considering alternatives to Eudora and have also reported the problem to Qualcomm as a bug in their apple event handling.

If a field is claimed to not exist on layout "0", this means that the field does not exist in the database. Perhaps you mis-spelled the field name, or perhaps the field is a related field instead of one in the database. Layout 0 is the default layout and contains every field present in the database, but no fields from other related databases. To access fields from related databases you must specify a layout containing the field.

If acesses are very slow, please see Tips for Best Performance.

If you are getting mysterious failures, please check the following:

Open the log window (select "Log" from the "Configure" menu). The log window shows information about the most recent request (but it does not save any information about previous requests). Turning on verbose logging for your WWW server may also help.
You are accessing the form by connecting to your WWW server, rather than opening your form as a file. This is an easy mistake to make if you are running your browser on the same machine as your server.
AppleScript 1.1 or later, and it is fully and correctly installed. AppleScript 1.1 comes with MacOS 7.5 and 7.6, and AppleScript 1.1.2 comes with MacOS 8. Older versions, including the version that came with system 7.1.2, will not work, and partial installations can cause very odd results.
You have FileMaker Pro 3.0. Older versions will absolutely not work with this version of ROFM CGI; guaranteed!
ROFM CGI is fully running; it takes 15-30 seconds to start up, and will ignore attempts to access it until then.
You have installed the scripting additions correctly and rebooted afterwards. If ROFM doesn't complain about this at startup then it is probably not a problem.
And of course, the old standby: try giving ROFM.acgi more memory. Too little memory can cause a crash at startup, a dialog box at startup reporting a "script error", or a message "cannot save changes" when you quit ROFM CGI.

Security

Serving a database puts it at great risk. A user can write and submit their own forms, so users can do anything the CGI allows regardless of whether you provide a form for it. For example, just because your forms don't access a particular field in the database doesn't mean that field cannot be read. Please read this section carefully.

ROFM CGI offers three types of security:

The security window (required): the security window tells ROFM CGI which databases it can access, and which actions are allowed on that database. If a database is not listed in the security window then it cannot be accessed.
Field protection (optional): fields whose names begin with underscore (for example: "_username") cannot be read; specifying such fields for parameters _field, _emailField, etc. will result in an error. Note that all other fields in the database can be read by anybody. If you have sensitive data in the database be sure to rename the relevant fields with a leading underscore, and be sure that this data isn't available in some other field (such as a calculation field).
Password protection (optional): if your database includes the special field names "_username" and/or "_password" then the same field(s) must be present on any Modify or Delete form, and the value(s) must match. If these fields are not present in the database (and Modify or Delete privilege is permitted in the security window), than anyone can modify or delete any record! Be very careful to spell these field names correctly in the database, and test the results!

Your WWW server probably allows you to restrict access to various CGIs (restricting access to your forms is not good enough; users can generate their own forms.) Read your server's documentation for help with this. This feature (if present) can be used to offer different sets of users different levels of access to your databases, as follows:

Create multiple copies of ROFM.acgi, one per category of access.
Rename each copy to a unique name. This is crucial, as otherwise apple events may go to the wrong copy, causing "unexpected behavior" and loss of security. It will also help you keep track of which copy you are configuring!
Put each copy in its own folder; this is necessary to keep preferences files separate, and so allow each copy to have its own security settings.
Set your WWW server to appropriately protect each copy of ROFM CGI.
Create a local preference file for each copy as follows:
- Run any copy of ROFM CGI. Specify any settings that you wish to be common to all copies of ROFM CGI, and save the settings.
- Find the file "ROFM CGI prefs" in "System Folder:Preferences".
- Put a copy of that file into each of these folders you created. The copies must also be named "ROFM CGI prefs", or they will not be seen!
Finally, run each renamed copy of ROFM.acgi and set its preferences as desired. Please be very careful to keep track of which copy of ROFM CGI you are configuring, else your attempts at security may backfire.

Be warned that you should not allow heavy use of any but one copy of ROFM CGI; the other copies should only be for occasional high-security access. The problem is that FileMaker Pro can only handle one request at a time. If one copy of ROFM CGI is accessing a database and another copy attempts to do anything with FileMaker Pro (even in an entirely different database), the second access will fail with a "database busy" error message. You may be able to avoid this problem by running multiple copies of FileMaker Pro (each with its own name), but I am not sure FileMaker Pro supports this.

FileMaker Pro allows you to password-protect various elements of a database, including adding records and reading specific fields. But once a database is opened using a secure username and password it becomes vulnerable to access by the CGI, so this mechanism must be used with great care. Also note that a protected database will ask for a username and password when it is first opened; so automatic startup you will probably require a special script to open your databases. For help setting up usernames and passwords, please read the FileMaker Pro documentation or contact Claris technical support.

Please be sure to test all security features before relying on them, especially for sensitive data. Don't just assume things work! For instance if the fields _username or _password are spelled wrong in the database then that protection will be inactive. Also, ROFM CGI (like most software) is not guaranteed to work correctly. Your best defense is to try to break the system yourself. Feel free to read the source code and see what ROFM CGI is actually doing. If in doubt then don't serve your data!

Support

If you have questions or comments about this CGI, or wish to be notified of new versions, please subscribe to the FileMaker Pro CGI Mailing List. I do not usually have time to respond to personal email about this CGI. Please do not try to contact me by phone regarding this CGI; I have a day job and would like to keep it (though am open to alternate possibilities).

If you improve the script, please let me know, and if possible email me a copy of the improved script. I would be especially interested in hearing of a translation to a faster language.