Difference: 0LASubrUtilCheckRbs (1 vs. 4)

Revision 42020-05-12 - JeanNeron

Line: 1 to 1
 
META TOPICPARENT name="FullAPIList"

.UTIL CHECK RBS

Line: 74 to 74
 
<--/commentPlugin-->

-- JeanNeron - 2012-10-30 \ No newline at end of file

Added:
>
>
META TOPICMOVED by="JeanNeron" date="1589314416" from="Main.0LASubrUtilCheckRBS" to="Main.0LASubrUtilCheckRbs"

Revision 32016-09-09 - JeanNeron

Line: 1 to 1
 
META TOPICPARENT name="FullAPIList"

.UTIL CHECK RBS

Line: 60 to 60
 
  • SECCHK FI ACC OK - Y or N indicating if the user has access to the file or not
For Fields:
  • SECCHK FLD AP ID - The Application Id of the file to be checked
Added:
>
>
  • SECCHK FLD FI NAM - The File containing the field to check
 
  • SECCHK FLD NAM - The field name to be checked. Note that GROUP HEADER/TRAILERS and SYNONYMS do not have security, and will return the system defaults.
Returns
  • SECCHK FLD VIEW OK - Y or N indicating if the user is allowed to view the contents of the field or not

Revision 22016-02-25 - JeanNeron

Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="APPX520Features"
>
>
META TOPICPARENT name="FullAPIList"
 

.UTIL CHECK RBS

Changed:
<
<
This subroutine is called to check the security access for the specified user when Role Based Security is used.
>
>
This subroutine is called to check the security access for the specified user when Role Based Security is used. Added in 5.2.0
 

Usage:

Line: 21 to 21
 
Different fields are required and returned in --- SECCHK, depending on whether you are checking Process or File/Field security. The common fields are:
Changed:
<
<
>
>
 
  • SECCHK SECUSER RID
Changed:
<
<
This is the Record Id (RID) of the specific user/role to be checked. In RBS, a user may have more than one Role and you need to indicate which Role you want checked. To determine which RID to use, read 0SA SECUSER by user id (possibly in a BEG READ/END READ loop), and GOSUB 0SA R/S – LOAD HIERARCHY for each record. You can then check SECDB DATABASE ID and / or SECDEPT DESC and/or SECWG DESC and /or SECROLE DESC to see if this is the DB/Dept/Workgroup/Role you are interested in. If so, use SECUSER RID, otherwise read next SECUSER
>
>
This is the Record Id (RID) of the specific user/role to be checked. In RBS, a user may have more than one Role and you need to indicate which Role you want checked. To determine which RID to use, read 0SA SECUSER by user id (possibly in a BEG READ/END READ loop), and GOSUB 0SA R/S – LOAD HIERARCHY for each record. You can then check SECDB DATABASE ID and / or SECDEPT DESC and/or SECWG DESC and /or SECROLE DESC to see if this is the DB/Dept/Workgroup/Role you are interested in. If so, use SECUSER RID, otherwise read next SECUSER
 
  • SECCHK DB ID - The 3 character database id to be checked
  • SECCHK ACL CONTEXT - The context to be checked, PROCESS, FILE or FIELD
  • SECCHK SOURCE (Required if SECCHK ACL CONTEXT = PROCESS)
Line: 37 to 37
 

For Processes:

Changed:
<
<
>
>
 
  • SECCHK PRNT AP ID - The Application Id of the Parent Process
  • SECCHK PRNT TYPE - The Process Type of the Parent Process
Line: 45 to 45
 
  • SECCHK PROC AP ID - The Application Id of the Child Process
  • SECCHK PROC TYPE - The Process Type of the Child Process
  • SECCHK PROC NAM - The Process Name of the Child Process
Changed:
<
<
Returns a Y, N or Blank in the following fields:
>
>
Returns a Y, N or Blank in the following fields:
 
  • SECCHK PROC RUN OK - Indicates if the user can run the process.
  • SECCHK PROC ADD OK - Indicates if the user can add records to the PCF file.
  • SECCHK PROC DEL OK - Indicates if the user can delete records in the PCF file.
  • SECCHK PROC CHG OK - Indicates if the user can change records in the PCF file.
Changed:
<
<
If a blank is returned, it means the flag will be inherited from some parent process at runtime.
>
>
If a blank is returned, it means the flag will be inherited from some parent process at runtime.
 
Changed:
<
<
For Files:
>
>
For Files:
 
  • SECCHK FLD AP ID - The Application Id of the file to be checked.
  • SECCHK FLD FI NAM - The File name to be checked.
