Fix configuration of Karma:
- Disable ES6 modules. The ES6 module transpiler is adding
"use strict" to all source files, this breaks e.g. chai or juggler
- Relax "ignore" setting to exclude only strong-task-emitter,
thus bring back Babel transpilation for chai and juggler.
Before this change, dependencies in node_modules (e.g. strong-remoting)
were not transformed to ES5 and thus crashed the tests in PhantomJS.
Note that loopback-datasource-juggler cannot be babelified to ES5
because it does not correctly support strict mode yet.
Rework the test verifying properties of `loopback` to ignore
new express properties added after the test was written.
Ignore "json" and "urlencoded" middleware that was added back
to Express, keep using our wrappers printing a deprecation message.
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.
Applications using MongoDB connectors typically have `user.id`
property of type ObjectID.
This commit fixes the code building the verification URL to
correctly convert the user id value into string.
Fix User.prototype.verify to call `querystring.stringify` instead
of concatenating query-string components directly.
In particular, this fixes the bug where `options.redirect` containing
a hash fragment like `#/home?arg1=value1&arg2=value2` produced incorrect
URL, because the `redirect` value was not correctly encoded.
Return 401 when the request does not provide any accessToken argument
or the token was not found.
Also simplify the implementation of the `logout` method to make only
a single database call (`deleteById`) instead of `findById` + `delete`.
Disable invalidation of access tokens by default to restore backwards
compatibility with older 2.x versions.
Add a new application-wide flag logoutSessionsOnSensitiveChanges
that can be used to explicitly turn on/off the token invalidation.
When the flag is not set, a verbose warning is printed to nudge the user
to make a decision how they want to handle token invalidation.
Fix User model to preserve the current session (provided via
"options.accessToken") when invalidating access tokens after a change
of email or password property.
We noticed that every time the user model updates, the emailVerified
column would change to false, even though the email was not changed
at all.
I took a look and realized there might be an error in
https://github.com/strongloop/loopback/commit/eb640d8
The intent of the commit just mention is to make emailVerified false
when the email gets changed, but notice that ctx.data.email is null
on updates, so the condition is always met and emailVerified always
becomes false.
This commit fixes the issue just mentioned.
Hide the new "options" arguments behind a feature flag
injectOptionsFromRemoteContext that is disabled by default for backwards
compatibility.
Fix construction of sharedCtor remoting metadata to prevent the
situation when we are configuring remoting metadata after
strong-remoting has already picked up data from our parent (base) model.
Define a new Model method "createOptionsFromRemotingContext" that allows
models to define what "options" should be passed to methods invoked
via strong-remoting (e.g. REST).
Define a new http mapping `http: 'optionsFromRequest'` that invokes
`Model.createOptionsFromRemotingContext` to build the value from
remoting context.
This should provide enough infrastructure for components and
applications to implement their own ways of building the "options"
object.
Currently the return type of Role.getRoles() method is inconsistent:
role names are returned for smart roles and role ids are returned for
static roles (configured through user-role mapping).
This commit adds a new option to Role.getRoles() allowing the caller
to request role names to be returned for all types of roles.
- Fix for current implimentation that returned all models that had any
assigned roles. Context was not carried into listByPrincipalType,
setting roleId as null.
- Add a new User setting 'allowEternalTokens'
- Enhance 'AccessToken.validate' to support eternal tokens with ttl
value -1 when the user model allows it.
Current implementation of `app.model(modelName, settings)`
works as a sugar for model creation. In LB 3.0, this is
not supported anymore. This backporting:
- keeps the sugar method for model creation for backward
compatibility
- updates test cases to use `app.registry.createModel()`
for model creation
Backport of #2401
Fix the definition of "data" argument to
{ type: 'object', model: modelName, ... }
That way strong-remoting passed the request body directly to the model
method (does not create a new model instance), but the swagger will
still provide correct schema for these arguments.
This fixes a bug where upsert in relation methods was adding default
property values to request payload.
Miroslav Bajtoš
Samuel Reed
Miroslav Bajtoš
loay
Aaron Buchanan
phairow
Ritchie Martori
Benjamin Kroeger
Aris Kemper
João Ribeiro
Sergey Reus
박대선
kobaska
Bram Borggreve
Eric
codyolsen
Adrien Kiren
Kogulan Baskaran
Dhaval Trivedi
Tim van der Staaij
gunjpan
Richard Pringle
Amir Jafarian
Sonali Samantaray