Overview
LoopBack provides useful built-in models for common use cases:
- Application model - contains metadata for a client application that has its own identity and associated configuration with the LoopBack server.
- User model - register and authenticate users of your app locally or against third-party services.
- Access control models - ACL, AccessToken, Scope, Role, and RoleMapping models for controlling access to applications, resources, and methods.
- Email model (see email connector) - send emails to your app users using SMTP or third-party services.
The built-in models (except for Email) extend PersistedModel, so they automatically have a full complement of create, update, and delete (CRUD) operations.
Note:
By default, only the User model is exposed over REST. To expose the other models, change the model’s public property to true in server/model-config.json.
See Exposing models for more information. Use caution: exposing some of these models over public API may be a security risk.
Application model
Use the Application model to manage client applications and organize their users.
The default model definition file is common/models/application.json in the LoopBack repository.
User model
The User model represents users of the application or API. The default model definition file is common/models/user.json in the LoopBack repository.
Important:
If your application requires only a user model with email and password fields, then you can use
the built-in User model for user management. Otherwise, you must create your own custom model (named something other than “User,” for example “Customer” or “Client”) that extends the built-in User model rather than use
the built-in User model directly.
Starting with version 3.3.0, LoopBack supports applications with multiple models based on the User model. (previous versions allowed only one). For more information, see Access control with multiple user models.
For more information, see Managing users.
Access control models
Use access control models to control access to applications, resources, and methods. These models include:
ACL model
An ACL model connects principals to protected resources. The system grants permissions to principals (users or applications, that can be grouped into roles).
- Protected resources: the model data and operations (model/property/method/relation)
- Whether a given client application or user is allowed to access (read, write, or execute) the protected resource.
Creating a new ACL instance.
server/boot/script.js
ACL.create({
principalType: ACL.USER,
principalId: 'u001',
model: 'User',
property: ACL.ALL,
accessType: ACL.ALL,
permission: ACL.ALLOW}, function (err, acl) {
ACL.create({
principalType: ACL.USER,
principalId: 'u001',
model: 'User',
property: ACL.ALL,
accessType: ACL.READ,
permission: ACL.DENY}, function (err, acl) {
}
);
}
);