Component Level Permissions

JBStrap has two levels of data accessibility. Public contents are visible to everyone, even to users who are not logged in. Private contents, however, are only visible to users with specific access rights. There are two ways to make component-level permissions work in JBStrap: you can use annotations or control access rights programmatically. Objects without annotations are private objects.

Annotations

For determining permissions, the JBStrap framework provides two annotations. These can be placed on any component.

The Public annotation serves to mark pages public. This annotation has no parameters. Pages that are public are visible to everyone, even to user who have not logged in.

Public page, that anyone can see:

The Private annotation is used to mark components or pages, that require the user to sign in. If you do not specify any parameters, every logged in user will be able to view the page or component.

If you want to limit the page or component to specific users, you must specify these user roles in the parameters of the Private annotation. The first parameter is allowed , where you need to list the roles that can access the content. The second parameter is denied , which is where you need to list the roles that cannot access the content. Multiple roles can be specified in either parameter, and the “*” character can be used as a wildcard.

Annotating a page, so that only users with the ADMIN role can access it:

Note that among the parameters, the denied parameter is considered stronger. If a role is listed in both parameters, the role will not be able to access the content. You could use this, to give every role access that starts with an ‘A’, but block out specific users, that also have the same ‘A’ starting character.

A page that is visible to every role that starts with an ‘A’, but is not accessible to the ADMIN role:

Implementing access control programmatically

You can also control access rights through code. Every access method is available on every component. Their use is similar to the use of the annotations. These methods are:

  • addAllowedRole() : You can add the allowed roles here. These roles will be considered allowed. You can use the ‘*’ character as a wildcard.
  • removeAllowedRole() : You can remove previously allowed roles with this method.
  • addDeniedRole() : You can add denied roles here. These roles will not be able to access the component. You can use the ‘*’ character as a wildcard.
  • removeDeniedRole() : You can remove previously denied roles with this method.

Please note that permissions granted through annotations take precedent over those, that were specified through code. As such, please consider the following:

  • If a role was allowed through an annotation, you cannot remove this permission through code.
  • If a role was denied through an annotation, you cannot remove this block through code.
  • If a role is allowed through an annotation, but you add it to the denied roles through code, then the role will not have access to the component. This deny can be removed later by the code.
  • If the role is considered denied through an annotation, you cannot set it to allowed through code. It will remain denied.
  • If a role is both allowed and denied through code, the role won’t have access to the component, as denies take precedent.
Allowing the ADMIN role, on a button, through code:
Denying the ADMIN role, on a button, through code:
Removing the previously allowed ADMIN role from the button:

Access right inheritance

Access rights are inherited in the framework. This means that a page will inherit the permissions of the UI, on which it is displayed. When placing a component on a page, or into another component, it will inherit that page or parent component’s permissions. These inherited permissions can be narrowed down, but they cannot be widened. Likewise, components inherit these access rights from the page, or their parent component. For example, if you place a Button on a Private page, and you do not specify it otherwise, the button will also have the same access rights as the page.

Inherited access rights can be modified, they can be narrowed down, but they cannot be widened. Meaning that if the ADMIN role is not allowed on the page, and there is a button on the page, the ADMIN role cannot access that button either, and you cannot allow it through code. However, if the ADMIN role is allowed on the page, it can access the button as well, but you can block the ADMIN role from the button.

If a component is removed from the parent component, and is placed on a different component, the child component will inherit the access rights from the new parent component, ignoring the original parent’s access rights. Access rights defined through annotations or code are carried over and are applied together with the newly inherited access rights from the parent component.

Permissions in the DataDescriptors

These access rights can apply to DataDescriptor s as well, not just to pages and components. For a more detailed description, please refer to the DataDescriptor Solution page.

You can set what roles are required to execute operations through the DataDescriptor . You can also specify which roles can read, and which roles can write (modify) data through the DataDescriptor .

Related pages