AppDynamics injects a proxy object into the router stack, which it
uses for its network analysis. This is similar to how NewRelic
adds a sentinel handler to the router stack. This commit adds a
similar workaround so that loopback can find the original layer.
Add API allowing applications to hide a Model from the
REST API and remove all references to it, allowing Garbage Collector
to claim all memory used by the model.
Emit a new method "remoteMethodAdded" whenever a new method is added,
typically when `Model.remoteMethod` or `Model.nestRemoting` is called.
The method is emitted both by the Model affected and the application
object.
Modify `app.enableAuth()` to verify that (custom) User and AccessToken
models have correctly configured their hasMany/belongsTo relations
and print a warning otherwise.
Notable side-effects:
- loopback no longer exports "caller" and "arguments" properties
- kv-memory connector is now properly added to the connector registry
- the file "test/support.js" was finally removed
Current implementation of `app.model(modelName, settings)`
works as a sugar for model creation. In 3.0, this is
not supported anymore. This implementation reports an
error when sugar is used for model creation.
Includes:
- Updated app.model() method
- Fixed test cases reflecting the change
Modify `app.enableAuth` to automaticaly setup all required models
that are not attached to the app nor a datasource.
Users wishing to use this option must provide the name of the
data-source to use for these models.
Example usage:
var app = loopback();
app.dataSource('db', { connector: 'memory' });
app.enableAuth({ dataSource: 'db' });
app.use(loopback.rest());
app.listen(3000);
- `loopback.registry` is now a true global registry
- `app.registry` is unique per app object
- `Model.registry` is set when a Model is created using any registry method
- `loopback.localRegistry` and `loopback({localRegistry: true})` when set to `true` this will create a `Registry` per `Application`. It defaults to `false`.
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)/]
});
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);
}
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.
Diana Lau
Nora
Miroslav Bajtoš
Mike Li
Mohammed Essehemy
virkt25
Kevin Scroggins
Justin Ross
Jürg Lehni
Daijiro Wachi
Flavien DAVID
Miroslav Bajtoš
Loay
David Cheung
Richard Pringle
gunjpan
Subramanian Krishnan
Supasate Choochaisri
Ryan Graham
Raymond Feng
Miroslav Bajtoš
Ritchie Martori
Rob Halff
Miroslav Bajtoš
Fabien Franzen