Changed:
<
<
Returns:
>
>
Returns:
 
  • SECCHK FI ACC OK - Y or N indicating if the user has access to the file or not
Changed:
<
<
For Fields:
>
>
For Fields:
 
  • SECCHK FLD AP ID - The Application Id of the file to be checked
  • SECCHK FLD NAM - The field name to be checked. Note that GROUP HEADER/TRAILERS and SYNONYMS do not have security, and will return the system defaults.
Changed:
<
<
Returns
>
>
Returns
 
  • SECCHK FLD VIEW OK - Y or N indicating if the user is allowed to view the contents of the field or not
  • SECCHK FLD EDIT OK - Y or N indicating if the user is allowed to change the contents of the field or not

Revision 12012-10-30 - JeanNeron

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="APPX520Features"

.UTIL CHECK RBS

This subroutine is called to check the security access for the specified user when Role Based Security is used.


Usage:

      PASS     --- SECCHK RECORD              FIELD            SHARE? Y
      GOSUB    --- .UTIL CHECK RBS
      *        Check for errors
      IF       --- .UTIL CHECK RBS            NE

Description:

This subroutine is called to check the security access for the specified user when Role Based Security (RBS) is used. If you are not using Role Based Security, use .UTIL CHECK SECURITY instead.

The --- SECCHK RECORD is a required parameter, if it is missing the subroutine will CANCEL.

Using this subroutine, you can check to see if a specific user is allowed to run a specific process from a specific parent, or if the specific user has access to a record or field in a file.

Different fields are required and returned in --- SECCHK, depending on whether you are checking Process or File/Field security. The common fields are:

  • SECCHK SECUSER RID
This is the Record Id (RID) of the specific user/role to be checked. In RBS, a user may have more than one Role and you need to indicate which Role you want checked. To determine which RID to use, read 0SA SECUSER by user id (possibly in a BEG READ/END READ loop), and GOSUB 0SA R/S – LOAD HIERARCHY for each record. You can then check SECDB DATABASE ID and / or SECDEPT DESC and/or SECWG DESC and /or SECROLE DESC to see if this is the DB/Dept/Workgroup/Role you are interested in. If so, use SECUSER RID, otherwise read next SECUSER
  • SECCHK DB ID - The 3 character database id to be checked
  • SECCHK ACL CONTEXT - The context to be checked, PROCESS, FILE or FIELD
  • SECCHK SOURCE (Required if SECCHK ACL CONTEXT = PROCESS)
    • One of:
    • APP START to check processes started from the Database record, ie, the Live Operations menu of the startup application.
    • USER START to check processes started from 0SA USER startup or the command line.
    • SYSPARM to check Direct Process 1
    • DEF INP to check processes invoked as Default Inputs from SCAN
    • OPT CHILD to check optional children

For Processes:

  • SECCHK PRNT AP ID - The Application Id of the Parent Process
  • SECCHK PRNT TYPE - The Process Type of the Parent Process
  • SECCHK PRNT NAM - The name of the Parent Process. Not Required if SECCHK SOURCE is not OPT CHILD
  • SECCHK PROC AP ID - The Application Id of the Child Process
  • SECCHK PROC TYPE - The Process Type of the Child Process
  • SECCHK PROC NAM - The Process Name of the Child Process
Returns a Y, N or Blank in the following fields:
  • SECCHK PROC RUN OK - Indicates if the user can run the process.
  • SECCHK PROC ADD OK - Indicates if the user can add records to the PCF file.
  • SECCHK PROC DEL OK - Indicates if the user can delete records in the PCF file.
  • SECCHK PROC CHG OK - Indicates if the user can change records in the PCF file.
If a blank is returned, it means the flag will be inherited from some parent process at runtime.

For Files:

  • SECCHK FLD AP ID - The Application Id of the file to be checked.
  • SECCHK FLD FI NAM - The File name to be checked.
Returns:
  • SECCHK FI ACC OK - Y or N indicating if the user has access to the file or not
For Fields:
  • SECCHK FLD AP ID - The Application Id of the file to be checked
  • SECCHK FLD NAM - The field name to be checked. Note that GROUP HEADER/TRAILERS and SYNONYMS do not have security, and will return the system defaults.
Returns
  • SECCHK FLD VIEW OK - Y or N indicating if the user is allowed to view the contents of the field or not
  • SECCHK FLD EDIT OK - Y or N indicating if the user is allowed to change the contents of the field or not

Comments:

Read what other users have said about this page or add your own comments.


<--/commentPlugin-->

-- JeanNeron - 2012-10-30

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback