Release 10.1A: OpenEdge Development:
Programming Interfaces

> ## Authorizing users from within a given procedure

> This sections shows some examples of procedures that you can use to check for user IDs in order to run the given procedure. The following procedure uses `_prostar.p`:

> i-csmnu3.p
>     DEFINE VARIABLE selection AS INTEGER FORMAT "9".
>     RUN _prostar.p.
>     REPEAT:
>       FORM  SKIP(2)    "    M A I N M E N U"
>           SKIP(1)    "  1)  Add a new customer"
>           SkIP(1)    "  2)  Change customer Information"
>           SkIP(1)    "  3)  Display orders"
>           SKIP(1)    "  4)  Create mailing labels"
>           SKIP(1)    "  5)  Delete a customer"
>           SKIP(1)    "  6)  EXIT"
>       WITH CENTERED TITLE "Maintenance and Reporting".
>       UPDATE SKIP(2) SPACE(1) selection AUTO-RETURN
>           WITH SIDE LABELS.
>     HIDE.
>           IF selection EQ 1 THEN RUN i-adcust.p.
>       ELSE IF selection EQ 2 THEN RUN i-chcust.p.
>       ELSE IF selection EQ 3 THEN RUN i-itlist.p.
>       ELSE IF selection EQ 4 THEN RUN i-rept6.p.
>       ELSE IF selection EQ 5 THEN RUN i-delcus.p.
>       ELSE IF selection EQ 6 THEN QUIT.
>       ELSE MESSAGE "Incorrect selection - please try again".
>     END.

> This procedure defines user access by first running the `_prostar.p` procedure before displaying the following main menu in a character environment:

> Suppose you want to define, on a per procedure basis, the individuals who can run each of the Maintenance and Reporting menu procedures. You can use the `CAN–DO` function to check the user ID(s) established by `_prostar.p`. The `i-adcust.p` procedure allows you to enter customer information:

> i-adcust.p
>     REPEAT:
>       INSERT customer WITH 2 COLUMNS.
>     END.

> If you want to limit the use of this procedure to database connection that have a database connection ID of `manager` or `salesrep`, you can modify the procedure as follows to authorize access based on the database connection ID for single connected database:

> i-adcus2.p

> The first part of `i-adcus2.p` authorizes the user to run the procedure. The `CAN–DO` function compares the values listed in the parentheses against the database connection ID for a single connected database. If the database connection ID does not match any of the values listed, the procedure displays a message and exits. If the database connection ID does match one of the values (listed user IDs), the procedure continues executing.

> The ID list you provide in the `CAN–DO` function is a comma-separated list of user ID tokens. You can use tokens to indicate specific users who have or do not have access. Table 2–10 lists the types of tokens you can specify.

> Table 2–10: Values to use for ID lists
> Value | Meaning
> --- | ---
> * | All users are allowed access.
> user | This user has access.
> !`user` | This user does not have access.
> `string`* | Users whose IDs begin with “`string`” have access.
> !`string`* | Users whose IDs begin with “`string`” do not have access.

> For more information on the `CAN–DO` function, see the OpenEdge Development: Progress 4GL Reference .

> You can also use the `USERID` function (with a specified or single database connection) to check user IDs in a procedure. Use this function when you want to allow only one user ID access to a procedure:

> i-adcus3.p

> If the user ID of the user running the procedure is not `manager`, the procedure displays a message and exits. If the user ID is `manager`, the procedure continues.

> If you use either the `CAN–DO` function or the `USERID` function to compare the specified database connection ID with one or more user IDs you hard-code in a procedure, you must modify and recompile that procedure whenever you change the user IDs allowed access to it. You can avoid having to make these changes by building a permissions table for activities in your application. For more information, see the "Defining activities-based user authorization" section.

> Also, given a single string of user IDs, the `CAN-DO` function, by default, validates the single `USERID` (database connection ID) value for a single database connection. If you connect to more than one database, a `USERID` function requires a specified logical database name and a `CAN–DO` function requires a second argument consisting of an explicit `USERID` function with a specified logical database name. For more information on multiple-database considerations, see OpenEdge Development: Progress 4GL Handbook .

> Note: The second argument of the `CAN-DO` function can also consist of a string expression that specifies an authenticated user ID other than the database connection ID. For example, you can specify the `USER-ID` attribute of a client-principal object validated against the application trusted domain registry to specify the Progress session ID. In this way, you can use the `CAN-DO` function to authorize procedure access independent of any database connection. For more information, see the "Authenticating user identities" section. You can also use the list of user roles set for the `ROLES` attribute on the client-principal object to identify user permissions for the `CAN-DO` function, for example: `IF CAN-DO(hCP:ROLES, "Admin") THEN ...`

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095