Update User's "before delete" hook to take into account the case when
the related AccessToken model was not configured in the application
(attached to a datasource).
Fix the owner role resolver to correctly handle the case when a user
from one model (e.g. Seller) is accessing an instance of another
user-like model (e.g. Customer).
Add API allowing applications to hide a Model from the
REST API and remove all references to it, allowing Garbage Collector
to claim all memory used by the model.
Before this change, when the test failed, the rejected promise
was not reported back to mocha and triggered "unhandled promise
rejection" warning only.
For scoped or related create method, the createOnlyInstance flag should
be calculated on the target model. For example, User.createAccessTokens
should set the flag only if AccessToken has updateonly properties.
Fix the code extracting current user id from the access token provided
in the HTTP request, to allow only access tokens created by the target
user models to execute the action.
This fixes the following security vulnerability:
* We have two user models, e.g. Admin and Customer
* We have an Admin instance and a Customer instance with the same
id and the same password.
* The Customer can change Admin's password using their
regular access token.
Fix the code extracting current user id from the access token provided
in the HTTP request, to allow only access tokens created by the target
user models to execute the action.
This fixes the following security vulnerability:
* A UserA with id 1 (for example), requires a resetToken1
* A UserB with the same id requires a resetToken2.
* Using resetToken2, use the UserAs/reset-password endpoint and change
the password of UserA and/or vice-versa.
- Fix `User.prototype.verify` to not modify properties of the supplied
`verifyOptions` argument. This is needed to allow callers to supply
the same options object to multiple calls of `verify`.
- Fix `User.getVerifyOptions` to always return a new copy of the
options object. This is needed to allow callers to modify the
returned options object without affecting the result returned
by subsequent calls of `getVerifyOptions`.
Fix the code resolving OWNER role to correctly handle the situation
where the target model has multiple "belongsTo" relations to the User
model.
Introduce a new model setting "ownerRelations" that enables the new
behavior. When "ownerRelations" is set to true, then all "belongsTo"
relations are considered as granting ownership. Alternatively,
"ownerRelations" can be set to an array of the relations which
are granting ownership.
For example, a document can "belongTo" an author and a reviewer,
but only the author is an owner, the reviewer is not. In this case,
"ownerRelations" should be set to "['author']".
When acl.resolvePermission was called with a request containing a
wildcard, it would return the matching acl with lowest score instead of
higher.
Fixes#2153
Reword the error message returned when the password is too long
- remove the plaintext password value, it looks very bad
- include information about the maximum allowed length instead
Also add additional context to the error.
- Remove flags and properly finish the stream.
- Destroy emits an end event for compability with ending of
ReadableStream now.
- Check for default implementation of destroy() method,
because in Node.js 8 all types of streams have a native one.
1. Make it possible to reuse getIdForRequest()
2. Introduce a flag to control if oAuth2 bearer token should be base64
encoded
3. Promote resolve() to locate/validate access tokens by id
This commit adds:
- user.prototype.verify(verifyOptions, options, cb)
- remote method /user/:id/verify
- User.getVerifyOptions()
The remote method can be used to replay the sending of a user
identity/email verification message.
`getVerifyOptions()` can be fully customized programmatically
or partially customized using user model's `.settings.verifyOptions`
`getVerifyOptions()` is called under the hood when calling the
/user/:id/verify remote method
`getVerifyOptions()` can also be used to ease the building
of identity verifyOptions:
```js
var verifyOptions = {
type: 'email',
from: 'noreply@example.com'
template: 'verify.ejs',
redirect: '/',
generateVerificationToken: function (user, options, cb) {
cb('random-token');
}
};
user.verify(verifyOptions);
```
NOTE: the `User.login()` has been modified to return the userId when
failing due to unverified identity/email. This userId can then be used
to call the /user/:id/verify remote method.
Improve the flow for setting/changing/resetting User password to make
it more secure.
1. Modify `User.resetPassword` to create a token scoped to allow
invocation of a single remote method: `User.setPassword`.
2. Scope the method `User.setPassword` so that regular tokens created
by `User.login` are not allowed to execute it.
For backwards compatibility, this new mode (flow) is enabled only
when User model setting `restrictResetPasswordTokenScope` is set to
`true`.
3. Changing the password via `User.prototype.patchAttributes`
(and similar DAO methods) is no longer allowed. Applications
must call `User.changePassword` and ask the user to provide
the current (old) password.
For backwards compatibility, this new mode (flow) is enabled only
when User model setting `rejectPasswordChangesViaPatchOrReplace` is set
to `true`.
virkt25
mcitdev
wolrajhti
Kevin Scroggins
Miroslav Bajtoš
Kevin Delisle
Raymond Feng
Zak Barbuto
Justin Ross
Edward Choh
bmatson
Samuel Reed
CSLTech
Raymond Feng
pierreclr
Farid Neshat
Rashmi Hunt
loay
Jürg Lehni
Sakib Hasan
ssh24
Alexei Smirnov
Daijiro Wachi
Piero Maltese
ebarault
Miroslav Bajtoš