Fix `Role.isOwner()` to check both principalId and principalType.
This fixes a bug where users from different User model were treated
as owners as long as their user id was the same as owner's id.
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.
Allow LoopBack applications to configure multiple User models and share
the same AccessToken model.
To enable this feature:
1) In your custom AccessToken model:
- add a new property "principalType" of type "string".
- configure the relation "belongsTo user" as polymorphic,
using "principalType" as the discriminator
2) In your User models:
- Configure the "hasMany accessTokens" relation as polymorphic,
using "principalType" as the discriminator
When creating custom Role and Principal instances, set your
User model's name as the value of "prinicipalType".
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.
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`.
- Remove ES5 parser exception from .eslintrc
- Configure Karma to use Babel to transpile ES6 sources to ES5,
because PhantomJS does not support ES6
- Upgrade es5-shim to es6-shim
Fix User model to preserve the current session (provided via
"options.accessToken") when invalidating access tokens after a change
of email or password property.
Yesterday, the loopback we are using in our system was upgraded
via npm, and since the upgrade, we noticed that every time
the user model updates, the emailVerified column would change to false.
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.
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.
this is needed because we added allowArray flag to persisted model's
remoteMethod, but when relations try to rebuild such methods, it does
not carry over such flags
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 for current implimentation that returned all models that had any
assigned roles. Context was not carried into listByPrincipalType,
setting roleId as null.
In strong-remoting 3.x, we have stricken the coercion of inputs
methods that are expecting an Object will nolonger accept an array
as input, to preserve backwards compatibility we have added flag
allowArray in remote arguments, which would accept an array of objects
ebarault
Miroslav Bajtoš
Miroslav Bajtoš
David Hernandez
Ritchie Martori
Aris Kemper
João Ribeiro
Benjamin Kroeger
Bram Borggreve
kobaska
박대선
Sergey Reus
David Cheung
Loay
Kogulan Baskaran
codyolsen
Adrien Kiren
Candy
Dhaval Trivedi