Hi Jeremy, A little over a year ago I transitioned one of my primary project from my 'roll my own' user system to using the 4D system. Primarily I wanted to get out of the password security business as well as take advantage of some of the native 4D security features. All of that gave me reason to learn to work with the commands you cite and I offer all this exposition just to let you know where I'm coming from.
First off, any of the commands can be executed in code as Designer unless the method the command is in is limited. This is what make using BLOB TO USERS and USERS TO BLOB useful. I ship a database with no users except for Designer and Admin. On server startup I look for the blob of stored users and import it to restore the local user scheme. An on server shutdown I export the user blob. Works great. I leave creating users to the Administrator but it can be done programmatically as well in which case you have the option to indicate whether the 4D user is created under the auspices of Designer or Administrator. Obviously you want to use the Admin. That command can be called by any method. So if you want to control user creation you want to protect the method it's called in. This is the case with setting group properties and such. Protect the method that calls those commands. The ones that get those properties aren't so sensitive generally. The thing to remember about creating users and groups with Designer or Admin is : - Designer created users/groups aren't exported to blob and can't be edited or changed by anyone except a Designer. They are permanent parts of the structure. - Admin created users/groups are exported to blob and are dynamic, specific additions to the structure. So anything you always want to be there you make with Designer. Anything that's under end-user purview let them build with Admin. This obviously makes a case for controlling how much of the 4D command language you expose and suggests it would be smart to filter any scripts you allow to run under something like Footrunner. I think I at least touched on your questions in here - hope it helps. BTW - my ultimate user management system uses a combination of the 4D scheme and my internal one. As I said I let 4D manage 'the wall' (to borrow popular American nomenclature) and bind each 4D user to my own internal user. The internal user's record is where fine-grained business logic permissions are handled. Any number of people can have access to the internal record but only the 4D Admin can create 4D users. On Mon, Mar 13, 2017 at 12:21 PM, Jeremy French via 4D_Tech < 4d_tech@lists.4d.com> wrote: > What is meant by "proper access privileges" in Users and Groups? Is there > a definiton somewere? > > 3-commands mention "Designer" and "Administrator", who can execute the > command. Those commands are: > 1) BLOB TO USERS > 2) DELETE Users > 3) USERS TO BLOB > > > But many other commands do not identify who is a privileged user. In the > Error Management section, the documentation simply says these commands > return an error when "you do not have the proper access privileges". > > Who has proper access privileges for the following commands? > • GET GROUP LIST > • GET GROUP PROPERTIES > • GET USER LIST > • GET USER PROPERTIES > • Is user deleted > • Set group properties > • Set user properties > > > QUESTIONS: > 1) What is meant by "proper access privileges"? > 2) Which users have "propert access privileges" when the documentation > doesn't identify the privileged users? > 3) What am I missing here? > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: http://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** -- Kirk Brooks San Francisco, CA ======================= ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************