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".
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
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".
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
1) Add integration tests running change replication over REST to verify
that access control at model level is correctly enforced.
2) Implement a new access type "REPLICATE" that allows principals
to create new checkpoints, even though they don't have full WRITE
access to the model. Together with the "READ" permission, these
two types allow principals to replicate (pull) changes from the server.
Note that anybody having "WRITE" access type is automatically
granted "REPLICATE" type too.
3) Add a new model option "enableRemoteReplication" that exposes
replication methods via strong remoting, but does not configure
change rectification. This option should be used the clients
when setting up Remote models attached to the server via the remoting
connector.
- Move core models `Model` and `PersistedModel` to `lib/`.
- Move `AccessContext` class to `lib/`, since it is not a model.
- Move all other built-in models to `common/models`.
This is a preparation for extracting model definitions to JSON files.
By splitting the change into multiple commits, git is able to keep track
of file moves (renames).
Miroslav Bajtoš
ebarault
Loay
Ryan Graham
Miroslav Bajtoš
Rob Halff
Rand McKinney