Метеор: нужен простой подход для администратора CRM

Question

Я пытаюсь создать способ для администрирования набора страниц CRM администратора, которые контролируют приложение Meteor, над которым я работаю. В одном проекте есть только одна база кода, с сервером, лицом, обращенным к клиенту, и администратором.

Мне нужна страница входа, в которой можно проверить пару имени пользователя и пароля, а также простой способ проверить статус пользователя как на стороне клиента, так и на стороне сервера. Мне также нужен способ авторизации тайм-аута администратора, если он не использовался в течение x минут.

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

Любые рекомендации по пакету или подходу, которые я мог бы использовать для его реализации?

Answer 1

Я знаю, что вы сказали, что учетные записи: пакет паролей казался немного «излишним», но на самом деле это действительно так. То, что вы получаете, это подключаемый интерфейс (через учетные записи - ui и другие пакеты, которые его строят). Подход, который я принял, - это (что хорошо работает даже для приложений, поддерживающих несколько пользователей, поскольку в конечном итоге вам все равно нужно загружать стартовых пользователей).

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

Далее вам необходимо загрузить ремень пользователя (ов). Где-то в вашей папке /server вы будете делать что-то вроде:

if (Meteor.users.find({}).count() == 0) { 
    // No users created...create default users 
    Accounts.createUser({ 
    username: 'myuser', 
    email: 'myuser@mydomain.com', 
    password: 'myp4ssw0rd!', 
    profile: { profileProp: 'propVal` } 
    }); 
    // Add new user to whatever roles needed 
} 

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

После того, как вы создали своих пользователей и роли, необходимо проверить/проверить пользователя/роли в вашем приложении. Для пунктов меню вы можете отображать/скрывать вещи на основе того, был ли пользователь зарегистрирован и/или имеет определенную роль, и вы также должны проверить на маршрутах приложений, для которых требуются ACL, например, ваш маршрут администратора. Кроме того, используйте идентификатор пользователя во всех ваших публикациях, а также для ограничения данных, которые могут видеть ваши пользователи. Не полагайтесь только на скрытие опции меню ... безопасность через неизвестность просто не работает.

Почему я предлагаю сделать это таким образом? Во-первых, это не так много кода. Вы могли бы буквально сделать это, вероятно, в 20 строках, максимум и иметь полную настройку аутентификации. И преимущество этих строк кода значительно перевешивает 30-минутные вершины, которые вам потребуются, так как теперь у вас будет «реальная» аутентификация пользователя в вашем приложении и есть возможность делать такие вещи, как OAuth, если вы когда-нибудь решите в будущем. Самое главное, что вы разблокируете плагины для предварительного создания UI, которые вам не нужны для программирования, встроенных и дополнительных методов для проверки ACL, возможности блокировки данных пользователем, и вам не нужно пытаться реализовать свое собственное решение.