field (eg, to refresh access tokens) but does *not* update anything else (which
is effectively a no-op change because in practice the only thing that it
attempted to update was "profile" but because existing fields were not
overridden, this never did anything).
Remove the "extra" argument from createUser and related functions. Add a new
"profile" option to the main options dictionary, interpreted by
defaultCreateUserHook.
Rely solely on indices (with some icky error parsing) to generate "user/email
already exists" errors.
Not yet making the ensureIndex API public. Not indexing the tiny
loginServiceConfiguration collection. Indexing tinytest_results.
Previously, if we did a Mongo write inside a method and Mongo returned an error
(eg, duplicate key in a unique index), the write fence would never fire and the
client would never quiesce. Now we make sure to fire the write fence (and mark
the collection dirty) even on error.
We no longer pass the requireEmail and requireUserame options in
Accounts.config (which means we also don't validate new users when
they are created -- that should probably be done with a server
analogue of .allow())
Instead, Accounts.ui.config can be passed a newUserWithPasswordHas
option with four distinct UI configurations.
modify with the default Meteor.users update allow rule.
This does mean that it's difficult for trusted server code calling
Accounts.createUser, even with a custom onCreateUser hook, to set values on the
new user that can't also be set by arbitrary clients. For now, server code
needing to do this can just set it with a post-create update; later we might add
another parameter to onCreateUser.
by an identical sub.
Previously, it would fail to subscribe. This confused the meteor.currentUser
subscription in accounts_client.js. Reproduction:
- Create user X with email (which sends a confirmation email)
- Log out.
- Log in as User Y in tab 1.
- Follow the confirmation link in tab 2. This leaves you logged in
as User Y.
- Tab 1's localstorage poller notices that there's a new token and logs in
with it.
- After a successful login, Accounts._makeClientLoggedIn unsubs from
meteor.currentUser and immediately resubs. It thinks there's already an
existing sub, so it doesn't send the sub message and does immediately call
the ready callback (which sets userLoaded() to true).
- The unsub gets sent and the object in Meteor.users() gets depopulated.
Now Meteor.userLoaded() is true but Meteor.user() is empty.
In the future we may support use of some of the sub-templates directly (eg, we
might expose a "sign in" template and a "create user" template, and keep the
events and links for switching between them on the outer loginButtons) but we
don't yet. This change leaves us open to change the internal details later.
- additional class on the element with class "login-link-and-dropdown-list"
with information about which of the three password flows we are in
- a wrapper element around each label/input pair in the password forms
- links to go back to the sign up flow from create account or forgot password
