Application model properties
The application model represents the metadata for a client application that has its own identity and associated configuration with the LoopBack server.
Basic properties
Each application has the basic properties described in the following table.
Property | Type | Required? | Description |
---|---|---|---|
id | String | Automatically generated ID | |
name | String | Yes | Name of the application |
description | String | No | Description of the application |
icon | String | URL of the icon | |
status | String | Status of the application, such as production/sandbox/disabled | |
created | Date | Timestamp of the record being created | |
modified | Date | Timestamp of the record being modified | |
owner | String | User ID of the developer who registers the application | |
collaborators | [String] | Array of user IDs who have permissions to work on this application. NOTE: Currently this property does not do anything; the feature is not yet implemented. |
Authorization properties
The following table describes application oAuth 2.0 settings.
Property | Type | Description |
---|---|---|
url | String | The application URL |
callbackUrls | [String] | An array of pre-registered callback URLs for oAuth 2.0 |
permissions | Array of oAuth 2.0 scopes that can be requested by the application |
Security properties
The following keys are automatically generated by the application creation process. They can be reset upon request.
Property | Type | Description |
---|---|---|
clientKey | Secret for mobile clients | |
javaScriptKey | Secret for JavaScript clients | |
restApiKey | Secret for REST APIs | |
windowsKey | Secret for Windows applications | |
masterKey | Secret for REST APIS. It bypasses model level permissions |
Push notification properties
The application can be configured to support multiple methods of push notifications. All push properties are defined within the "pushSettings" key. Within this:
apns
key contains properties for Apple Push Notification Service for iOS devicesgcm
key contains properties for Google Cloud Messaging for Android devices.
Properties for apns:
Property | Type | Description |
---|---|---|
certData | ||
keyData | ||
production | Boolean | |
pushOptions | Object |
|
feedbackOptions | Object |
|
Properties for gcm:
Property | Type | Description |
---|---|---|
serverApiKey |
For example, from the loopback-push-notification-example application:
$scope.create = function () { $http.post('/api/applications', { name: $scope.name, description: $scope.description, pushSettings: { apns: { certData: $scope.certData, keyData: $scope.keyData }, gcm: { serverApiKey: $scope.gcmKey } } }) .success(function (data, status, headers) { // console.log(data, status); $scope.id = 'Application Id: ' + data.id; $scope.restApiKey = 'Application Key: ' + data.restApiKey; }); };
Authentication scheme properties
Property | Type | Description |
---|---|---|
authenticationEnabled | ||
anonymousAllowed | ||
authenticationSchemes | ||
scheme | String | Name of the authentication scheme, such as local, facebook, google, twitter, linkedin, github |
credential | Scheme-specific credentials |
ACL model
Properties
The following table describes the properties of the ACL object:
Property | Type | Description |
---|---|---|
model | String | Name of the model |
property | String | name of the property, method, scope, or relation |
accessType | String | Type of access: READ, WRITE, or EXECUTE |
permission | String | Type of permission: ALLOW, or DENY |
principalType | String | Type of principal, for example application, user, role |
principalId | String |
Role model
The following table describes the properties of the role model:
Property | Type | Description |
---|---|---|
id | String | Role ID |
name | String | Role name |
description | String | Description of the role |
created | Date | Timestamp of creation date |
modified | Date | Timestamp of modification date |
LoopBack defines some special roles:
Identifier | Name | Description |
---|---|---|
Role.OWNER | $owner | Owner of the object |
Role.RELATED | $related | Any user with a relationship to the object |
Role.AUTHENTICATED | $authenticated | Authenticated user |
Role.UNAUTHENTICATED | $unauthenticated | Unauthenticated user |
Role.EVERYONE | $everyone | Everyone |
Scope model
Is this correct? How can we get these into the JSDocs, assuming we should?
The following table describes the properties of the Scope model:
Property | Type | Description |
---|---|---|
name | String | Scope name; required |
description | String | Description of the scope |
RoleMapping
A RoleMapping entry maps one or more principals to one role. A RoleMapping entry belongs to one role, based on the roleId property.
The following table describes the properties of the roleMapping model:
Property | Type | Description |
---|---|---|
id | String | ID |
roleId | String | Role ID |
principalType | String | Principal type, such as user, application, or role |
principalId | String | Principal ID |