Fix the definition of "data" argument to
{ type: 'object', model: modelName, ... }
That way strong-remoting passed the request body directly to the model
method (does not create a new model instance), but the swagger will
still provide correct schema for these arguments.
This fixes a bug where upsert in relation methods was adding default
property values to request payload.
Current implementation of `app.model(modelName, settings)`
works as a sugar for model creation. In 3.0, this is
not supported anymore. This implementation reports an
error when sugar is used for model creation.
Includes:
- Updated app.model() method
- Fixed test cases reflecting the change
- Expose "keys()" at "GET /keys"
- Add a dummy implementation for "iterateKeys" to serve a useful error
message when the model is not attached correctly.
Fix token middleware to check if `req.loopbackContext` is active.
The context is not active for example when express-session calls
setImmediate which breaks CLS.
Rework the test suite to always report errors and correctly signal
when async tests are done.
This should prevent spurious test failures on CI servers that are
difficult to troubleshoot, because the error is reported for different
test case.
The remote-connector test has misconfigured the client (remote) model,
where the client model was trying to keep track of changes. That's
redundant because it's up to the server model (attached directly to the
database) to track changes.
This commit fixes that configuration and also cleans up the test code
a little bit to make it easier to distinguish between the remote
(client) model and the server model.
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.
- Removes backward compatibility
for legacy end points `/models` & `/routes`
- Removes `legacyExplorer` flag which
enabled these routes
- Update related tests & tests using the
legacyExplorer flag
subsequent token middleware tries to read `token.id` when `enableDoublecheck: true`. That caused a "Cannot read property `id` of `null`" error when the first middleware didn't actually find a valid accessToken.
*Re-mapping `updateAttributes` endpoint to use
`PATCH` and `PUT`(configurable) verb
*Exposing `replaceById` and `replaceOrCreate` via
`POST` and `PUT`(configurable) verb
Rework tests in `test/rest.middleware.test.js` to not depend
on `app.autoAttach()` and global shared registry of Models. Instead,
each tests creates a fresh app instance with a new in-memory datasource
and a new set of Models.
Rework User tests to not depend on `app.autoAttach()` and global shared
registry of Models. Instead, each tests creates a fresh app instance
with a new in-memory datasource and a new set of Models.
Add two new options:
- When `enableDoublecheck` is true, the middleware will run
even if a previous middleware has already set `req.accessToken`
(possibly to `null` for anonymous requests)
- When `overwriteExistingToken` is true (and `enableDoublecheck` too),
the middleware will overwrite `req.accessToken` set by a previous
middleware instances.
Fix `getIdFromWhereByModelId()` to correctly detect the situation
when "bulkUpdate" performs a write operation using a where filter
containing both id attribute but also all other model attributes.
This should significantly improve the performance of change replication,
because the cost of running rectifyAll is very high.
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.
The decision which Promise implementation to use should be made by
LoopBack user, not by the framework.
This commit moves Bluebird reference from lib/utils.js to
test/support.js.
Modify `app.enableAuth` to automaticaly setup all required models
that are not attached to the app nor a datasource.
Users wishing to use this option must provide the name of the
data-source to use for these models.
Example usage:
var app = loopback();
app.dataSource('db', { connector: 'memory' });
app.enableAuth({ dataSource: 'db' });
app.use(loopback.rest());
app.listen(3000);
When creating an application with a local registry, the default
behaviour is to define only two core models Model & PersistedModel.
The new flag `loadBuiltinModels` modifies this behaviour and instructs
loopback to define all builtin models in the local registry too.
Process `settings.methods` and `config.methods` as a key-value map
where the key is the method name and the value is an object describing
the method in the format expected by strong-remoting.
Example: a static method `Model.create`
"methods": {
"create": {
"isStatic": true,
"accepts": {
"arg": "data", "type": "Car",
"http": { "source": "body" }
},
"returns": { "arg": "data", "type": "Car", "root": true }
}
}
This patch is based on the code proposed by @mrfelton in #1163.
This patch fixes the method Model.getApp() that started to report
the following error after b61fae5 was landed:
assert.js:88
throw new assert.AssertionError({
^
AssertionError: undefined == true
at loopback/loopback/lib/model.js:392:7
at EventEmitter.<anonymous> (loopback/loopback/lib/model.js:222:9)
at EventEmitter.g (events.js:257:16)
at emitOne (events.js:77:13)
at EventEmitter.emit (events.js:166:7)
at EventEmitter.app.model (loopback/loopback/lib/application.js:157:9)
The commit b917075 accidentally removed a couple of properties,
this commit is bringing them back:
- loopback.modelRegistry
- loopback.defaultDataSources
A unit-test was added to prevent this kind of regressions in the future.
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`.
Refactor the core implementation of current context from
server/middleware/context.js into server/current-context.js.
Expose new public API:
- loopback.runInContext
- loopback.createContext
Modify `Change.diff()` to include current data revision in each
delta reported back. The current data revision is stored in
`delta.prev`.
Modify `PersistedModel.bulkUpdate()` to check that the current data
revision matches `delta.prev` and report a conflict if a third party
has modified the database under our hands.
Fix `Change` implementation and tests so that they are no longer
attempting to create instances with duplicate ids.
(This used to work because the memory connector was silently
converting such requests to updateOrCreate/findOrCreate.)
This commit adds the ability for the developer to use a custom token generator function for the user.verify(...) method. By default, the system will still use the crypto.randomBytes() method if no option is provided.
Add tests covering typical replication scenarios that happen
in the setup where multiple clients are synchronizing changes
against a single server (database).
Rework the Change model to merge changes made within the same
Checkpoint.
Rework `replicate()` to run multiple iteration until there were no
changes replicated. This ensures that the target model is left in
a clean state with no pending changes associated with the latest
(current) checkpoint.
Extend `PersistedModel.replicate` to pass the newly created checkpoints
as the third callback argument.
The typical usage of these values is to pass them as the `since`
argument of the next `replicate()` call.
global.since = -1;
function sync(cb) {
LocalModel.replicate(
since,
RemoteModel,
function(err, conflicts, cps)
if (err) return cb(err);
if (!conflicts.length) {
since = cps;
return cb();
}
// resolve conflicts and try again
});
}
Rework the "replicate()" to create a new source checkpoint as the first
step, so that any changes made in parallel will be associated with
the next checkpoint.
Before this commit, there was a race condition where a change might
end up being associated with the already-replicated checkpoint and thus
not picked up by the next replication run.
Modify `PersistedModel.replicate` to allow consumers to provide
different "since" values to be used for the local and remote changes.
Make the "since" filters consistent and include the "since" value
in the range via `gte`. Before this commit, the local query used
`gt` and the remote query used `gte`.
Setting legacyExplorer to false in the loopback config will disable
the routes /routes and /models made available in loopback.rest.
The deprecate module has been added to the project with a reference
added for the legacyExplorer option as it is no longer required by
loopback-explorer. Tests added to validate functionality of disabled
and enabled legacy explorer routes.
Fix all test models that are tracking changes so that they have
a generated unique string id.
Make model names unique where possible to prevent tests reusing
the same model which causes unintented side effects.
Make the "redirect" parameter optional. When the parameter is not
specified, the server responds with an empty response (204). This allows
API clients to call the method without the need to handle redirects
and HTML responses.
Even when the "redirect" parameter is included, the builtin afterRemote
hook still calls next(), so that user-provided afterRemote hooks
are executed too.
Add unit-tests to verify that all DAO methods correctly create change
records.
Rework the change detection to use the new operation hooks, this fixes
the bugs where operations like "updateOrCreate" did not update change
records.
The patch strongloop/loopback-datasource-juggler#436 changed the way
how `Model.extend` works, which broke one loopback test relying on the
old behaviour.
This commit fixes the failing test. The test is checking now that
the model base was not changed, instead of checking that the base
is undefined.
Enhance the error objects with a `code` property containing
a machine-readable string code describing the error, for example
INVALID_TOKEN or USER_NOT_FOUND.
Also improve 404 error messages to include the model name.
Allow convenient URLs for curl and browsers such as:
- http://some-long-token@localhost:3000/
- http://token:some-long-token@localhost:3000/
Basic Auth specifies a 'Basic' scheme for the Authorization header
similar to how OAuth specifies 'Bearer' as an auth scheme.
Following a similar convention, extract the access token from the
Authorization header when it specifies the 'Basic' scheme, assuming
it is the larger of the <user>:<pass> segments.
When executing a request using a pooled connection, connectors
like MongoDB and/or MySQL rebind callbacks to the domain which
issued the request, as opposed to the domain which opened the pooled
connection.
This commit fixes the context middleware to play nicely with that
mechanism and preserve domain rebinds.
David Cheung
Loay
Candy
Miroslav Bajtoš
gunjpan
Amirali Jafarian
Sonali Samantaray
Simon Ho
Subramanian Krishnan
Benjamin Kroeger
Carl Fürstenberg
Samuel Reed
jannyHou
Gunjan Pandya
Simon Ho
Supasate Choochaisri
Ryan Graham
Miroslav Bajtoš
Benjamin Kröger
Ryan Graham
Samuel Gaus
Amir Jafarian
Richard Pringle
Miroslav Bajtoš
Simo Moujami
wusuopu
Richard Walker
Raymond Feng
Raymond Feng
Pradnya Baviskar
Miroslav Bajtoš
Ritchie Martori
Tom Kirkpatrick
Esco Obong
Fabien Franzen
jakerella
ulion
Ron Edgecomb
Pham Anh Tuan
Clark Wang