2.38.1 (LTS)

loopback 2.38.1 (LTS)

Improve "filter" arg description

Add an example showing how to serialize object values as JSON.

• Pull request #3219
• Issue strongloop/loopback-component-explorer#94

Fix creation of verification links

Fix User.prototype.verify to call querystring.stringify instead of concatenating query-string components directly.

In particular, this fixes the bug where options.redirect containing a hash fragment like #/home?arg1=value1&arg2=value2 produced incorrect URL, because the redirect value was not correctly encoded.

• Pull request #3195
• Issue #2307

Include link to docs in logoutSessions warning

Make it easy for people encountering the long warning about "logoutSessionsOnSensitiveChanges" to find the relevant information in our documentation.

• Pull request #3193

Preserve sessions on User.save() making no changes

Fix session-invalidation code to correctly recognize the case when User.save() was called but neither password nor email was changed.

Modify the code detecting whether logoutSessionsOnSensitiveChanges is enabled to correctly handle the case when the model is not attached to any application, as is the case with loopback-component-passport tests.

• Pull request #3167
• Issue #3124

Fix logout to handle missing or unknown accessToken

Return 401 when the request does not provide any accessToken argument or the token was not found.

Also simplify the implementation of the logout method to make only a single database call (deleteById) instead of findById + delete.

• Pull request #3158
• Issue #1669

Role model: resolve related models by name

Resolve models related to the Role model by name instead of class instance. This allows to use localRegistry in app without monkeypatching Role manually.

When loading the Role model into a custom registry (e.g. by setting localRegistry to true when instantiating the app object), static roles can not be resolved because the RoleMapping model used inside static methods (e.g. Role.isInRole()) is loaded into a different registry (i.e. loopback) and thus not attached to any dataSource. The patch changed code resolving models related to the Role model to use model name instead of a global model constructor, which leads to them being resolved from the same registry that Role is loaded in as well.

• Pull request #3135
• Issue #2627

Fix User methods to use correct Primary Key

Do not use hard-coded "id" property name, call idName() to get the name of the PK property.

• Pull request #3129

strong-remoting 2.33.0 (LTS)

See https://github.com/strongloop/strong-remoting/releases/tag/v2.33.0

Enable remote methods to be disabled by alias

Fix disableMethodByName method to allow callers to specify one of method aliases instead of the "canonical" name. For example, disable the method removeById by calling disableMethodByName('destroyById').

• Issue #1936
• Pull request strongloop/strong-remoting#395
• Backport of strongloop/strong-remoting#385

Fix content-type reported by the built-in error handler

When a remote method sets a custom content-type (e.g. image/jpeg) and then fails, the content-type is reset back to application/json now, in order to match the body contents.

• Pull request strongloop/strong-remoting#390

Convert object query params to JSON in outgoing requests

When invoking a remote method via strong-remoting, fix the code building query string parameters to correctly handle edge cases like a deeply-nested empty-array value.

Consider the following invocation:

Model.find({where: {id: {inq: []}}})

Before the fix, an empty argument value was sent.

strong-remoting is sending the correct argument value now.

• Issue strongloop/strong-remoting#324
• Pull request strongloop/strong-remoting#381
• Backport of strongloop/strong-remoting#325

loopback-datasource-juggler 2.54.1 (LTS)

See https://github.com/strongloop/loopback-datasource-juggler/releases/tag/v2.54.1

Fix datasource to report connector-loading errors

When resolving full connector path, all errors used to be ignored. As a result, when the connector was installed but not correctly built (e.g. loopback-connector-db2 which uses a native addon), a very confusing message was reported by LoopBack.

We fixed the code handling require() errors to ignore only MODULE_NOT_FOUND errors that contain the name of the required module.

3.0 GA

3.1.1

 * Update package.json for LB3 release (Simon Ho)
 * Invalidate AccessTokens on password change (Miroslav Bajtoš)
 * Fix registration of operation hooks in User model (Miroslav Bajtoš)
 * Remove "options.template" from Email payload (Miroslav Bajtoš)
 * Upgrade eslint config and grunt-eslint to latest (Miroslav Bajtoš)
 * Update paid support URL (siddhipai)
 * Update paid support URL (Siddhi Pai)
 * Remove duplicate warning in issue template (Siddhi Pai)

3.0.0 Release Candidate

This is the first Release Candidate release of the upcoming major version 3.0.

See Release Notes and Migration Guide for more details.

List of notable changes made between 2.x and 3.0 in this repository follows below.

loopback-datasource-juggler was moved from peerDependencies to dependencies

Originally, we (ab)used peer dependencies to ensure there is only one instance
of loopback-datasource-juggler in the dependency tree, so that there is only
one singleton instance of model registry. This was very fragile and might not
have worked in certain edge cases.

We have reworked loopback-datasource-juggler and connectors to not rely on
a single juggler instance anymore. As the last step, juggler became a regular
dependency.

#275

When upgrading application from previous loopback versions, simply remove
loopback-datasource-juggler from your dependencies.

always use bluebird as promise library

