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.
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.
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
- 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.
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.
*Re-mapping `updateAttributes` endpoint to use
`PATCH` and `PUT`(configurable) verb
*Exposing `replaceById` and `replaceOrCreate` via
`POST` and `PUT`(configurable) verb
Modify `Change.rectify` to look up the current checkpoint only when
there was actually some change made.
This should improve the performance of `rectifyAll` when called from a
regular timer and there were no changes made since the last call.
Before this commit, `rectifyAll` would perform N calls of
`Checkpoint.current` where N is the number of model instances. With
this commit in place, no call is made.
Modify `Change.rectify()` to not make any changes to the Change instance
(most notably to not modify the `checkpoint` field) when the tracked
model instance was not changed.
This should improve the performance of change replication as it reduces
the number of unnecessary replications.
For example, before this commit, every run of `rectifyAll` would
trigger a full sync of all clients, because all change instances would
be moved to the current checkpoint.
Fix `Application.resetKeys()` to reset instance id only if it is not
already set. This fixes a bug where each call of resetKeys created
a new instance.
Change the type of the "include" argument to "string array".
The type used to be "string" before and thus requests sending multiple
include items were technically incorrect.
Add end-to-end unit-tests verifying enforcement of access control during
conflict resolution.
Implement two facade methods providing REST API for Change methods used
by conflict resolution:
PersistedModel.findLastChange
GET /api/{model.pluralName}/{id}/changes/last
PersistedModel.updateLastChange
PUT /api/{model.pluralName}/{id}/changes/last
By providing these two methods on PersistedModel, replication users
don't have to expose the Change model via the REST API. What's even
more important, these two methods use the same set of ACL rules
as other (regular) PersistedModel methods.
Rework `Conflict.prototype.changes()` and `Conflict.prototype.resolve()`
to use these new facade methods.
Implement a new method `Conflict.prototype.swapParties()` that provides
better API for the situation when a conflict detected in Remote->Local
replication should be resolved locally (i.e. in the replication target).
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.
- `loopback.registry` is now a true global registry
- `app.registry` is unique per app object
- `Model.registry` is set when a Model is created using any registry method
- `loopback.localRegistry` and `loopback({localRegistry: true})` when set to `true` this will create a `Registry` per `Application`. It defaults to `false`.
João Ribeiro
Benjamin Kroeger
Miroslav Bajtoš
Bram Borggreve
Miroslav Bajtoš
박대선
Sergey Reus
Eric
Loay
codyolsen
Adrien Kiren
Candy
Dhaval Trivedi
Simon Ho
David Cheung
Simon Ho
Setogit
Rand McKinney
Amir Jafarian
Rik
Supasate Choochaisri
Ryan Graham
juehou
Samuel Gaus
Amir Jafarian
Richard Pringle
Simo Moujami
wusuopu
Felipe Oliveira Carvalho
Farid Nouri Neshat
Raymond Feng
Raymond Feng
Pradnya Baviskar
Miroslav Bajtoš
Berkeley Martinez
Richard Walker
Owen Brotherwood
Alexandru Savin
Miroslav Bajtoš
Edmond Lau
Ritchie Martori