When the user runs a procedure, you can check the permission for the activity associated with the procedure. Specifically, you:

  • Find the activity record in the permissions table.
  • Compare the permissions for the activity with the user ID (database connection ID or OpenEdge session ID) of the user running the procedure.
  • If there is a match for the user ID, allow access. Otherwise, display a message and exit from the procedure.

The following figure shows what happens when the user with user ID manager runs the i-adcust.p procedure.

Figure 1. User with permission to run a procedure


When the specified user ID and the permission defined in the i-adcust.p record in the permissions table match, the that user can run the procedure. The following figure shows what happens when the user with user ID inventory tries to runs i-adcust.p. Because there is no match, the procedure displays a message and the user cannot run the remaining code.

Figure 2. User without permission to run a procedure


You use the CAN–DO function to do security checking in your procedure. The procedure i-adcus4.p is a modified version of the i-adcust.p procedure that includes activity-based security checking.

i-adcus4.p

/* Security checking */
DO FOR permission:
  FIND permission "p-adcust.p" NO-LOCK.
  IF NOT CAN-DO(can-run) THEN DO:
    MESSAGE "You are not authorized to run this procedure.".
    RETURN.
  END.
END.

/* p-adcust.p */
REPEAT:
  INSERT Customer WITH 2 COLUMNS.
END.

The first part of this procedure makes sure the user's single database connection ID is authorized to run the procedure. The FIND statement reads the permission record for the i-adcust.p procedure. The CAN–DO function compares the value of the can–run field in the record with the database connection ID of the user running the procedure. If the values do not match, the procedure displays a message and exits. If there is a match, the procedure allows the user to add Customer records.

The AVM checks privileges within a DO FOR block to ensure that the record read by the FIND statement is held only during that block, rather than during the entire procedure. In addition, the NO–LOCK option ensures that other users can access or update the permissions table while this procedure is running.

The part of the i-adcust.p procedure that does security checking is standard. For example, you could include the same security checking statements in the procedures i-chcust.p and i-delcus.p, if you change the name of the activity record being read in the permissions table.

i-delcs2.p

/* Security checking */
DO FOR permission:
  FIND permission "p-delcs.p" NO-LOCK.
  IF NOT CAN-DO(can-run) THEN DO:
    MESSAGE "You are not authorized to run this procedure.".
    RETURN.
  END.
END.

/* p-delcs.p */
PROMPT-FOR Customer.CustNum.
FIND Customer USING Customer.CustNum.
DELETE Customer.

The procedure in i-itlst2.p shows how you can modify a print procedure, such as i-itlist.p, and add security checking to it.

i-itlst2.p

/* Security checking */
DO FOR permission:
  FIND permission "print" NO-LOCK.
  IF NOT CAN-DO(can-run) THEN DO:
    MESSAGE "You are not authorized to run this procedure.".
    RETURN.
  END.
END.

/* p-itlst2.p */
FOR EACH Customer NO-LOCK WHERE Customer.CreditLimit > 50000 
  BY Customer.PostalCode:
  DISPLAY Customer.Name Customer.Address Customer.City Customer.State
    Customer.PostalCode Customer.CreditLimit
    WITH SIDE-LABELS.
  FOR EACH Order OF Customer NO-LOCK:
    DISPLAY Order WITH SIDE-LABELS.
    FOR EACH OrderLine OF Order NO-LOCK, Item OF OrderLine NO-LOCK:
      DISPLAY OrderLine.LineNum Item.ItemNum Item.ItemName
        OrderLine.Qty OrderLine.Price WITH SIDE-LABELS.
    END.
  END.
END.

Here, the FIND statement reads the print record from the permissions table. The CAN–DO function compares the value of the can–run field with the database connection ID of the user running the procedure. If there is no match, the procedure displays a message and exits. If there is a match, the procedure displays order information.

Remember, there is no separate record in the permissions table for the i-itlst2.p procedure. However, you can use the record for the "print" activity to handle security for any procedure that you specify as a print activity. You can include the same security checking statements in any other procedure that you consider to be a print activity, such as i-rept6.p.

i-rept6.p

OUTPUT TO mail.lst.
FOR EACH Customer NO-LOCK
  WHERE Customer.Balance >= 1400 BY Customer.PostalCode:
  PUT Customer.Contact SKIP
      Customer.Name SKIP 
      Customer.Address SKIP.
  IF Customer.Address2 NE "" THEN 
    PUT Customer.Address2 SKIP.
  PUT Customer.City + ", " + Customer.State + "  " +
    STRING(Customer.PostalCode," 99999") FORMAT "X(23)" SKIP(1).
  IF Customer.Address2 EQ "" THEN PUT SKIP(1).
END.

For application maintenance purposes, you might want to put security checking statements into an include file. Procedures that require security checking can simply include that file, passing the activity as an argument. An example of a such an include file is i-chkprm.i.

i-chkprm.i

DO for permissions:
  FIND permissions {1} NO-LOCK.
  IF NOT CAN-DO (can-run) THEN DO:
    MESSAGE "You are not authorized to run this procedure".
    RETURN.
  END.
END.