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.
Resolves these conflicts:
meteor
scripts/dev-bundle-server-package.js
scripts/dev-bundle-tool-package.js
tools/files.js
This requires building a new dev bundle, and moving the wrapCallSite
thing to source-map-retriever-stack.js.
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.
I think it is important to stress that you can use Template.currentData
inside template.autorun, because you cannot use it inside
Tracker.autorun, it throws an error that current view does not exist.
This simply adds an extra note to the 'writing packages' section of the docs which states that you should `meteor add` an internal package to enable it. I ran into this issue and banged my head for a while last night wondering why an internal package was not exposing a template / exported object to the rest of my app. The issue was that I did not `meteor add` it since I assumed that because it was internal source code I did not have to.