Currently any `currentUserLiteral` routes when accessed with a bad
token throw a 500 due to a SQL error that is raised because
`Model.findById` is invoked with `id={currentUserLiteral}`
(`id=me` in our case) when the url rewrite fails.
This commit changes the token middleware to return 401 Not Authorized
when the client is requesting a currentUserLiteral route without
a valid access token.
Fixing server/middleware/token.js to handle correctly the
setup of a custom AccessToken model by name in either
middleware.json or using any of :
app.use(loopback.token({...}));
app.middlewareFromConfig(loopback.token, {...})
app.middleware('auth', loopback.token({...})
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
Fix token middleware to check if `req.loopbackContext` is active.
The context is not active for example when express-session calls
setImmediate which breaks CLS.
Add two new options:
- When `enableDoublecheck` is true, the middleware will run
even if a previous middleware has already set `req.accessToken`
(possibly to `null` for anonymous requests)
- When `overwriteExistingToken` is true (and `enableDoublecheck` too),
the middleware will overwrite `req.accessToken` set by a previous
middleware instances.
- `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`.
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' });