The Transition from Sun to NT

There were only a few CGI processes, all Perl, on the legal publisher's Sun system. It seemed a straight forward process to move them to NT as there were few system dependent features in the scripts. There was one significant surprise. The scripts depended on saved hashes or associative arrays via UNIX's dbm support. It turned out that the SDBM support that is included with Windows Perl has approximately 1K limits on both key and data size. The dbm capabilities on Sun supported much larger sizes and ATLA's CGI scripts made use of much larger record sizes. We paid a consultant to port GDBM which theoretically had unlimited key and record sizes to the Win32 environment. This solved the immediate problem and allowed the scripts to be moved with minimal changes. We did not know at the time that this was going to cause some serious problems nearly three years later.

The largest issues were integrating NT and Lyris with the member database as discussed below. A purely technical surprise was how NT and IIS 2/3 failed to protect scripts in a fashion similar to other OS files. Anyone familiar with IIS knows that the installation creates an anonymous web user. Prior to IIS 4, to allow public access to a web page or directory, NT permissions simply need to be set so that the anonymous user had read access to the HTML file or directory. If the anonymous user did not have sufficient access the server would require either basic or NT Challenge Response authentication depending on how it was configured.

Script Problems under NT and IIS

If you used the same script interpreter, such as Perl, for both public and private scripts, the interpreter had to be executable by the anonymous user. If the script to be interpreted was not available to the anonymous user, IIS and NT did not check prior to invoking the interpreter. Once the interpreter was invoked, and the user was not authenticated and did not have access to the script, an ugly 500 series server error message was displayed. The situation was complicated by different browser behaviour with regard to when basic authentication information that had already been entered by the user was and was not passed back to the server.

The solution was to write a simple security function that was called by all private scripts and which checked if the user had an authenticated user name. If not, the script generated a not authorized condition, forcing the browser to authenticate the user. Initially the new site was like the old with regards to security, the only distinction was between public and member only areas. Later as more differentiation among member types was required, the security function was enhanced to provide the highly granular security described below. Too late for our purposes, IIS 4 later provided a configuration option that accomplished what we were forced to program into the scripts, i.e. the ability for the server to force authentication for scripts without having to build the logic into the scripts.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.