<a name"1.8.1">

1.8.1 (2017-02-03)

Bug Fixes

• pass authstrategy to Bearer module (3a6baccc)

<a name"1.8.0">

1.8.0 (2017-01-23)

Bug Fixes

• ensure HTTPS instance is destroyed at server shutdown (d269f805)
• redirect http to https with 301 instead of 302 (ae6c13a3)
• make hard-coded protocol redirect dynamic (52f7fe87)
• remove call to hasOwnProperty for node >= 6 (cfa48adc)
• package.json to reduce vulnerabilities (34b34964)
• make tests run cross platform (2f3f7081)
• extend ds cache options using main config options (c0e9a12e)
• allow a 404 route to skip validation (9ba36b60)

Features

• add example https config file (d069b2b4)
• refactor http/https/http>https config (ce62e0e0)
• add http/http+https/https support (05cee152)

Cache-Control headers for redirects

A cache-control header can be added to a 301/302 redirect by adding to the headers configuration block:

"headers": {
  "cacheControl": {
    "301": "no-cache"
  }
}

Dust Helpers

Version 1.7.0 sees the completion of the extraction of the built-in Dust helpers. These are no longer available in the core Web product and must be loaded separately, see https://www.npmjs.com/package/@dadi/dustjs-helpers for usage information.

Preloaded Data

The Web configuration file now has provision for specifying datasources that should be loaded at startup. Add preload datasources by adding a block to the configuration file:

data: {
  preload: [
    "categories"
  ]
}

Accessing preloaded data in Web events is as simple as passing the datasource key to the Preload module:

var Preload = require('@dadi/web').Preload
var categories = Preload().get('categories')

The preloader stores the contents of the inner results property of the data that is returned, so there is no metadata section as you would normally find in data returned from DADI API.

Note: There is no refresh of this preloaded data, yet. Refresh support will be added in a future release.

Page Route Specification

DADI Web 1.7.0 introduces a more explicit way of specifying multiple routes per page . The route property has been replaced with routes which should be an Array of route objects.

Each route object must contain, at the very least, a path property. At startup, Web adds the value of each path property to an internal collection of routes for matching incoming requests.

