@ub and @cb issues - an idea

[Bill Akers]

Jay R. Ashworth wrote:
> On Wed, Apr 21, 2004 at 01:09:32PM -0400, GCC Consulting wrote:
> 
>>I wrote a physician's credentialing system which required much more
>>tracking of who did what & when then even the *nix system maintained
>>fields offered. It took a separate file(s) to track the information
>>management wanted as to who did what & when. This included who
>>looked or printed information(when by date & time) and 10 levels of
>>modification tracking (complete "secret" copies of before(when "<U>
>>was pressed & after snapshots of the data). Too much information to
>>just track the change. It took 12 screens to get all of the data.
> 
> 
> Ah, yes; auditing.

I had a package with similar audting, although not quite that extensive. 
         All users logged in under one unix login name to generate the 
ticket. It was to their advantage to properly identify themselves as the 
originator of the ticket for several reasons, including that they would 
be fired if their productivity was too low. The reason that we used one 
login was that a terminal would stay logged in all day and everyone who 
worked there would use any terminal that was available. It was 
absolutely necessary to do this because of the nature of the business. 
No one had an assigned work ststion. It therefore became necessary to 
have user names in a file along with passwords, and to have passworded 
access to the some functions of the system, especially to any areas 
where modifications of a ticket could be made after it was stored. 
Generally only certain trusted employees could modify stored informstion.

> 
> I've often wished for a *clean* way to get "what this field had in it
> before I changed it" in WLF processing -- one, that is, that didn't
> require either a WEF* with a temp dummy that couldn't have the proper
> edit, or a separate routine for each field -- @PV would be nice.  :-)
> 
> 
>>The above system had it's own login file controlling access to the
>>system. One set of files was available to anyone. The other file
>>had permission controls applied even before any data could be seen.
>>This file required a second login to insure that someone other then
>>the person logged in to the computer wasn't trying to access the
>>restricted file.
> 
> 
> I'm curious; assuming this was on Unix, why wasn't checking @ID good
> enough for the security you needed?

Unless you are using controlled terminals that are locked by the user 
when he/she leaves the work area, @id most likely will not work well as 
almost anyone in an office that does the same job could use the terminal 
for a period of time, especially if they happen, for instance, to answer 
the phone at that station and need to look up and maybe modify a 
workorder. But if you use a user/password system for modifications to 
the workorder then you will know who does what, regardless of who is 
logged in at that station, unless the office manager is lack-a-daisical 
about security and hands out user'slogin names and passwords like they 
were M&M's.

> 
> Cheers,
> -- jra



-- 
William Akers
MGM Industries, Inc.
Hendersonville TN USA