In version 3.0, we always use bluebird as our promise library
instead of global.Promise.
We consider Bluebird API as part of LoopBack API from now on,
you are welcome to use any Bluebird-specific methods in your applications.

If you are using LoopBack with a custom promise implementation provided
via global.Promise,
you will have to check all places where you are using non-standard promise API
and update them to use Bluebird API instead.

Please see related code changes.

new method of defining remoting metadata

In 2.0, remote methods were defined as:

methods: {
  staticMethod: {
    isStatic: true,
    http: { path: '/static' }
  },
  instanceMethod: {
    isStatic: false,
    http: { path: '/instance' }
  }
}

For 3.0, the isStatic flag is no longer required and will be determined from the method name.
Method name starting with "prototype." will be the same as having isStatic flag set to false.

methods: {
  staticMethod: {
    http: { path: '/static' }
  },
  'prototype.instanceMethod': {
  http: { path: '/instance' }
}

Please see related code changes.

remove Change.handleError

Change.handleError is now removed as it was used inconsistenly for a subset of possible
errors only. All Change methods will report all errors to the caller via the callback.

Use PersistedModel to report change-tracking errors via the existing method
PersistedModel.handleChangeError. This method can be customized on a per-model basis to
provide different error handling.

Please see related code changes.

remove unused user properties

The following properties are removed from the built-in User model in 3.0:

• credentials
• challenges
• status
• created
• lastUpdated

Developers that are relying on these properties, can redefine them in user.json or equivalent model.json as follow:

{
  "name": "MyUser",
  "base": "User",
  "properties": {
    "credentials": { "type": "object" },
    "challenges": { "type": "object" },
    "status": "string",
    "created": "date",
    "lastUpdated": "date"
  }
}

Please see related code changes.

Remove getters for Express 3.x middleware

Express 4.x stopped bundling commonly-used middleware. To simplify migration
of LoopBack 1.x applications (powered by Express 3.x) to LoopBack 2.x (powered
by Express 4.x), we created getter properties to allow developers to keep using
the old convention.

We have removed these getters in LoopBack 3.0, here is the full list of
removed properties together with the middleware module name to use instead:

• loopback.compress - use require('compression') instead
• loopback.timeout - use require('connect-timeout') instead
• loopback.cookieParser - use require('cookie-parser') instead
• loopback.cookieSession - use require('cookie-session') instead
• loopback.csrf - use require('csurf') instead
• loopback.errorHandler - use require('errorhandler') instead
• loopback.session - use require('express-session') instead
• loopback.methodOverride - use require('method-override') instead
• loopback.logger - use require('morgan') instead
• loopback.responseTime - use require('response-time') instead
• loopback.favicon - use require('serve-favicon') instead
• loopback.directory - use require('serve-index') instead
• loopback.vhost - use require('vhost') instead

We have also removed loopback.mime, which was always set to undefined.

See loopback#2349.

Remove loopback#errorhandler

We have removed loopback#errorhandler middleware, users should use strong-error-handler directly.

// server/middleware.json
{
  // ...
  "final:after": {
    "strong-error-handler": {}
  }
}

// server/middleware.development.json
{
  "final:after": {
    "strong-error-handler": {
      "params": {
        "debug": true
      }
  }
}

See also strong-error-handler's options and the related code change.

Remove current context API and middleware

We have removed the following current-context-related APIs:

• loopback.getCurrentContext
• loopback.createContext
• loopback.runInContext

Additionally, loopback#context middleware and remoting.context server
config were removed too.

Upgrading from 2.x to 3.x

When upgrading from LoopBack 2.x, you need to disable or remove
remoting.context configuration in your server config.

{
  "remoting": {
    "context": false, // or remove completely
    // etc.
  },
  // etc.
}

Without this change, you will see the following error on the first HTTP request
received:

Unhandled error for request GET /api/Users:
Error: remoting.context option was removed in version 3.0.
See https://docs.strongloop.com/display/APIC/Using%20current%20context for more
details.
    at restApiHandler (.../node_modules/loopback/server/middleware/rest.js:44:15)
    at Layer.handle [as handle_request] (.../node_modules/express/lib/router/layer.js:95:5)

Setting up "current context" in 3.x

To setup "current context" feature in your LoopBack 3.x application, you
should use loopback-context
module:

1. Add loopback-context to your dependencies

2. Configure the new context middleware in your server/middleware-config.json file

   {
     "initial": {
       "loopback-context#per-request": {}
     }
   }

3. Replace all usages of loopback.getCurrentContext with the following:

   // at the top of your file
   var LoopBackContext = require('loopback-context');
   
   // in your code
   var ctx = LoopBackContext.getCurrentContext();
   if (ctx) {
     // use the context
   }

See also loopback#2564
and the official documentation

Remove sugar for creating models

app.model(modelName, settings), a sugar for creating non-existing model, is
now removed in favor of promoting use of:

• app.registry.createModel(modelName, properties, options) to create new model
• app.model(modelCtor, config) to update existing model and attach it to app

Please see related code changes.