Developed by the Thompson-Nicola Regional
District Library System, the Public Access Terminal Control project is
intended to provide an Open Source solution to controlling user access to
public computer terminals.
How It Works
The system operates under the premise that there is one specific key application
on the public terminal that the user will run (for example, for a public
Internet terminal, Netscape).
In order to users to access the terminal, they must first authenticate
themselves. This is done with the PATC client. The client takes the user's
information (such as patron ID) and sends it to the PATC server. The PATC
server performs a series of checks: Is the user ID valid? Does the user have
time available for the day? Is the user currently logged onto another
terminal? In any event, the server responds to the client with the appropriate
information for the situation: if the user can't log on, the server sends
a message explaining why, if the user can log on, the server tells
the client how many seconds the user's session may last for.
In the clever diagram above, there's a big green block labelled 'Resource
Control' that stands between the PATC client and the session application.
At the moment, the PATC client isn't capable of controlling all resources
on the computer. For example, you may not want the user to write to the
hard drive. The solution is to use some 3rd party resource control software
(the TNRD Library System uses Bardon Data System's WinU).
The final step in the process if for the PATC client to launch the session
application (in this case, Netscape). When the user voluntarily ends the
session, or exhausts all available time, the session application is closed,
the server is informed that the session ended, and the client returns to the
Click here to download the
client and its source (1.7MB).
The client is coded in Visual Basic 6.0 and makes use of the ActiveX
Internet Transfer control that comes bundled with the Professional edition.
Click here to download the
The server, coded in Perl, must be modified for each installation (since the
method of authenticating users will vary). Information is provided in the
code. Currently, the server runs as a CGI script on a web server.
- nice client configuration - for a Windows application the client is
a nightmare to configure (it currently uses the Unix configuration method:
a text editor and configuration file). I've been working on a menu-based
configuration system for the client. I had initially planned to move
configuration data into the Windows registry but have since reconsidered since
there's a number of things that'll make this quite a programming
inconvenience. I don't know how much I care for the registry anyways...
The menu interface for this is complete... I'm just working on a class to
handle the reading and writing of configuration data.
- modify user inputs without mucking with the source code - at the
TNRDLS, the patron's card number is sufficient to authenticate by, but this
is not going to be the case everywhere. Forcing the administrator to get
into the code of the client in order to make the necessary changes for
the organization is probably a really big inconvenience. While it kind of
falls into the new nice client configuration above, I've done some work
on a way for the user input fields to be created without playing in the
The code for this configuration is all but complete. It now needs to
be incorporated into the client. This will not change the fact that the
server will need to have custom code from location to location.
- 'cracker' control - there needs to be measures against 'sneaky'
users. User input fields should have the ability to have input concealed,
and repeated attempts to log in using invalid information should be
interrupted by the client becoming inactive for a period of time. The intent
of both of these steps is to prevent users from looking over the shoulder of
another user's login, or trying to brute-force the system.
I haven't yet added these features to the client, but they should be
- better session control - the client is reasonably capable of
controlling a user's session, but this control needs to be refined. For
example, if the user has multiple Netscape windows open and goes to a
"forbidden" site, the client will shut down Netscape entirely (instead of
just the offending window -- this is especially bad if the user is
doing serious work and follows an innocent-looking link that leads to one of
those popup window sites). This also includes checking that the methods that
the client uses to control sessions is supported in Windows NT.
- resource management - ultimately, I'd like to see the client
not need the support of a 3rd party application like WinU. The client
should be able to lock down the public terminal well enough to prevent a
user (malicious or otherwise) from tampering with settings or playing with
This page will be tidied up and expanded as I get time.
Last updated: April 18, 2000
Hosting provided by