Fix the code invalidating access tokens on user email/password changes
to correctly handle the case when the relation
"AccessToken belongs to (subclassed) user" is not configured.
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".
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`.
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.
Operation hooks are inherited by subclassed models, therefore they must
be registered outside of `Model.setup()` function.
This commit fixes this problem in the built-in User model.
There are not tests verifying this change, as writing a test would be
too cumbersome and not worth the cost IMO.
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
Miroslav Bajtoš
Eric
Miroslav Bajtoš
Ritchie Martori
Aris Kemper
João Ribeiro
Bram Borggreve
박대선
Sergey Reus
Loay
Adrien Kiren
Candy
Dhaval Trivedi
David Cheung
Setogit
Rik
Ryan Graham
Jue Hou
Richard Pringle