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.
Modify the code detecting whether logoutSessionsOnSensitiveChanges
is enabled to correctly handle the case when the model is not attached
to any application, as is the case with loopback-component-passport
tests.
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.
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.
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.
- Expose "keys()" at "GET /keys"
- Add a dummy implementation for "iterateKeys" to serve a useful error
message when the model is not attached correctly.
*Re-mapping `updateAttributes` endpoint to use
`PATCH` and `PUT`(configurable) verb
*Exposing `replaceById` and `replaceOrCreate` via
`POST` and `PUT`(configurable) verb
Use local registry in test fixtures to prevent collision in globally
shared models.
Fix issues discoverd in auth implementation where the global registry
was used instead of the correct local one.