* Converted example to use ES6 conventions (fat-arrow functions)
* Removed arrow functions from onRendered/onDestroyed at Sashko's request
* Fixed spacing
Closes#6108
Pull request #6180
Test is included, as is updated documentation.
All tests in ddp-client package (including new test for #6108) pass.
Implemented as simply a noRetry flag on apply which triggers it to fail with a
Meteor.Error('invocation-failed') instead of retrying on reconnect.
Test passes, methods which are marked as noRetry get an error in case of reset,
only if they've sent at least once, and this happens before messageSent flag is
cleared. This results in it getting it's callback as soon as quiescence
triggers, and the callback is called with an Error 'invocation-failed'.
[stubailo: changed error code, fixed docs, squashed commits]
1. Add `addAssets` API to `package.js`
2. Rename `getSourcesFunc` to `getFiles` in internal code
3. Changed `PackageAPI#sources` to `PackageAPI#files` with a new structure that
has separate objects for assets and sources
4. Added some tests for different error conditions
5. The same file can now be a source and an asset
Since we have added additional constraints to the database around case
sensitivity, we now want to discourage people from working with the Accounts
collection directly and provide an API for changing certain fields in a correct
way.
Methods that do database checks before and after the operation:
Accounts.setUsername
Accounts.addEmail
Accounts.removeEmail
Methods that make sure to use a case-insensitive query to retrieve the user
Accounts.findUserByUsername
Accounts.findUserByEmail
PR #5024
Closes#550.
`loginWithPassword` now matches username or email in a case insensitive manner.
If there are multiple users with a username or email only differing in case, a
case sensitive match is required.
Although `createUser` won't let you create users with ambiguous usernames or
emails, this could happen with existing databases or if you modify the users
collection directly.
Because MongoDB does not support case insensitive indexes, we perform a case
insensitive query both before and after inserting a new user, removing the user
when we detect another matching user has been inserted in the meantime. This
leaves us with the theoretical possibility that a server crash could occur in
between the insert and the second query or remove. In that situation there
would be two accounts with a username or email only differing in case, so we
will require a case sensitive login.
A possible pitfall when configuring OAuth is that after proxying the Meteor application behind (for instance) nginx, the ROOT_URL doesn't match the hostname/port combination expected.
