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`
Enable authentication for all User unit-tests to check that the ACLs are
correctly configured.
Fix the rule for `confirm` - the correct permission is `ALLOW`, not
`ACL.ALLOW`.
Allow the developer to pass custom `remoting` options via Model
settings, e.g.
PersistedModel.extend(
'MyModel',
{ name: String },
{
remoting: { normalizeHttpPath: true }
});
Also add `options` arg to `app.handler`, this object is passed directly
to strong-remoting handler.
When running on Unix and no hostname is specified, use `0.0.0.0`
as the hostname instead of `localhost`.
When running on Windows and the hostname is either not specified or
it is `0.0.0.0` or `::`, use `localhost` in the URL. The reason is
that Windows cannot open URLs using `0.0.0.0` as a hostname.
- Move core models `Model` and `PersistedModel` to `lib/`.
- Move `AccessContext` class to `lib/`, since it is not a model.
- Move all other built-in models to `common/models`.
This is a preparation for extracting model definitions to JSON files.
By splitting the change into multiple commits, git is able to keep track
of file moves (renames).
Raymond Feng
Miroslav Bajtoš
Miroslav Bajtoš
Guilherme Cirne
Juan Pizarro
Raymond Feng
Fabien Franzen
Ritchie Martori
Alexander Ryzhikov
Clark Wang