Table of Contents
If you remove all eyecandy created by more or less sophisticated user interfaces you will discover the driving force behind [fleXive]: the core layer. It is implemented at the EJB layer and is provided by stateless session beans. These “engines” serve as abstractions to concrete implementations (usually using some form of singleton pattern) for different databases or algorithms used.
The areas covered are structure definition, content manipulation, SQL like queries, organizing contents in trees, scripting, workflow, user management and how security is handled.
Handling users and user information is a basic business of virtually every major software system in use today. At this juncture [fleXive] is no exception. User management in [fleXive] is based on accounts – that is a user and its basic information (name, login name, contact data, e-mail addresss, ...) are stored in accounts.
In the table below you see the listing of all attributes an account in [fleXive] owns.
Attribute | Description |
---|---|
id, name, login name, e-mail, description, contactDataId | Some basic attributes. The Id uniquely identifies the account. The description allows you to characterize the account while the contactDataId identifies the contact data (e.g. postal address, telephon number) linked to this user. Name and login name stand for themselves. |
mandatorId | The mandator the account belongs to. Note that every account has to be assigned to exactly one mandator. |
language | Identifies the preferred language for the account. Whenever there are available user interface translations or contents in several languages the system will select to display the ones in the language specified here, if available. |
active | An account can be set to status inactive. Thus no login is possible while it is not activated again. Note: both flags, active and validated, have to be set to true for the login to work. |
validated | Flags for admins indicating that the user data was audited and is no fake. Setting this flag to false prevents a login for the corresponding account until the flag is set to true. This setting can be used when auto-creating accounts to force validation of the account data. Note: both flags, active and validated, have to be set to true for the log in to work. |
validFrom, validTo | The valid from/to dates may be used to define a time periode in which the user may log in. |
defaultNodeId | The desired start node in the tree for the user. |
allowMultiLogin | True if multiple logins for the account are possible at the same time. |
updateToken | The update token may be used in external API calls modifying this account to improve security. |
There are two system defined accounts:
the guest user. Everyone who is not logged in is treated as GUEST.
the supervisor. This user is in all roles and may operate on all mandators.
These two accounts can not be removed.
In the following we will look at how to create, update and remove accounts.
Creating a user requires special rights. More precisely only callers (i.e. a user) in role ACCOUNT MANAGEMENT may create users, and only for their mandator. An exception is a user in the role GLOBAL_SUPERVISOR who may create users for all mandators. An example of how to create a new user is given next.
Example 6.1. Creating a new user
import com.flexive.shared.EJBLookup; import com.flexive.shared.interfaces.AccountEngine; import com.flexive.shared.security.AccountEdit AccountEngine ae = EJBLookup.getAccountEngine(); AccountEdit accountEdit = new AccountEdit() accountEdit.setEmail("[email protected]") accountEdit.setName("admin") long accountId = ae.create(accountEdit, "password")
Returns the ID of the created account.
After the account creation one can assign the roles the account is in and the groups it belongs to. For a detailed explanation of the meaning and functioning of roles and groups refer to the the section called “Security”.
For assigning a role to an account the following rules apply:
the caller must be in role ACCOUNT MANAGEMENT
the account/user has to belong to the callers mandator
the caller may only assign roles that he is assigned to himself
GROUP_GLOBAL_SUPERVISOR may set the roles for all users in the system.
Assigning a group to an account presumes the following prerequisites:
the caller must be in role ACCOUNT MANAGEMENT
the account/user has to belong to the callers mandator
the caller may only assign groups that also belong to his mandator, plus GROUP_EVERYONE and GROUP_OWNER
GROUP_GLOBAL_SUPERVISOR may set all groups for all users. Note that by default a newly created account is assigned to the group EVERYONE. To get more information about groups go to the the section called “Security”.
[fleXive] provides two methods for updating an account. One is for updating only some personal data of the specified user (name, login name, password, e-mail address, and language). The other one lets you update all attributes of the user. For both methods applies: setting one parameter to null in the method call means keeping its original value (i.e. the value of the corresponding account attribute is not changed).
The following code updates the previously created administrator account (ID 1) by setting its name to “System administrator” and its e-mail address to “[email protected]”.
Example 6.2. Updating a user
import com.flexive.shared.EJBLookup; import com.flexive.shared.interfaces.AccountEngine; AccountEngine ae = EJBLookup.getAccountEngine(); ae.update(1, null, “System administrator”, null, "[email protected]", null);
Note that by setting the parameters password, login name and language to null the original values (“pw123”, “admin”, 1) are preserved.
There are two prerequisites for the caller to remove an account:
the caller must be in role ACCOUNT MANAGEMENT
the account/user has to belong to the callers mandator
GlobalSupervisor may remove users belonging to any mandator. The accounts USER_GUEST and USER_GLOBAL_SUPERVISOR may not be removed in any case.
For removing an account one only needs to know the account ID. Thus removing the previously created and updated administrator account works as follows: