Security Administration

 

 

 

In Codeless Platform all of your UI logic resides on the server and is never exposed to attackers. Only one communication servlet is open to the outside world, reducing the attack surface to the absolute minimum. The platform performs form data validation on the server, which cannot be accessed with client-side attacks. 

Application security in Codeless Platform is based on security permissions on a form, view or field level. You can protect the visibility or editability of every field of the form. In the same way, you can protect any action that can be performed on form. For  example you can protect saving the form, generating Excel reports or importing data from a yml file.

Security Permissions are grouped in Security Roles. Each User can have multiple Security Roles assigned. 

Security Permission administration is done inside Form Designer where you simply click to configure what you would like to protect and the way you want to protect it.

 

Grouping of permissions is done in the Security Role form, and adding roles to Users can be done either in User form where you can administer roles for each user separately or in User Login Roles form that is a Checker view where you can administer all User and Roles on one screen.

 

Sensitive form fields like password fields can be protected with encryption algorithms. The default encryption library used for this purpose is BCRYPT. 

Security permission

Security permission is permission defined for the form and it’s action can refer to a Form, View or a Field. 

Security action

Security Action represents concrete action for a particular permission: 

 

Code	Description	Form	View	Field
ADD	Add entity
UPDATE	Update entity or property
DELETE	Delete entity or property
VIEW	View form, view or field
COPY	Copy entity
EXPORT	Export collection of entities
IMPORT	Import collection of entities
REPORTS	Show reports on form

 

 

Let’s see some examples:

 

Action	Level	When user does not have permission
VIEW	Form	Form will not be shown in a application menu
UPDATE	Form	Button Update on a Form will be disabled
DELETE	Form	Button Delete on a Form will be disabled
VIEW	View	View will not be visible
VIEW	Field	Field will not be visible
UPDATE	Field	Field will be disabled

 

Note that when we define permission on a Form level it will be applied to this form and all other forms where the form appears as a child. 

Note that when “VIEW” permission is defined for a field, this field will not be visible on Detail, Grid and Gallery view.

Example:

Form “Visit” can exist independently or as a child form of the “Pet” form. If we create “VIEW Visit” permission and a User does not have this permission, then the following will happen: 

• User will not have “Visit” in an application menu

• User will not see the “Visits” child on the “Pet” form 
  
  

Security Roles

Security permissions are grouped in groups called SecurityRoles.
Each user can have one or more security roles.

 

Creating Security Permissions
 

Security permissions are managed in Form Designer.

When we open Form Designer, and select some form like “Vet”, in the main toolbar we will have a button “Permission”: 

 If we click on this button we will see the following options: 

 

All actions in the previous image are referred to a Form level. Let’s select “View” and “Delete” actions: 

 

Note that the color of the “Permission” button is changed to green because we have at least one permission defined for this form.

From the previous image we defined the following permissions:

• Permission to View “Vet” form

• Permission to Delete vets on “Vet” form 

Let’s see how this form looks when no permission is defined:

 

 

Note that we have a “Vet” form in the application menu and the “Delete” action is enabled.

As soon as we create permissions described previously, we will have this situation:

 

 Note that we will not have the “Vet” form in the application menu.

 Let's go back and delete permission to view “Vet” form:

 

If we go back and try again, we will see that “Vet” is again in the menu: 

 

 

Note however that the “Delete” option is disabled.

Let’s go back to permission options again and click on “View-level security…”

A new window will open with all views in this form except the “Main” view. The “Main” view is not on the list because you can handle the visibility of the “Main” view on the form level.

 

 

If we select “Main_col_1” this means that this view will not show on this form if a user does not have this permission: 

 

Note that the name and description of a vet are not visible because view “Main_col_1” is protected.

Let’s do the same for the “VetsSpecialties” view as well:

 

 

Note that If the view is protected with “VIEW” permission and it’s in the same time base view for a Tab, Accordion or Responsive, then the panel (tab sheet, accordion panel) will not be shown at all. 

Let’s demonstrate this on the following form:

 

 

Note that on the “First” tab sheet we have the “Visits” view: 

 

 Without permission form looks like this: 

 

If we select “Visits” in permission list for action “View”: 

 

The result will be:  

 

 

Note that the “First” tab is missing.

 

Adding roles
 

Security role form is used to group security permissions. Creating a new role is as simple as specifying name, description and selecting permissions from a list of all permissions.

 

 

When we click the “Add” button on the “Permissions” child form we get a checker window to select permissions: 

 

 

Assigning roles to a User

Assigning security roles to a particular user can be done in the User login form:

 

 

Click on the “Roles” button in the toolbar:

  

 

You can “Delete” selected role or “Add” new roles:

 

 

 

Assigning roles to users

   

To administrate all users and roles on a single screen we can use form User login roles: 

 

Start typing the name of a user or click on the “Find” icon:

 

  

Click on the “Update” button and then on any checkbox that will associate the user with the security role. When you save the changes all UserLoginRoles will be updated (created or deleted)