This section describes the components distributed in the Server folder of the ISS kit. If you are not running Microsoft IIS, or would prefer a different folder structure, review the following notes.
The client is configured for DHCP. You must configure the ISS to provide a DHCP IP address to the client when the client connects to the server. Because the sign-up process is relatively short, the expiration time for the IP address lease can be small, possibly only a few minutes.
Because the sign-up processing is intended to be used over a point-to-point dial-up connection, the IP addresses allocated for the DHCP server need not be formally assigned IP addresses. It is your responsibility to determine whether the DHCP IP addresses will be truly valid Internet addresses or arbitrary addresses.
For the client to process the .ins file automatically, you must register a MIME type for the .ins file with the ISS. This MIME type has been designated "application/x-Internet-signup." When the client requests an .ins file, the ISS responds with this MIME type, which starts the associated installation application on the client side.
You must manually edit MIME types in the registry. To add the .ins file MIME type, use Regedt32.exe to add the following information:
Under this key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters\MimeMap
Add this value:
application/x-internet-signup,ins,,5
This value does not have a string associated with it. For more details about setting MIME types, you can also refer to the IIS Help documentation.
Note
To cause these registry settings to take effect, it is necessary to shut down all IIS services after adding the new MIME type. It is not sufficient to simply stop and restart the Web publishing service. (In practice, the FTP and Gopher services are not likely to be running in the ISS configuration.)
This version of the sample ISS was tested on IIS. The following topics discuss installation notes specific to the IIS, as of this version.
The CGI source code is written in standard C and uses a simple Windows initialization-format file for its database. You should immediately modify two sections of the source file:
These sections are identified as the "ISP Customization Section" in the source code comments.
The elements in the data keyword table are used in two ways:
There are two groups of database interface functions:
The transaction start function creates a unique session handle that identifies a given sign-up client throughout the remainder of the sign-up process. As mentioned earlier, this session handle may be a simple sequence number (as demonstrated in the example CGI code) or a transaction identifier generated by your database system. The specific value of the session handle is not important, as long as it is unique and you can use it to track the sign-up transaction.
You use the transaction end function to handle your own database transaction conclusion processing. In the example CGI code, a state flag is set to indicate that the transaction was accepted.
The transaction abort function serves the same purpose as the transaction end function, with you taking the appropriate action to handle the sign-up cancellation.
In addition to the previous CGI code modifications, you may want to validate data for each CGI posting, or wait until the conclusion of the transaction to validate the data entered by the sign-up client. The example CGI code demonstrates the method for validating each CGI posting. If data validation fails in the FormtoDB function, the current HTML template is regenerated and sent back to the HTTP client again. You may want to modify this function (ProcessCurrent) to include an advisory message indicating the data validation error.
The example sign-up CGI processing code was compiled by using Microsoft Visual C++ version 4.1. A project file, Signup.mdb, is included with this kit for rebuilding the CGI processing executable file as needed. Because the database was implemented using the Windows initialization file functions, the source code includes the Windows.h file. Other areas of source code might need to be modified slightly if your HTTP server is not running on a Microsoft Windows platform. However, for the most part, the sample code is quite portable.
The example sign-up CGI processing code was compiled with simple sequentially generated session handles. In any public implementation, these session handles must be generated using a random handle generator. The use of random handles eliminates the possibility of a user guessing the handle of another user (which is very easy with sequential handles).