Security

[Robert J.M. Edis]

G'day John

I would agree with using a table (or file) to control the security access.
However, I would make the table as part of your record retrieval process in
the screens and reports rather than reading the table and passing the
security code from one process to another.

This way the security is controlled at an earlier stage and less screen I/O
is required.

Have you thought about how you might be able to use the PowerHouse ASCs as
part of the security picture?

Blue 

-----Original Message-----
From: John Pearce
To: powerh-l@lists.swau.edu
Sent: 1/16/00 6:17 PM
Subject: Security

I need to extend security in a group of screens to determine the records
a
user can enter/find based on a location code.  

At this point, it seems the best thing to do is build a dataset with the
user (signonid) and allowed location code.  The main menu would use the
Initialize procedure to do a lookup in this dataset to find the user and
their allowed location code and pass that to the lower level screens.  

The lower level screens would have a PostFind procedure to check the
location code from the record retrieved versus the allowed location code
passed from the main menu.  If the two codes don't match, issue an
ERROR.
For new records, an edit (or input) procedure on the location code would
be
used to check the allowed location code.

Has anyone done something similar in the past and have I missed
anything?
Is it reasonably secure? Are there are other suggestions on how to
implement this style of security?

Thanks for any suggestions or help you can provide.


------------------------------------------------------------------
John Pearce  <jpearce@rmi.net>       | Bethesda Management Company 
Speaking for only myself             | Colorado Springs, CO  USA
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
= =
Subscribe: "subscribe powerh-l" in message body to
majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to
majordomo@lists.swau.edu
This list is closed, thus to post to the list, you must be a subscriber.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
This list is closed, thus to post to the list, you must be a subscriber.