FLFSS Source Code Listings

Below, you may select any map or table you wish to view the filePro source for the activity denoted. All tables are for use "AS-IS", and come with no warranty, express or implied. During development especially, tables may indeed have bugs in them, or may be out of date, although I'll try to avoid both situations.

This source is made available for public instruction purposes. The project relies on the generic CGI gateway package, OneGate, and will not function without it. This project serves as a demonstration of the ease with which one can build a functioning web-enabled product using CGI methodology inside filePro, using the OneGate product.

All code is copyrighted to Mark Luljak <fairlite@fairlite.com>, but may be used either (1) without credit, if you license OneGate; or (2) with credit if you modify segments for use without OneGate. Credit must include the following notice, conspicously present on all output data in any application using any code derived from mine: "Portions, Copyright 2004, Fairlight Consulting <fairlite@fairlite.com>."

For documentation and information about OneGate, please follow the link above, and/or email me.

Fairlight->

General Package Flow

FLFSS is pretty straightforward in operation. Let's quickly review how it basically works:

As a starting note, all processing tables run under the flfss_control database. In OneGate, a "slot" number is assigned to each currently running OneGate session, beginning with 1 and going upwards to the number given to OneGate for max_session_count. At any given execution, the lowest possible open slot is used. On the filePro side, the flfss_control database itself is populated with 128 records. When OneGate calls rreport, I use "-sr %n" to avoid record locking issues, as the record used in the table corresponds to the slot number OneGate has assigned to its transaction, which by design can never overlap. That said, let's move on to the actual flow.

This would be a good time to talk about session management. Every time you log in, whether it be automatically via cookie, or via manual authentication, you are assigned a session ID. This ID is passed with you from program to program within the suite. No program accessible after the login process will function without a verifiable session ID. Sessions expire after 30 minutes of inactivity. Use of any program will refresh the life of the session to a full 30 minutes of time remaining. Session IDs are unique, and cannot be forged. Nobody can hijack your session from another computer and pretend to be you, as the IP address of the computer attempting to use a session ID is checked against the IP address of the computer it was assigned to. Session ID's are always used, irrespective of whether you utilise cookies to automatically log in. If a session ID expires due to inactivity, users not using cookies will be asked to re-authenticate themselves at the login page, while users using cookies will simply transparently be assigned a new session ID on-the-fly, as if they'd just logged in again. Using sessions, one can be assured at all times that a user is authenticated, know who that user is, and be able to handle any specific behaviours associated with that user. Strict use of sessions ensures that transactions cannot be forged.

That sums up the basic flow and functionality of this package.

Processing Tables

Map Files

OneGate Configuration

As mentioned, this package relies on my OneGate engine to handle the CGI end of things. All you have to do in filePro is perform lookups to the onegate database to obtain your data. Configuration of OneGate is minimal for this package. Please note the simplicity of the following files:

In addition, there are several one-line configuration files in the temporary directory for each program in OneGate's spool. You will see them referenced throughout the code. These files are each one line long, and are meant to provide configurability without hardwiring values into the processing table code. These files are:

It should be noted that symbolic links work perfectly for keeping configuration files in sync throughout a project's many program sets. I keep one master copy of the config, environment, and cookies files in one program set's configuration directory, and symlink to them in *nix for all the other program sets. Likewise, I have one temporary directory populated with the real one-line configuration files listed above, symlink to them from the other spool temp directories. This way, you can configure your entire suite by configuring one application. This doesn't hold true for fields and program.set files, as they differ by application. I listed the contents above for each for the sake of clarity, to show that they are indeed needed.

Last Modified: 28-Oct-2006, 04:35:56 EDT