Introduction

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 login prompt.

The Client

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.

The Server

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.

What's Coming?

• 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 source.

  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 pretty easy.

• 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 local drives.

This page will be tidied up and expanded as I get time.