The fix introduced in previous commit was relying on the default
merge algorighm applied when a child model inherits relation config
from the parent.
This commit changes the check to use a more reliable approach
based on the relation metadata configured by the child model.
In the present implementation `verifyUserRelations(Model)` assumes that
`Model.relations.accessTokens` is always set, and as a result may
crash when trying to access `polymorphic` property of that relation.
It seems the intention is to check whether the the following conditions
are met:
1. a model has a hasMany accessTokens relation
2. that relation is polymorphic
This commit fixes the problem by accounting for the case where the
accessTokens relation was not correctly set up.
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.
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 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']".
- 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.
Define a new property `AccessToken.scopes` to contain the list of
scopes granted to this access token.
Define a new remote method metadata `accessScopes` to contain a list
of scope name required by this method.
Define a special built-in scope name "DEFAULT" that's used when
a method/token does not provide any scopes. This allows access
tokens to grant access to both the default scope and any additional
custom scopes at the same time.
Modify the authorization algorithm to ensure that at least one
of the scopes required by a remote method is allowed by the scopes
granted to the requesting access token.
The "DEFAULT" scope preserve backwards compatibility because existing
remote methods with no `accessScopes` can be accessed by (existing)
access tokens with no `scopes` defined.
Impact on existing applications:
- Database schema must be updated after upgrading the loopback version
- If the application was already using a custom `AccessToken.scopes`
property with a type different from an array, then the relevant code
must be updated to work with the new type "array of strings".
Emit a new method "remoteMethodAdded" whenever a new method is added,
typically when `Model.remoteMethod` or `Model.nestRemoting` is called.
The method is emitted both by the Model affected and the application
object.
Adds an authorizedRoles object to remotingContext.args.options
which contains all the roles (static and dynamic) that are
granted to the user when performing a request through
strong-remoting to an app with authentication enabled.
The authorizedRoles object for example looks like:
{
$everyone: true,
$authenticated: true,
myRole: true
}
NOTE: this pr also covers a number of jsdoc fixes as well
as refactoring in ACL.js and access-context.js
Allow custom properties to be added to Change Model,
and make change filter customizable through mixins
to allow to add the custom property to the filter
used to look up relevant changes during change replication.
Modify `app.enableAuth()` to verify that (custom) User and AccessToken
models have correctly configured their hasMany/belongsTo relations
and print a warning otherwise.
Fix the code loading builtin models to always clone the JSON object
used as model settings/definition. This is needed to allow applications
to modify model settings while not affecting settings of new models
created in the local registry of another app.
Add a new model-level setting "replicationChunkSize" which allows
users to configure change replication algorithm to issue several
smaller requests to fetch changes and upload updates.
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.
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".
The option injectOptionsFromRemoteContext was added to LoopBack 2.x only
and is not available in LoopBack 3.x (and newer).
When a model with this option is encountered, we are printing a warning
message now, to let the user know about this change between 2.x and 3.x.
Raymond Feng
Mohammed Essehemy
virkt25
Diana Lau
mcitdev
ryanxwelch
Dimitris
Miroslav Bajtoš
Kevin Delisle
Kevin Scroggins
Justin Ross
Edward Choh
bmatson
Samuel Reed
Raymond Feng
Jürg Lehni
Siegfried Ehret
pierreclr
Zak Barbuto
Kevin Delisle
Rashmi Hunt
Alexei Smirnov
Farid Nouri Neshat
Daijiro Wachi
Candy
Piero Maltese
Miroslav Bajtoš
Flavien DAVID
ebarault
agriwebb build
kobaska
Raymond Camden