Page Contents

Overview

Set up middleware in middleware.json. Here is the default version created by the Application generator

{
  "initial:before": {
    "loopback#favicon": {}
  },
  "initial": {
    "compression": {},
    "cors": {
      "params": {
        "origin": "*",
        "credentials": true,
        "maxAge": 86400
      }
    },
    "helmet#xssFilter": {},
    "helmet#frameguard": {
      "params": [
        "deny"
      ]
    },
    "helmet#hsts": {
      "params": {
        "maxAge": 0,
        "includeSubDomains": true
      }
    },
    "helmet#hidePoweredBy": {},
    "helmet#ieNoOpen": {},
    "helmet#noSniff": {},
    "helmet#noCache": {
      "enabled": false
    }
  },
  "session": {},
  "auth": {},
  "parse": {},
  "routes": {
    "loopback#rest": {
      "paths": [
        "${restApiRoot}"
      ]
    }
  },
  "files": {},
  "final": {
    "loopback#urlNotFound": {}
  },
  "final:after": {
    "strong-error-handler": {}
  }
}

Phases

Each top-level property in middleware.json corresponds to one of the following middleware phases:  

  1. initial - The first point at which middleware can run.
  2. session - Prepare the session object.
  3. auth - Handle authentication and authorization.
  4. parse - Parse the request body.
  5. routes - HTTP routes implementing your application logic. Middleware registered via the Express API app.useapp.routeapp.get (and other HTTP verbs) runs at the beginning of this phase. Use this phase also for sub-apps like loopback/server/middleware/rest or loopback-explorer.

  6. files - Serve static assets (requests hit the file system here).

  7. final - Deal with errors and requests for unknown URLs.

Each phase has “before” and “after” subphases in addition to the main phase, encoded following the phase name, separated by a colon. For example, for the “initial” phase, middleware executes in this order:

  1. initial:before 
  2. initial
  3. initial:after

Middleware within a single subphase executes in the order in which it is registered. However, you should not rely on such order. Always explicitly order the middleware using appropriate phases when order matters.

In general, each phase has the following syntax:

phase[:sub-phase] : {
  middlewarePath : {
    [ enabled: [true | false] ]
    [, name:    nameString ]
    [, params : paramSpec ]
    [, methods: methodSpec ]
    [, paths :   routeSpec ]
  }
}

Where:

  • phase: is one of the predefined phases listed above (initial, session, auth, and so on) or a custom phase. See Adding a custom phase.
  • sub-phase: (optional) can be before or after.
  • name: optional middleware name.
  • middlewarePath: path to the middleware function.
  • paramSpec: value of the middleware parameters, typically a JSON object.
  • methodSpec: An array containing HTTP methods for which the middleware is triggered; for example: "methods" : ["GET", "POST"]. If not present, applies to all methods.
  • routeSpec: REST endpoint(s) that trigger the middleware.

For more information, see Defining middleware.

CORS settings

Set Cross-origin resource sharing (CORS) settings as cors.params properties in the initial phase.

You can set other CORS properties as well. For more information, see cors.

Property Type Description Default
cors.params.origin String|Boolean Configures the Access-Control-Allow-Origin CORS header. Expects a string (for example: "http://example.com/" or "*"). Set to true to reflect the request origin, as defined by req.header('Origin'). Set to false to disable CORS. Can also be set to a function, which takes the request origin as the first parameter and a callback (which expects the signature err [object], allow [bool]) as the second. true
cors.params.credentials Boolean Configures the Access-Control-Allow-Credentials CORS header. Set to true to pass the header, otherwise it is omitted. You can set other cors properties as well. For more information, see cors. true
cors.params.maxAge Number Configures the Access-Control-Allow-Max-Age CORS header. Set to an integer to pass the header, otherwise it is omitted. 86400