Listed below are some typical security implementations in Servoy applications.

Basic Servoy Authentication 

Practical where the security will be managed by the developer of the application and does not require anyone else configuring users or permissions.

...

• Using the User/Group editor, decide what authorization permission groups are required for the application.  Create these groups before development begins.
• During development of tables and forms, use the settings on the security tab of each editor to configure what permissions each group has for the table/form.  Keep in mind during form development that elements must be named in order to assign permissions.
• Set the mustAuthenticate flag to true (selected) for the solution.
• Create users with either the User/Group editor or with the Users page in the application server administration utility.  Assign users to groups in either editor.
• Deploy the application.  When launching the application, the default login window will appear to authenticate the user.

Custom Authentication

To allow tenant administrators or "super users" to adminstrate users, or if you are using an external authentication source, you must create custom authentication.  Custom authentication will allow the developer to use a users table in the database for authentication or access an external authentication directory.

...

Solution onOpen Method

For almost every implementation of security, the solution should have an onOpen method assigned. This event is triggered right after the authentication process is complete. Some of the functions of this method in regards to security include:

• Setting up of tenancy for a multi-tenant solution.  Table filters are enacted at this time to filter the data appropriately for the tenant.
• Applying custom security.  If the security model is custom, these permissions should be set at this time.  This would normally involve reading metadata from the database and applying permissions/restrictions based on the user's group.
• Setting security variables. Normally, in order to better facilitate using information from the users and tenants tables, global variables should be set for the current user id and the current tenant id.  If these variables were not set during the login process, then they should be set here.
• Database switching. If the application is set up as a multi-tenant with a database for each tenant, this is the time to switch to the tenant's database.

Example Login Method

The code below is an example of a typical custom login method. In this scenario, the login page contains the following form variables:

...

function login(){

	errorMessage = null;

	if(!userName){
		errorMessage = 'Please specify a user name';
		return false;
	}
	if(!password){
		errorMessage = 'Please specify a password';
		return false;
	}

	var tenantID = security.authenticate("myAuthenticator","getTenant",[userName]);
	if(tenantID){
		if(security.authenticate("myAuthenticator","loginUser",[userName,password])){
			return true;
		} else {
			errorMessage = "No tenant found. Please check your password";
		}
	}
	errorMessage = 'Login Failed';
}

Example Authentication Method

The code below is an example of a typical authentication method.

...

Note that you have the choice of querying the database or getting an external authentication.  You may also read a user groups table to create the array of groups the user has privileges with. Also not that the only thing that is returned is a true or false and that reporting errors to the user does not occur at the authenticator level.

Fully Custom Security

In a fully custom security implementation, both authentication and authorization information is handled outside of Servoy built in security paradigm.

...