Topincs gives you fine grained control over what users may see and do in your Topincs store. Strict and complex requirements on confidentiality and data integrity can be met with the correct application and combination of the presented mechanisms.
Hint: Read more on user management.
But before we go deeper into this subject, a quick summary on how Topincs organizes its user accounts. Topincs supports any number of users groups and user accounts. Every user account is member of exactly one user group and it may be tied to a domain topic in the store representing the user.
Privileges control which actions a user group may perform with a topic type. In addition you can programmatically decide if a user may access a topic. In total there is four mechanisms for access control:
Hint: Topic access filters can also deny access to a all instances of a topic type.
You can decide which actions a user group may perform for instances of a topic type. The following table list these privileges.
Privilege | Description | Affected components |
---|---|---|
CREATE | Create instances | form, child form (row/data sheet) |
EDIT | Edit instances | form, child form(row/data sheet) |
VIEW | View instances | factsheet, row, data sheet |
DELETE | Delete instances | side menu |
FREEZE | Freeze and unfreeze | side menu |
SEARCH | Search for label | index page, service form |
These rights take effect when the user works with the generic basic components of the web database: form, fact sheet, and index. When similar actions are performed by the same user indirectly via a service using the virtual API of the store, they do not have any affect, e.g. a POST service call that modifies an instance will succeed, even if the user may not EDIT instances of the topic type.
In combination with the shortly introduced readonly user groups, you are able to create an application on the database with minimal access rights. This is in particular helpful to restrict user groups with a very specific or marginal touch point to the system. The basic components play a minor role in these micro applications. All reading and modifying functionality is implemented with services with an occasional form or fact sheet.
By default a user group may create and edit instances of every topic type unless revoked, since all authenticated users are assumed to contribute to the store. By declaring a user group readonly this principle is reverted: members of this group may not create and edit instances unless it is granted. The user group representing the unauthenticated user is always readonly.
In rare circumstances it could be necessary to make a user account completely read only without any option to override. This makes it possible to basically put a user in a user group, but deny him the right to perform any changes whatsoever. All other configurations are overridden by this setting. Simply edit the the user account and set the Read only field to Yes.
Hint: Open Admin menu > User management > User rights > Services to inspect and modify service access rights.
For each service you can decide which user groups should be able to use it. By default a service is available to everyone, even the unauthenticated user, if access is not generally denied with syntactical means. So if you implement a service exposing sensitive information, it is good practice to think first about who is allowed to access it. If a user group may use a service, it may access both:
The form renders topic arguments as a select box, which allows the user to read the label of all instances when choosing from the options. Therefore the user must be able to SEARCH
the topic types in the range of all topic arguments of the service.
Hint: The SEARCH
privilege can be revoked when the application delivers form/product URLs where the argument is already bound. There is no need to search anymore in this case.
By revoking the SEARCH
privilege, a user group can be denied access to the service form, while still being able to access the service product, e.g to generate their mission briefing as a PDF. A sensitive topic argument should therefore be declared to check access. If there is a topic access filter for a user group defined, access to the service will be denied if the user may not access the bound topic.
A topic access filter can be used to deny access to topics based on a relationship between the topic and the user. It is created for a user group in the side menu on its fact sheet. The filter is a piece of PHP code which gets evaluated every time a member of that user group accesses a topic in the factsheet or the form. It can also be enabled for topic arguments of services, where it is disabled by default.
You will need to connect the user account to something in your domain in order to evaluate the relationship to the accessed topic. A standard association type exists for this purpose. Make the topic type whose instances represent users a sub type of user, one of the few predefined topic types.
You can write any domain code in your access filter and test any property and relationship. You can base your access decisions on anything, but the most common use case involves some sort of ownership. You can also deny access to topics purley based on its properties, e.g. when a mission is accomplished, the superheros may no longer access it.
Hint: The parameter $user_id represents the user account.
$topic = Tobject::get($topic_id);
$user = Tobject::get($user_id);
$hero = $user->get_superhero();
// $group = Tobject::get($group_id);
switch ($topic->type()) {
case "mission":
if ($topic->get_superhero() !== $hero) {
Access::deny();
}
if ($topic->get_accomplished() === true) {
Access::deny();
}
break;
// Whitelist some nonsecret topic types
case "superhero":
case "hideout":
case "villain":
case "vehicle":
break;
// Deny access to everything else
default:
Access::deny();
}
A topic type is a collection of constraints: topic occurrence, topic name and topic role constraints. They relate directly to the fields in the form and fact sheet. By default all fields are visible. But the administrator can hide fields for a user group in the form and the fact sheet.
But if a new field is added it is initially visible for all user groups. To circumvent this problem and reliably hide a field from a user group, Topincs takes a whitelisting approach. If a user group should have access to a topic type which carries potentially sensitive information, define a view and make it the default for the user group. A view is simply a list of fields.
By revoking the right to view and edit a field, users in the respective group will neither see it in the fact sheet nor the form. It still may be disclosed in a service where the context of when/where/who can be programmatically evaluated to meet your confidentiality requirements.
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.
Saving …