Add unit-tests to verify that all DAO methods correctly create change
records.
Rework the change detection to use the new operation hooks, this fixes
the bugs where operations like "updateOrCreate" did not update change
records.
Express has recently deprecated `req.param()` to force developers
to be explicit about the source of the value. To avoid deprecation
warnings, this commit replaces all calls of `req.param()` with a
simplified inline version.
Enhance the error objects with a `code` property containing
a machine-readable string code describing the error, for example
INVALID_TOKEN or USER_NOT_FOUND.
Also improve 404 error messages to include the model name.
Bugs fixed:
- express helpers like `req.get` are now available in middleware
handlers registered via `app.middleware`
- `req.url` does not include the mountpath prefix now, this is
consistent with the behaviour of `app.use`
The implementation of phased middleware was completely rewritten.
- We no longer use Phase and PhaseList objects from loopback-phase.
- Handler functions are registered via the `Layer` mechanism used by
express router.
- The app keeps the layers sorted according to phases.
Add a new argument to `app.middleware` allowing developers
to restrict the middleware to a list of paths or regular expresions.
Modify `app.middlewareFromConfig` to pass `config.paths` as the second
arg of `app.middleware`.
Examples:
// A string path (interpreted via path-to-regexp)
app.middleware('auth', '/admin', ldapAuth);
// A regular expression
app.middleware('initial', /^\/~(admin|root)/, rejectWith404);
// A list of scopes
app.middleware('routes', ['/api', /^\/assets/.*\.json$/], foo);
// From config
app.middlewareFromConfig(
handlerFactory,
{
phase: 'initial',
paths: ['/scope', /^\/(a|b)/]
});
The new location allows developer to use the following identifiers
when loading the middleware using the new declarative style:
app.middlewareFromConfig(
require('loopback/server/middleware/rest'),
{ phase: 'routes' });
app.middlewareFromConfig(
require('loopback/server/middleware/url-not-found'),
{ phase: 'final' });
Refactor the implementation to use the new method `phaseList.zipMerge`.
This is commit is changing the behaviour in the case when
the first new phase does not exist in the current list.
Before the change, all new phases were added just before the "routes"
phase.
After this change, new phases are added to the head of the list,
until an existing phase is encountered, at which point the regular
merge algorithm kicks in.
Example:
app.defineMiddlewarePhases(['first', 'routes', 'subapps']);
Before the change: code throws an error - 'routes' already exists.
After the change: phases are merged with the following result:
'first', 'initial', ..., 'routes', 'subapps', ...
Implement method for registering (new) middleware phases.
- If all names are new, then the phases are added just before
the "routes" phase.
- Otherwise the provided list of names is merged with the existing
phases in such way that the order of phases is preserved.
Example
// built-in phases:
// initial, session, auth, parse, routes, files, final
app.defineMiddlewarePhases('custom');
// new list of phases
// initial, session, auth, parse,
// custom,
// routes, files, final
app.defineMiddlewarePhases([
'initial', 'postinit', 'preauth', 'routes', 'subapps'
]);
// new list of phases
// initial,
// postinit, preauth,
// session, auth, parse, custom,
// routes,
// subapps,
// files, final
Implement a function registering a middleware using a factory function
and a JSON config.
Example:
app.middlewareFromConfig(compression, {
enabled: true,
phase: 'initial',
config: {
threshold: 128
}
});
Modify the app and router implementation, so that the middleware is
executed in order defined by phases.
Predefined phases:
'initial', 'session', 'auth', 'parse', 'routes', 'files', 'final'
Methods defined via `app.use`, `app.route` and friends are executed
as the first thing in 'routes' phase.
API usage:
app.middleware('initial', compression());
app.middleware('initial:before', serveFavicon());
app.middleware('files:after', loopback.urlNotFound());
app.middleware('final:after', errorHandler());
Middleware flavours:
// regular handler
function handler(req, res, next) {
// do stuff
next();
}
// error handler
function errorHandler(err, req, res, next) {
// handle error and/or call next
next(err);
}
Modify `loopback.rest()` to read the configuration for
`loopback.context` from `app.get('remoting')`, which is the approach
used for all other configuration options related to the REST transport.
- Implement the middleware `loopback.context`
- Inject context into juggler and strong-remoting
- Make http context optional and default to false
- Optionally mount context middleware from `loopback.rest`
Miroslav Bajtoš
Raymond Feng
crandmck
Ritchie Martori
Miroslav Bajtoš
Ron Edgecomb
bitmage
Clark Wang
Ryan Graham
Raymond Feng
Alex Voitau