d9ae32429b
Yesterday, the loopback we are using in our system was upgraded via npm, and since the upgrade, we noticed that every time the user model updates, the emailVerified column would change to false. I took a look and realized there might be an error in https://github.com/strongloop/loopback/commit/eb640d8 The intent of the commit just mention is to make emailVerified false when the email gets changed, but notice that ctx.data.email is null on updates, so the condition is always met and emailVerified always becomes false. This commit fixes the issue just mentioned. |
||
---|---|---|
.. | ||
README.md | ||
access-token.js | ||
access-token.json | ||
acl.js | ||
acl.json | ||
application.js | ||
application.json | ||
change.js | ||
change.json | ||
checkpoint.js | ||
checkpoint.json | ||
email.js | ||
email.json | ||
key-value-model.js | ||
key-value-model.json | ||
role-mapping.js | ||
role-mapping.json | ||
role.js | ||
role.json | ||
scope.js | ||
scope.json | ||
user.js | ||
user.json |
README.md
Application
Application model represents the metadata for a client application that has its own identity and associated configuration with the LoopBack server.
Each application has the following basic properties:
- id: Automatically generated id
- name: Name of the application (required)
- description: Description of the application (optional)
- icon: URL of the icon
- status: Status of the application, such as production/sandbox/disabled
- created: Timestamp of the record being created
- modified: Timestamp of the record being modified
An application has the following properties linking to users:
- owner: The user id of the developer who registers the application
- collaborators: A array of users ids who have permissions to work on this app
oAuth 2.0 settings
- url: The application url
- callbackUrls: An array of preregistered callback urls for oAuth 2.0
- permissions: An array of oAuth 2.0 scopes that can be requested by the application
Security keys
The following keys are automatically generated by the application creation process. They can be reset upon request.
- 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 settings
The application can be configured to support multiple methods of push notifications.
-
pushSettings
pushSettings: { apns: { certData: config.apnsCertData, keyData: config.apnsKeyData, production: false, // Development mode pushOptions: { // Extra options can go here for APN }, feedbackOptions: { batchFeedback: true, interval: 300 } }, gcm: { serverApiKey: config.gcmServerApiKey } }
Authentication schemes
- authenticationEnabled
- anonymousAllowed
- authenticationSchemes
Authentication scheme settings
- scheme: Name of the authentication scheme, such as local, facebook, google, twitter, linkedin, github
- credential: Scheme-specific credentials
APIs for Application model
In addition to the CRUD methods, the Application model also has the following apis:
Register a new application
You can register a new application by providing the owner user id, application name, and other properties in the options object.
Application.register('rfeng', 'MyApp1',
{description: 'My first loopback application'},
function (err, result) {
var app = result;
...
});
Reset keys
You can reset keys for a given application by id.
Application.resetKeys(appId, function (err, result) {
var app = result;
...
});
Authenticate by appId and key
You can authenticate an application by id and one of the keys. If successful, it calls back with the key name in the result argument. Otherwise, the keyName is null.
Application.authenticate(appId, clientKey, function (err, keyName) {
assert.equal(keyName, 'clientKey');
...
});