Because client and server are separate processes (and can even be on different machines) with Zim Server Connectivity, there are some new options for providing security, although the same basic mechanisms are used.
Using ZIM Security
Within Zim, security is provided through a combination of log in user names, passwords, and entity set, relationship, and field level permissions. The following is a summary.
- Entity sets and relationships belong to the user who created them. They each have Read, Add, Change, and Delete permissions assigned for the owner, anyone in the same group as the owner, and anyone else. A user must have the necessary permissions to carry out any given operation. For example, an entity set might have Read, Add, Change, and Delete permissions assigned for the owner. The group might have Read, Add, and Change while everyone else might only have Read permission. This means the owner can do anything to this entity set. Members of the group cannot delete records. Anyone else can only read the entity set. For more information, see Object Permissions.
- Individual fields can have either Read or Read/Write permissions for the owner, group, and everyone else. If a user does not have any permissions for a field, then the field appears as $NULL to that user.
- User names are defined in the Object Dictionary in the Users entity set. The PASSWORD command is used to define passwords and the LOGIN command is used to LOGIN as a specific user. When Zim is started, you are automatically logged in as the user ZIM. By default, this user is defined as a “super user” who has universal permissions for everything. However, the definition of this user may be changed (by updating the contents of the Users entity set).
Zim Server uses the same facilities. When a Zim application connects to Zim Server, a Database Agent process is started to service requests from that application. The CONNECT command can contain a user name and password. If it does, a LOGIN is executed at the server. If a LOGIN is executed for a specific user, then all subsequent requests to the server are executed under that user. Thus any permissions that have been set up at the server are obeyed.
Permissions (which are set using the PERMISSIONS command) are set in the server database using a development version of Zim with that database on the server machine. Permissions cannot be set from a client Zim application.
Using Operating System Security Features
You can use operating system features to provide security as well. Many possibilities here exist here, but the following points provide some guidelines. Since the means of specifying operating system level security varies from one operating system to another, actual operating system commands are specified. Consult your system documentation for more details on setting file permissions.
- From an operating system point of view, it is the Database Agent process that accesses the files that make up the server database. The Database Agent process operates as the user that started the Zim Server process (unless either the Zim Server process or the Database Agent process have the “set userid” attribute. See your operating system documentation for details). The user that the Database Agent process operates as is called its effective user id. This means that, if the Database Agent process receives a request to read from part of the database, its effective user id must have the necessary operating system permissions to read from the associated files. Similarly, if a request to update the database is received, the Database Agent process’ effective userid must be able to write to the associated files. In general, ensure that the Database Agent process’ effective user id has read and write capabilities for all database files as well as any directories in which the database exists.
- The Database Agent process is started by the Zim Server process. The Zim Server must have the necessary permissions to execute the Database Agent process. However, the Zim Server process does not access the database directly, so it does not require any permissions with respect to the database.
Given the above, here is one scenario of how security could be provided by using operating system facilities:
- In some cases, it might be desirable to make sure that database files can be accessed only through Zim Integrated Server. This ensures that no one can read or update database files unless they are using the server. Therefore, no one can circumvent the security features that have been implemented in your application or that have been implemented at the server using Zim facilities (see above). To do this, a special system user could be created that
- is used to start the Zim Server process (and becomes the effective user id for the Zim Server and Database Agent processes).
- owns the database directory and all files in it and has read/write permissions for all the files and directories.
- is independent of other users so that no other users are able to access the database
Object Permissions
Entity sets, relationships and fields have security permissions that control how they can be accessed. The permissions defined at the remote database are independent of permissions defined at the client. The following chart illustrates the valid relationships.
- At the server, an entity set, Customers, is defined as well as two users, Bob and Carol. Carl can Read, Add, Change or Delete Customers, but Bob can only Read the entity set. Carol has Read/Write permissions for the Salary Field, while Bob has no permissions for this field.
- Customers is also defined in the Zim application at the client end. Two users are defined at the client, Ted and Alice. Ted has permissions to Read Customers and Alice has permission to Read, Add, Change, or Delete. Ted and Alice have Read/Write permissions for Salary.
Client LOGIN user name | CONNECT user name | Client Operation | Result |
| Ted | Bob | ADD Customers… | Client-side permissions disallow this. |
| Ted | Bob | LIST Customers… | Data is retrieved but Salary appears as $NULL because of server side permissions for Bob. |
| Ted | Carol | ADD Customers… | Client-side permissions disallow this. |
| Ted | Carol | LIST Customers… | All data is retrieved. |
| Alice | Bob | ADD Customers… | Operation fails on the server side because Bob cannot add to Customers. |
| Alice | Bob | LIST Customers… | Data is retrieved but Salary appears as $NULL because of server-side permissions for Bob. |
| Alice | Carol | ADD Customers… | The operation proceeds. |
| Alice | Carol | LIST Customers… | The operation proceeds. |
Read-only fields
Read-only fields are database fields defined by in a table on the database server. The value of a read-only field is always assigned by the server. Such fields are often identity fields or primary keys that serve to uniquely identify a particular row or record in the table. To create a read-only field, set the Required field to the value of RO or ROE. RO and ROE both designate read-only fields. ROE fields are exported by the Export SQL Definitions facility in the Development Center. RO fields are not exported. When a field is defined as read-only, Zim does not generate syntax that assigns a value to this field, even if the language syntax assigns a value or a value is assigned implicitly because a form field name matches the name of the read-only field.
For example, RO is often useful for pseudo-columns that already exist on the server such as “ROWID” in Oracle database tables. If you create a field in a Zim entityset that reside sin an Oracle database with the name ROWID, Oracle always supplies a value for the field. Making it a read-only field in Zim ensures that Zim does not assign a value to it.
English 
Portuguese