In this example, the same page (and therefore it's template) will be loaded for requests matching any of the formats specified by the path properties:

"routes": [
  {
    "path": "/movies/:title"
  },
  {
    "path": "/movies/news/:title?/"
  },
  {
    "path": "/movies/news/:page?/"
  }
]

Route Validation/Constraints

DADI Web 1.7.0 introduces several new ways to ensure the correct route is loaded for a particular request, hopefully reducing the hacky workarounds we've implemented for some projects.

See the documentation here: xxx/routing.md.

For assistance with routing changes, please add an issue to your project and assign it to jimlambie.

Integration of @dadi/cache

The DADI Cache module has replaced the caching code in Web 1.7.0. DADI Cache includes better failover support for when Redis connections fail. Datasources now require a caching configuration similar the main config. See the next section, Migration to Version 1.7.0.

Migrating to Version 1.7.0

To help you migrate your Web installation to v1.7.0, the router will inform you of any changes required to page specifications if the existing route property has not yet been modified.

Look out for console messages similar to the following:

The `route` property for pages has been extended to provide better routing functionality.
Please modify the route property for page 'movies_news'. The schema should change to the below:

{
  "page": {
    "name": "movies_news",
    "description": "movies news",
    "language": "en"
  },
  "settings": {
    "cache": true
  },
  "datasources": [],
  "events": [],
  "routes": [
    {
      "path": "/movies/news/:furl?/"
    }
  ]
}

Migration datasource specifications

Note that it isn't a requirement to specify caching for datasources, as they will use the main configuration settings if none are specified.

Prior to 1.7.0, caching configuration took the following format:

"caching": {
  "enabled": true,
  "ttl": 300,
  "directory": "./cache/web/",
  "extension": "json"
}

In 1.7.0 this has changed. If you want your datasources to be cached differently to pages, the caching configuration should now appear similar to the main configuration file:

"caching": {
  "ttl": 300,
  "directory": {
    "enabled": true,
    "path": "./cache/web/",
    "extension": "json"
  },
  "redis": {
    "enabled": false
  }
}

Dust Helpers

Version 1.7.0 sees the completion of the extraction of the built-in Dust helpers. These are no longer available in the core Web product and must be loaded separately, see https://www.npmjs.com/package/@dadi/dustjs-helpers for usage information.

Preloaded Data

The Web configuration file now has provision for specifying datasources that should be loaded at startup. Add preload datasources by adding a block to the configuration file:

data: {
  preload: [
    "categories"
  ]
}

Accessing preloaded data in Web events is as simple as passing the datasource key to the Preload module:

var Preload = require('@dadi/web').Preload
var categories = Preload().get('categories')

The preloader stores the contents of the inner results property of the data that is returned, so there is no metadata section as you would normally find in data returned from DADI API.

Note: There is no refresh of this preloaded data, yet. Refresh support will be added in a future release.

Page Route Specification

DADI Web 1.7.0 introduces a more explicit way of specifying multiple routes per page . The route property has been replaced with routes which should be an Array of route objects.

Each route object must contain, at the very least, a path property. At startup, Web adds the value of each path property to an internal collection of routes for matching incoming requests.

In this example, the same page (and therefore it's template) will be loaded for requests matching any of the formats specified by the path properties:

"routes": [
  {
    "path": "/movies/:title"
  },
  {
    "path": "/movies/news/:title?/"
  },
  {
    "path": "/movies/news/:page?/"
  }
]

Route Validation/Constraints

DADI Web 1.7.0 introduces several new ways to ensure the correct route is loaded for a particular request, hopefully reducing the hacky workarounds we've implemented for some projects.

See the documentation here: xxx/routing.md.

For assistance with routing changes, please add an issue to your project and assign it to jimlambie.

Integration of @dadi/cache

The DADI Cache module has replaced the caching code in Web 1.7.0. DADI Cache includes better failover support for when Redis connections fail. Datasources now require a caching configuration similar the main config. See the next section, Migration to Version 1.7.0.

Migrating to Version 1.7.0

To help you migrate your Web installation to v1.7.0, the router will inform you of any changes required to page specifications if the existing route property has not yet been modified.

Look out for console messages similar to the following:

The `route` property for pages has been extended to provide better routing functionality.
Please modify the route property for page 'movies_news'. The schema should change to the below:

{
  "page": {
    "name": "movies_news",
    "description": "movies news",
    "language": "en"
  },
  "settings": {
    "cache": true
  },
  "datasources": [],
  "events": [],
  "routes": [
    {
      "path": "/movies/news/:furl?/"
    }
  ]
}

Migration datasource specifications

Note that it isn't a requirement to specify caching for datasources, as they will use the main configuration settings if none are specified.

Prior to 1.7.0, caching configuration took the following format:

"caching": {
  "enabled": true,
  "ttl": 300,
  "directory": "./cache/web/",
  "extension": "json"
}

In 1.7.0 this has changed. If you want your datasources to be cached differently to pages, the caching configuration should now appear similar to the main configuration file:

"caching": {
  "ttl": 300,
  "directory": {
    "enabled": true,
    "path": "./cache/web/",
    "extension": "json"
  },
  "redis": {
    "enabled": false
  }
}

This version update adds the ability to use a datasource as the main source of the htaccess style rewrites

Add the following block to configuration, specifying an existing datasource name:

rewrites: {
   datasource: "rewrites"
   path: ""
 }

Cluster support

This version adds support for running in cluster mode to take advantage of multiple core CPUs.

The default configuration does not use cluster mode. To enable, add the following to configuration:

"cluster": true

Web will report it is running in cluster mode at startup.

Misc

• fix #63: don't use main config options for ds extension

  if no cache config options are provided for a datasource the main
  config settings are used. for a datasource, we need to use .json
  by default, rather than the main config setting

• add 503 server too busy response

• allow port configuration to be set from environment variable PORT

• fix: bug where an ID parameter from the request URL was added to all subsequent datasource filters

• fix: bug where caching was performed routing, therefore sometimes ignoring routes

• fix: allow datasource configuration to override protocol:

  • Previous versions assumed if the API settings used HTTPS then the datasource calls should too. Fix to allow
    a datasource to specify it's protocol and have that override the API setting.

• add support for HTTPS

• add page template metadata to returned JSON:

  "page": {
    "name": "movies_news",
    "description": "movies news",
    "language": "en"
  }
  

• fix #48: test current URL against returned redirect results:

  • when using a datasource for redirects, ensure that any results
    returned are matched against the URL before redirecting the request

• add config option to force a domain redirect

  this allows a setting in config as below which will force redirecting
  to the specified domain, e.g. useful to redirect a root domain to www.

  "rewrites": {
    "forceDomain": "www.example.com"
  }
  

• fix: allow any format for config setting sessions.cookie.maxAge

  the default for express-session is to use cookie.maxAge = null
  which means no "expires" parameter is set so the cookie becomes
  a browser-session cookie.

  When the user closes the browser the cookie (and session) will be removed.

• allow Redis use for session store configuration

• add token wallet path to paths configuration blocks

• integration @dadi/passport for token generation/validation

• add protocol option to api and auth configuration blocks

Status endpoint

Adds an endpoint at /api/status which returns server/application data in JSON format.

The request must be a POST and the body must have a clientId and secret that match those stored in the application's config file.

POST /api/status HTTP/1.1
Host: www.example.com
Content-Type: application/json

{"clientId": "testClient","secret": "superSecret"}

Partials in subdirectories

Storing partials in subdirectories of the main partials folder previously caused the application crash. Now it doesn't. Thanks @eduardoboucas!

requestParams type definition

Now allows the ability to specify a type definition of 'Number' on requestParams in a datasource
schema to override default of String. Thanks @mingard!

"requestParams": [
  { "param": "author", "field": "authorId", "type": "Number" }
]

This release is the first for the reconfigured application, now able to be installed as a node module.

It includes:

• configurable workspace paths
• support for in-memory and MongoDB backed sessions
• long-awaited support for POST requests