This document provides information that an experienced Internet server administrator can use to implement an ISS. It assumes that you are already familiar with HTTP, Hypertext Markup Language (HTML), and Common Gateway Interface (CGI) processing. If you are not familiar with these components, click HTTP and CGI to access information about official HTTP specifications and Common Gateway Interface (CGI) specifications.
The ISS adds a new customer to the ISPÆs database in three steps:
A potential customer opens a sign-up program that starts Internet Explorer, dials the ISS, and posts an initial CGI request. The ISS:
If you are using Microsoft Internet Information Server 3.0 (IIS), carry out the steps below to copy all files in this ISS Server folder to the InetSrv folder on the IIS system. If you are not using IIS, see Understanding the Server Folder Components for details about where to place the components.
To the WWWRoot sub-directory: xcopy
If you are using the sample sign-up server without modifying signup.exe, you must use the default directory structure for IIS. If you have a different directory structure, you will see the following CGI error after you submit the final request to create the .ins file in the insfiles directory in WWWRoot:
"The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:"
The error occurs because the CGI application source code has hard coded directory paths and if the code is not modified, then it requires the default directory structure for IIS.
To the Scripts sub-directory: xcopy
To modify options
To create a guest account
To modify the acc2.ins file
The following entries are generally required for all users, and must be added manually to the .ins file. Be sure to review these entries carefully, because no error checking is provided.
Note: There can be cases where these entries will vary by user, typically when different users are serviced by different networks.
| Section | Entry | Comment |
| [Entry] | Entry_Name | May vary for private label customization |
| [Server] | All entries | |
| [TCP/IP] | All entries | |
| [Custom] | All entries | Not required |
| [Custom_File] | All entries | Not required |
| [Scripting] | All entries | Not required |
| [Script_File] | All entries | Not required |
The following entries are user-specific, and must be added to the .ins file (except for the Internet Mail and News entries, which are necessary only if Internet Mail and News features are provided by the service). The mechanism for placing these entries dynamically in the file varies based on the services available on your server. Usually, user input is required at sign-up. Most servers support some macro mechanism associated with CGI that makes the process easy.
| Section | Entry | Comment |
| [Phone] | All entries | |
| [User] | All entries | |
| [Internet_Mail] | Email_Name | |
| . | Email_Address | |
| . | POP_Logon_Name | |
| . | POP_Logon_Password | |
| [Internet_News] | NNTP_Logon_Name | |
| . | NNTP_Logon_Password |
For Windows 3.1, all Internet Mail and News entries must be set or none of the settings will be used.
If users are assigned to different servers, the following entries need to be changed to replace the information entered into the wizard.
| Section | Entry | Comment |
| [Internet_Mail] | POP_Server | |
| . | SMTP_Server | |
| . | Domain | |
| [Internet_News] | NNTP_Server |
Collecting sign-up information from the customer involves creating a sequence of HTML pages and uploading them, on demand, from the ISS to the HTTP client. The sequence of pages walks the user through the sign-up process, much like a wizard in a Windows-based program. Although the content and format of the pages are entirely up to you, each page typically includes:
To create customer sign-up pages
Note: In addition to providing a link to your sign-up server information, you will need to provide a link that enables users who already have Internet accounts to access your custom browser.
Creating a wizard-like interface in HTML pages requires that you use HTML forms and CGI processing. Each form gathers information from the user and uses the GET method to pass the information to the CGI processor whenever the user clicks a navigation button. Typically, each HTML page includes a form that contains the following controls:
After recording the data, the CGI processor determines which button control initiated the posting and uses that information to construct the next HTML page to upload to the customerÆs desktop computer. The CGI processor dynamically constructs the next page from an HTML template that contains variable tokens. When the processor parses a variable token such as a $SessionHandle token, it replaces the token in the HTML stream with the appropriate variable value. Finally, the processor writes the dynamically created HTML file to the HTTP client by means of the standard output stream.
Using dynamic HTML provides the ability to pre-load the form controls with data. This enables the customer to navigate backward and forward through the HTML pages to review or edit previously entered data.
The CGI processor uses a unique session handle to identify all transactions belonging to a particular sign-up session. The processor embeds the session handle as a hidden control in the HTML forms that it uploads to the HTTP client. The client returns the handle with each form that it posts back to the CGI processor.
Because HTTP is a session-less protocol, the only way the ISS can determine if a sign-up session has been abandoned is by means of an external watchdog process. When the sign-up session is initiated, the ISS creates a time stamp and registers it in the sign-up database. The watchdog process scans the database periodically and determines if a session has exceeded the nominal time allocated for signing up. If so, the watchdog process assumes that the session has timed out and aborts this sign-up transaction.
Click smplform.txt to see a sample form for collecting a customerÆs name and address.
The customer sign-up session is concluded when the customer either accepts or declines the sign-up agreement by clicking the appropriate button control on the final ISS HTML page.
If the customer accepts the sign-up agreement, the ISS builds an Internet sign-up (.ins) file that contains information about the customer and the ISP, and redirects the HTTP client to this .ins file. A Multipurpose Internet Mail Extensions (MIME) type of "application/Internet-sign-up" has been created for this file. This MIME type is associated with the configuration program on the HTTP client. When it receives data from the .ins file, the HTTP client sends the data stream to the configuration program, which continues with the sign-up procedure. This is the official handoff of responsibility from the ISS back to the HTTP client.
If the customer declines or quits the sign-up agreement, the ISS redirects the HTTP client to an "Abort" .ins file that contains only a "Status=Abort" key. As in the acceptance sequence, this is the end of the ISSÆs responsibility.
In both of these conclusions, the ISP database must be informed of the result of the final decision. While processing the final CGI request, during which time the Accept or Cancel .ins file is created, you should perform any required database processing needed for handling the conclusion of the sign-up transaction. In the sample sign-up CGI code, for example, the transaction state is set to either "Accepted" or "Canceled." This is the strategic section of code that is provided in this kit; you must adapt this code to your specific database environment.
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.
This version of the sample ISS was tested on IIS. The following topics discuss installation notes specific to the IIS, as of this version.
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:REG_SZ: 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.)
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:
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.