Security

[Knox, Dave (Dallas CSC Citrix)]

There's many different ways to approach this. So to add another...

You may also wish to consider SETSYSTEMVAL/GETSYSTEMVAL options.

You can interrogate your security file in main menu initialize proc as
suggested, then set system variable (location_code) accordingly...

That can then be interrogated directly in any subsequent screen without the
need of passing/receiving clauses, and/or adding extra files to your screens
for the sake of one static variable (that's gotta be an oxymoron). 

Also the GETSYSTEMVAL can be used anywhere. Defines, selects, any designer
written procedure, whatever...

In combination with ASC's as Blue mentioned, you have an awful lot of
control.

Regards
Dave


> ----------
> From: 	Robert J.M. Edis[SMTP:robert.edis@creatcomp.com]
> Sent: 	Monday, January 17, 2000 9:28 AM
> To: 	'powerh-l@list.swau.edu'
> Subject: 	RE: Security
> 
> 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.
> 
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
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.