Frontier Scripting

ODB name:suites.allowdeny
Version:1.0.2
Version Date:1998/08/11
Compatibility: F4.2.3 - F5.0.1 - F5.0.2b - F5.1+ - F6.0
Download: Binhex file for Mac (16 kb)
ZIP file for Mac or Windows (10 kb)
Binhex file for Mac and Frontier 4.2.3 (12 kb)
Release notes

The AllowDeny Suite

Created by Samuel Reynolds.


Overview

When creating CGI scripts, it is often useful to limit (by IP address or domain name) the range of clients that are allowed to call the CGI on a particular server. Without such limitations, an unscrupulous (or just ignorant) web denizen could make use of a CGI on any server for his or her own pages; this can result in a server being loaded down by CGI calls from pages belonging to users who are not otherwise associated with the server. This is sometimes referred to as "CGI theft."

A well known example is the ubiquitous page hit counter. There is a long history of hit counters being "stolen" for use on distant servers across the web.

The AllowDeny suite provides an allow/deny mechanism to enable any Frontier CGI to determine whether a given IP address or domain name should be allowed to access the CGI's service(s). If the client is not allowed to call the CGI, it could return an error message or nothing to the client, instead of its service product.

Note that the meaning of "access" depends on the code that uses this mechanism. For a hit counter, for example, "access" simply means use of the hit counter CGI to maintain and update a hit count; when access is denied, the CGI will return of an empty string, a Not Found response, or a nasty error message about hit counter theft on the world wide web (or maybe just an "Unauthorized CGI access attempted" message).

Compatibility

This suite works in Frontier 4.2.3 on MacOS, and in Frontier 5.0.1 and later on both MacOS and Windows.


Copyright and Permissions

Created by Samuel Reynolds.
Copyright © 1997 by Samuel Reynolds. All rights reserved.

Permission is hereby granted to use this software for private or commercial use at no charge, and to distribute it with this documentation in its original form. You may modify the software for such purposes, but may not distribute the modified versions of the scripts. You may not sell this software, either as is or as part of another product, without express written consent from the author.

If you have suggestions or changes you think should be included for distribution with future versions of this software, please contact the author at <reynol@primenet.com>;.


Allow/Deny Rules

In a nutshell, the allow/deny rules adhere to the following logic:

    o If there is a table named "allow", use restrictive rules: o
      o Only client addresses/domains found in the "allow" table may have access.

      o The "deny" table explicitly specifies denied addresses within the address ranges specified by the "allow" table.

    o If there is *not* a table named "allow", use permissive rules: o

      o The "deny" table explicitly specifies all denied addresses.


Gotchas

Because of the way the allow/deny mechanism works, an empty "allow" table means that *no* client address is allowed, and therefore *all* client addresses are denied! In this case, simply delete the Allow table to allow access to any client address not listed in the Deny table.

A given client address can be allowed (or denied) access by IP address (or partial IP address) or by domain name. Depending on how a given CGI script calls the AllowDeny suite, it may be necessary to enter both IP address *and* domain name in the Allow (or Deny) table to make certain that it is in fact allowed (or denied) in all cases. It will be allowed if *either* key (IP address or domain name) is found in the Allow table, and *neither* key is found in the Deny table.

Note that the AllowDeny menu options for Allowing, Denying, and Removing clients and for otherwise manipulating AllowDeny tables currently work only with user.AllowDeny. If you use a different AllowDeny table, you will have to maintain it completely manually.


Primary Scripts in the Suite

ClientIsAllowed( inIPorDN, inAllowDenyTbl )

Call this script to determine if the client address is allowed access according to the specified permissions table.

inIPorDN can be a complete IP address, a partial IP address, or a domain name.

inAllowDenyTbl is optional. If provided, it must be the address of a table containing a subtable named "deny"; it may optionally have a subtable named "allow". If omitted, @user.AllowDeny is used.

AllowClientAddr( inIPorDN, inAllowDenyTbl, inNotifyUser )

Call this script to specifically allow a given client address (IP address or domain name) access.

inIPorDN can be a complete IP address, a partial IP address, or a domain name.

inAllowDenyTable is optional. If provided, it must be the address of a table containing a subtable named "deny"; it may optionally have a subtable named "allow". If omitted, @user.AllowDeny is used.

inNotifyUser indicates to the script whether to notify the user when they have called this routine to allow a client address that is already explicitly allowed, or whether to prompt the user whether to proceed when completion of this routine will result in the creation of an Allow subtable. inNotifyUser defaults to FALSE.

If inNotifyUser is false, the script will simply create the Allow subtable if necessary, and will not report either the creation of the Allow subtable or the attempt to allow a client address that is already allowed.

DenyClientAddr( inIPorDN, inAllowDenyTbl, inNotifyUser )

Call this script to specifically deny a given client address (IP address or domain name) access.

inIPorDN can be a complete IP address, a partial IP address, or a domain name.

inAllowDenyTable is optional. If provided, it must be the address of a table containing a subtable named "deny"; it may optionally have a subtable named "allow". If omitted, @user.AllowDeny is used.

inNotifyUser indicates to the script whether to notify the user when they have called this routine to deny a client address that is already explicitly denied, or whether to prompt the user whether to proceed when completion of this routine will result in the creation of a Deny subtable or in the removal of the Allow subtable. inNotifyUser defaults to FALSE.

If inNotifyUser is false, the script will simply create the Deny subtable if necessary, will delete the Allow subtable if it is empty, and will not report the creation of the Deny subtable, the deletion of the Allow subtable, or the attempt to allow a client address that is already allowed.

RemoveClientAddr( inIPorDN, inAllowDenyTbl, inNotifyUser )

Call this script to remove a given client address (IP address or domain name) from the Allow and Deny tables.

inIPorDN can be a complete IP address, a partial IP address, or a domain name.

inAllowDenyTable is optional. If provided, it must be the address of a table containing a subtable named "deny"; it may optionally have a subtable named "allow". If omitted, @user.AllowDeny is used.

inNotifyUser indicates to the script whether to prompt the user whether to proceed when completion of this routine will result in the removal of the Allow subtable. inNotifyUser defaults to FALSE.

If inNotifyUser is false, the script will simply delete the Allow subtable if it is empty, and will not report the deletion of the Allow subtable.


Release Notes

Spinward Stars
Copyright © 1998, 1999 by Samuel Reynolds. All rights reserved. Last modified 1999/08/03.
Built with Frontier v.6.0 on Macintosh OS 8.1 on 1999/08/19.