Re: Programing Question/Authority...

And this is the only way that you can practically manage the problem.

Column/row level object security is only applicable to the most trivial
applications. Trying to manage it with a 1000+ file ERP system would be an
absolute nightmare.


John Taylor


----- Original Message -----
From: "Njal Fisketjon"
>
> The reasons we don't use object authority are:
> - direct object authority lets the user access the data with whatever
> tool he/she has available. With lots of applications created long before
> PF constraints and triggers were are part of the OS/400 database we think
> it's very dangerous to specify direct user authority to files.
> We don't want the user to use ODBC, Client Access, etc to update AS/400
> files at "free will".
>
> - maintaining object authorities requires special care when database
> changes are done.
>
> By combining USRPRF(*OWNER) and application controlled authority per
> program both at user and user group level (user groups defined in our
> "menu system", because multiple groups per user was not available in
> OS/400 at the time we created it), lets the application (system) owner
> grant & revoke authorities. This has eased the workload of the DP staff.
>
> If the system owner grants your "Fred Bloggs" update access to our
Customer
> Update program, he may do all what the program allows him do to.
> No need to know which files (or views) you need access to (and which sort
of
> access).
>


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---