2.7 How to Apply Security

The security model in the JeeWiz 3.9 transform is fairly loose, and is mostly expected to be used to produce variant pages, that is pages which appear to one group of people different to another. It is also possible to restrict edit access to certain data items or block access to pages completely.

To switch security on you need to generate the application with the security property set to "true". This will cause anyone attempting to use the application to be asked to log on. Provided their user has been set up by the application server administrator, the user will then be able to access the application with no further effects unless you have modeled restrictions within the application. Associated with each user name is the list of roles that the user is a member of. To access the application the user would have to be part of the "everyone" role.

Now you can restrict access to parts of the application by using the following properties: rolesAllowed, rolesBlocked, rolesReadonly and hideWhenBlocked.

The first three are comma separated lists of role names. If none of them are set, all users who can log on can access the object. If you want to restrict access, you can set the roles who should be allowed to use the object in the rolesAllowed list. Then any user who is a member of any role in the roleAllowed list will be able to access the object, and anyone else won't.

You can also explicitly block certain roles, by entering them into the rolesBlocked list. Any user in any role that appears in the rolesBlocked list will not be able to access the object, whether or not they appear in the rolesAllowed list. Those in the rolesReadonly are limited to viewing and can't change the object (create, update or delete). Users in roles in this list must also be allowed access via the rolesAllowed settings (either being in a role present in that list or rolesAllowed being empty).

The following elements have role-based security available:

• Entity
• Dataview
• Attribute
• DataviewField
• End
• DataviewEnd
• Page
• BusinessMethod
• Event

These authorization features on an entity are mapped up to the maintenance dataview level, and so only apply to the standard maintenance screens. Similarly, the security lists on an attribute are mapped to the standard maintenance fields and those on an end are mapped to the generated dataview end.

A dataview security role is applied both to the pages backed by the dataview and maintenance session methods. The security on fields and dv-ends are applied to the elements on a page. Blocked fields are hidden rather than not sent at all. Some of the relations, such as multi-dropdown, allow apparent alteration for a read-only state, but then simply block the create/update on submission.

Event security is also applied to pages, with buttons either being greyed out or not being shown at all. Page and event level security only supports roles-allowed and roles-blocked. however there is a hide-when-blocked boolean feature, which can be set to false to allow links such as buttons to still be shown even though they will not fire. It is this situation that causes a greyed-out button.

If you need finer discrimination, the user and roles are available to programmers, who can implement all sorts of security measures.

Copyright © 2001-2006 New Technology / enterprise Ltd.