Background.

A browser will make a request of a webserver. If the request is for an STR file, then the webserver will run a translation program, hereinafter called FS2. FS2 will consult a database named DPWEB (through Firestorm) and using information found therein will generate a t-log file for the request. FS2 will then invoke a new version of DataPerfect, hereinafter called DP3, passing it the name of the t-log file on the command line. The t-log file will include "#R:" commands to cause DP3 to run one or more DataPerfect reports. These reports will belong to a particular DataPerfect application, identified by an application code in the requesting URL. The output of these reports may (and typically will) be directed to a file whose name is given in a special parameter in the t-log file. When DP3 has concluded running all application reports, FS2 will direct the contents of the output file back to the webserver. The webserver will then send these contents back to the browser.

Proposed design for secure access.

DPWEB will have a new security panel, holding application id, session id, username, and password. The index will be by application id and session id. It is assumed that username and password will be values taken from the application's userid panel. There will also be a date and timestamp in this panel for session aging purposes.

If a request comes in, which has a session id, and a match is found in the DPWEB security panel, then DP3 will be run with the corresponding username and password. This means that DP3 will run the reports as that particular user of the application.
FS2 will edit the record in the application's userid panel to place the session id in a designated field. If username and password are blank, they would not be included, as this would mean that the application does not require login. If the matching record in the DPWEB security panel is older than a configurable (in the DPWEB application panel) number of seconds, then it will be considered invalid, and this request will be handled as if it had no session id.

In addition, the DPWEB application panel will include a login report number field, which can be set to zero. It will also include a login required field, which can be either left blank or set to non-blank (ex. X). It will also include a session timeout field, which will be significant only if login is required. There are four possible states of the first of these two fields:

A) login required = ' ' and login report = 0
B) login required = ' ' and login report not = 0
C) login required = 'X' and login report = 0
D) login required = 'X' and login report not = 0

In addition, the DPWEB application panel will include a session id parameter name field (whose value shall be referred to hereinafter as SIDPN).

In cases A and B, no login is required. If the session timeout field contains a zero, this is assumed to mean that there is no session tracking. If there is session tracking, then when the t-log file is generated, it will include a parameter whose name is SIDPN and whose value is a newly generated session id. It is expected that the application will then ensure that the session id is included in all requests it makes from that point on. A field will be added to the DPWEB application page panel to indicate that the page to be produced should invalidate the session id. In this case, the record in the DPWEB security panel will be deleted before DP3 is invoked to produce the page. In this way, an application can perform a secure logout.

If a request comes in without a session id, then a new one will be created and a record made of it in the DPWEB security panel, with a blank username and password. DP3 will be run with a particular (login) report (whose number is specified in the DPWEB application panel). If the login report value is zero, then FS2 will create a standard login page which includes all details of the initial request (as well as the new session id, and fields for username and password entry) and send this page back to the browser through the webserver. If the user responds to this page, then FS2 will use the application id and session id to locate the record in the security panel, store therein the username and password, and proceed normally with the initial request. It will be the responsibility of the application to check username and password and return an appropriate response if these are not valid. DP3 provides a built-in function (user.field[x]) to provide access to fields in the userid panel of the application. If these values are empty (or zero, for numerics) that means there was no matching record in the userid panel of the application.

If the login report value is non-zero, FS2 will prepare a request to the specified report, passing into it (via the t-log file) all the parameters of the initial request, including the page id. This will allow the application report to produce a webpage for login which can eventually lead to the initial request being satisfied.

There will be a new field in the DPWEB page panel to indicate whether or not this page is allowed for "initial entry" to the application. The discussion above will hold if the initial request calls for a page marked for initial entry. For other pages, FS2 will simply return an unauthorized response code to the webserver for display in the browser.

Need a sequence of "railroad" diagrams showing the progress of a request through the various processes (browser, webserver, FS2, DP3, and back) in each of the possible circumstances.

Alternatively, a sort of flowchart showing the logic of FS2 could be provided.

Need a specification of URL structure and mapping. For example, the URL might look like:

http://domain/appcode/app.str/pgcode?parm1=val1&...parmk=valk

When the webserver finds the app.str file, it would pass the request off to FS2, giving it the original request URL, the path information (in this case, "/pgcode") and the query string (in this case "?parm1=val1&...parmk=valk". Using this information, FS2 would parse out the application code (in this case "appcode") and page code. It would use these to find the application record in DPWEB panel one and the page description record in DPWEB panel two. These would allow it to generate a t-log file like:

#C:
=BCP=*1"SID"*2"parm1"*3"1"*4"val1"**
...
#C:
=BCP=*1"SID"*2"parmk"*3"k"*4"valk"**
#E:
=UIDP=+1+1"user id"++
*UIDSF"SID"**
#R:
=R1=
...
#R:
=Rj=

Where:

BCP is the number of the Browser Control Panel (DPWEB P1F3)

SID is the session id.

k is the number of parameters in the query string.

UIDP is the panel number of the application userid panel (DPWEB P1F4)

UIDSP is the field number of the session id field in the userid panel (DPWEB P1F5)

R1 through Rj are the report numbers (DPWEB P3F6), in the order they appear in the index.