Login Definition
LoginDefinition
MPO Version: 1.3.0
Defines the core login architecture of the project, including the user and tenant structures that underpin authentication and access. These settings enable Mindbricks to generate a built-in 'auth' service tailored to your data model, supporting user registration, login, permissions, and optional multi-tenant behavior.
interface LoginDefinition = {
userSettings : LoginDefUserSettings;
tenantSettings : LoginDefTenantSettings;
}
| Field | Description |
|---|---|
| userSettings | Defines how the built-in user object is configured and authenticated within the project. While the user data model is fully managed by Mindbricks, this setting allows you to control the primary login identifier (email, mobile, or both), secondary identifier presence, super admin credentials, registration behavior, user group support, and verification requirements. These settings shape how authentication flows and access are handled at the user level. |
| tenantSettings | Configuration for multi-tenant applications, including tenant object definitions and their relationship to users and user groups. When enabled, this isolates resources by tenant and supports tenant-scoped access control. Omit this section for single-tenant projects. |
LoginDefUserSettings
MPO Version: 1.3.0
Defines how users are stored, managed, and authenticated within the project. This includes the primary login identifier configuration (email, mobile, or dual), secondary identifier presence rules, super admin credentials, email and mobile verification settings, public registration policies, and whether user groups are active. This structure governs the behavior and structure of the user service's primary data model.
interface LoginDefUserSettings = {
primaryLoginIdentifier : PrimaryLoginIdentifier;
superAdminIdentifier : String;
superAdminPassword : String;
userNameType : UserNameType;
superAdminData : DataMapItem[];
userGroupsActive : Boolean;
userGroupsInTenantLevel : Boolean;
secondaryIdentifierPresence : SecondaryIdentifierPresence;
dualIdentifierRegistration : DualIdentifierRegistration;
emailVerificationRequiredForLogin : Boolean;
mobileVerificationRequiredForLogin : Boolean;
mobile2FARequiredForLogin : Boolean;
email2FARequiredForLogin : Boolean;
userRegisterIsPublic : Boolean;
userAutoAvatarScript : MScript;
userGroupAutoAvatarScript : MScript;
}
| Field | Description |
|---|---|
| primaryLoginIdentifier | Specifies which field is used as the primary login identifier. When set to 'mobile', users register and log in with a phone number instead of email. When set to 'emailOrMobile', both are supported. Defaults to 'email' for backward compatibility. |
| superAdminIdentifier | The login identifier of the super admin user. When primaryLoginIdentifier is 'email' or 'emailOrMobile', this should be an email address. When it is 'mobile', this should be a mobile number in E.164 format (e.g. +905551234567). If left at the default "admin@admin.com" and primaryLoginIdentifier is 'mobile', Mindbricks automatically replaces it with "+10000000001" during validation. A custom email in a mobile-primary project causes a validation error. This user has full permissions across the project and is not tenant-scoped. |
| superAdminPassword | The password of the super admin user. This preset password is used to access the system after initial deployment and should be changed in production environments. |
| userNameType | Specifies whether the user's name will be stored as a single 'fullname' or as separate 'name' and 'surname' fields. |
| superAdminData | Preset values for the super admin user. Required only for custom properties beyond the standard fields (identifier, name, password, etc.). |
| userGroupsActive | Indicates whether user group functionality is enabled. When active, a 'userGroup' data object is added to the user service with fixed fields (id, name, description), optionally scoped by tenant. |
| userGroupsInTenantLevel | If true, user groups are defined per tenant; otherwise, they are defined globally across the SaaS. Applies only when user groups are enabled. |
| secondaryIdentifierPresence | Controls whether the non-primary identifier field (mobile when email is primary, email when mobile is primary) is stored in the user data model. When set to 'none', the field is omitted entirely. When 'optional', the field exists but is not required. When 'required', the field must be provided during registration. Ignored when primaryLoginIdentifier is 'emailOrMobile' (both always exist). |
| dualIdentifierRegistration | Only applies when primaryLoginIdentifier is 'emailOrMobile'. Controls whether users must provide both email and mobile during registration ('both'), or just one of them ('atLeastOne'). |
| emailVerificationRequiredForLogin | Indicates whether users must verify their email address before they can log in. Related verification flows must be enabled in VerificationServices. |
| mobileVerificationRequiredForLogin | Indicates whether users must verify their mobile number before logging in. This applies only when the mobile field is present in the user data model. |
| mobile2FARequiredForLogin | Indicates whether two-factor authentication via mobile is required during login. This applies only when the mobile field is present in the user data model. |
| email2FARequiredForLogin | Indicates whether two-factor authentication via email is required during login. Related verification flows must be enabled in VerificationServices. |
| userRegisterIsPublic | Determines if users can self-register. If false, only administrators can create users. |
| userAutoAvatarScript | An MScript expression that generates a default avatar for the user. This is used when no avatar is provided in the request. |
| userGroupAutoAvatarScript | An MScript expression that generates a default avatar for the user group. This is used when no avatar is provided in the request. |
PrimaryLoginIdentifier
Specifies which field is used as the primary login identifier for user accounts.
const PrimaryLoginIdentifier = {
email: "email",
mobile: "mobile",
emailOrMobile: "emailOrMobile",
};
| Enum | Description |
|---|---|
| Email is the primary login identifier. Users must register and log in with an email address. This is the default behavior. | |
| mobile | Mobile number is the primary login identifier. Users register and log in with a phone number (WhatsApp-style). Email becomes optional. |
| emailOrMobile | Both email and mobile are supported as login identifiers. Users can register and log in with either an email address or a mobile number. |
SecondaryIdentifierPresence
Controls the presence and requirement level of the non-primary identifier field in the user data model.
const SecondaryIdentifierPresence = {
none: "none",
optional: "optional",
required: "required",
};
| Enum | Description |
|---|---|
| none | The secondary identifier field is not stored in the user data model at all. When email is primary, mobile is omitted. When mobile is primary, email is omitted. |
| optional | The secondary identifier field exists in the user data model but is not required during registration. Users may optionally provide it. |
| required | The secondary identifier field exists in the user data model and must be provided during registration. |
DualIdentifierRegistration
Controls registration behavior when primaryLoginIdentifier is 'emailOrMobile'. Ignored for other values.
const DualIdentifierRegistration = {
atLeastOne: "atLeastOne",
both: "both",
};
| Enum | Description |
|---|---|
| atLeastOne | Users must provide at least one identifier (email or mobile) during registration. They can log in with whichever they provided. |
| both | Users must provide both email and mobile during registration. Both fields are required and both can be used for login. |
UserNameType
Specifies how user names are represented in the data model.
const UserNameType = {
asFullname: "asFullname",
asNamePair: "asNamePair",
};
| Enum | Description |
|---|---|
| asFullname | Stores the user's name in a single 'fullname' field. |
| asNamePair | Stores the user's name in separate 'name' and 'surname' fields. |
LoginDefTenantSettings
MPO Version: 1.3.0
Specifies how tenant-based access control is structured for multi-tenant projects. This includes the tenant object name, registration permissions, and tenant separation logic. When enabled, this enforces strict data and user isolation by tenant.
interface LoginDefTenantSettings = {
useMultiTenantFeature : Boolean;
configuration : LoginDefTenantSettingsConfig;
}
| Field | Description |
|---|---|
| useMultiTenantFeature | Enable this if the project requires multi-tenant architecture. If false, the project will be treated as single-tenant and no tenant-based separation is applied. |
| configuration | The configuration object for tenant settings. Leave it null if useMultiTenantFeature is false. |
LoginDefTenantSettingsConfig
MPO Version: 1.3.0
Configuration details for tenant-based access control, including tenant registration, naming, and avatar script.
interface LoginDefTenantSettingsConfig = {
tenantRegisterIsPublic : Boolean;
tenantName : String;
tenantAutoAvatarScript : MScript;
}
| Field | Description |
|---|---|
| tenantRegisterIsPublic | If true, any user can create a tenant. If false, only SaaS admins can register tenants. When a user creates a tenant, they are automatically assigned as the tenant owner. |
| tenantName | Defines the name of the tenant object in the system (e.g., 'client', 'organization', 'workspace'). This name will be used to generate code, database models, and field references. |
| tenantAutoAvatarScript | An MScript expression that generates a default avatar for the tenant. This is used when no avatar is provided in the request. |
Last updated 2 weeks ago
Built with Documentation.AI