meteor
Аккаунты пользователей Meteor

Пакет счетов Meteor

У вас есть несколько вариантов, когда дело доходит до входа в Meteor. Самый распространенный метод - использование accounts для Meteor.

Счета-пароль

Если вы хотите, чтобы пользователи могли создавать и регистрироваться на вашем сайте, вы можете использовать accounts-password .

Установите пакет, используя meteor add accounts-password .

Чтобы создать пользователя, вам необходимо использовать Accounts.createUser(options, [callback])

options должны быть объектом со следующими свойствами:

• username : username пользователя пользователя в виде строки.
• email : email пользователя в виде строки.
• password : password пользователя (не зашифрованный) как строка.
• profile : дополнительные данные пользователя как объект. Это может быть, например, имя пользователя и фамилия пользователя. profile является обязательным.

Обратный вызов возвращает 1 переменную, если есть ошибка, которая является объектом Meteor.Error.

Вам нужно только использовать username или email , чтобы вы могли создать пользователя с именем пользователя, но не с адресом электронной почты, и наоборот. Вы также можете использовать оба варианта.

Он возвращает вновь созданный идентификатор пользователя, если все прошло правильно.

Таким образом, вы можете, например, использовать это:

// server side
var id = Accounts.createUser({
    username: "JohnDoe",
    email: "[email protected]",
    password: "TheRealJohn123",
    profile: {
        firstName: "John",
        lastName: "Doe"
    }
}, function(err) {
    console.log(err.reason);
});

Он также автоматически войдет в систему, если пользователь будет успешно создан.

Это создающая часть. Для входа в систему вам необходимо использовать Meteor.loginWithPassword(identifier, password, [callback]) на стороне клиента.

identifier - это username , email или userId в виде строки от пользователя. password - это (не зашифрованный) password пользователя.

Обратный вызов возвращает одну переменную, если есть ошибка, которая является объектом Meteor.Error.

Пример:

// client side
Meteor.loginWithPassword("JohnDoe", "TheRealJohn123", function(err) {
    console.log(err.reason);
});

И это для базового создания учетных записей и входа в систему.

Доступ к пользовательским данным

Вы можете проверить на стороне клиента, если пользователь вошел в систему, вызвав Meteor.userId() который вернет свой userId если они вошли в систему, и undefined если они не вошли в систему.

Вы можете получить некоторую информацию от Meteor.user() . Он будет возвращен undefined, если пользователь не войдет в систему, и некоторые данные пользователя, если они есть. По умолчанию он не даст вам никаких паролей, по умолчанию он покажет userId пользователя, имя пользователя и объект профиля.

Если вы хотите проверить, зарегистрирован ли пользователь на странице, вы также можете использовать помощник currentUser . Он вернет содержимое Meteor.user() . Пример:

{{#if currentUser}}
    <h1>Hello there, {{currentUser.username}}!</h1>
{{else}}
    <h1>Please log in.</h1>
{{/if}}

Другие функции учетной записи

Существуют и другие функции, которые работают для каждого пакета учетных записей.

Вы можете выйти из системы с помощью Meteor.logout()

Не используйте поле профиля по умолчанию

Существует соблазн существующего поля, называемого profile который добавляется по умолчанию, когда регистрируется новый пользователь. Это поле исторически предназначалось для использования в качестве царапины для пользовательских данных - возможно, их аватар изображения, имя, вводный текст и т. Д. Из-за этого поле profile для каждого пользователя автоматически записывается этим пользователем с клиента . Он также автоматически публикуется клиенту для этого конкретного пользователя.

Оказывается, что наличие поля, доступного по умолчанию, не делая этого супер очевидного, может быть не лучшей идеей. Есть много историй о новых разработчиках Meteor, хранящих такие поля, как isAdmin on profile ..., а затем злоумышленник может легко установить это значение true, когда захочет, сделав себя администратором. Даже если вас это не беспокоит, не рекомендуется позволять злонамеренным пользователям хранить произвольные объемы данных в вашей базе данных.

Вместо того, чтобы иметь дело со спецификой этого поля, может быть полезно просто полностью игнорировать его существование. Это можно сделать безопасно, если вы отказываетесь от всех писем от клиента:

// Deny all client-side updates to user documents
Meteor.users.deny({
  update() { return true; }
});

Даже игнорируя последствия для профиля безопасности, не рекомендуется включать все пользовательские данные вашего приложения в одно поле. Протокол передачи данных Метеор не делает глубоко вложенных различий полей, поэтому неплохо сгладить ваши объекты во многих областях верхнего уровня документа.