Использовать отдельный сервер для базы данных централизованных пользователей - PullRequest
0 голосов
/ 04 апреля 2020

Я использую Meteor 1.10 + mongodb.

У меня есть несколько мобильных чатов и информационных приложений.

Эти мобильные приложения изначально разработаны с использованием библиотек Meteor DDP.

Но У меня одна база пользователей для всех приложений.

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

Мне нужны предложения о том, как мне достичь эта архитектура с метеором.

Помня о реактивности и производительности.

Ответы [ 2 ]

0 голосов
/ 24 апреля 2020

Итак, наконец-то у меня есть работа. Возможно, это не идеальный способ справиться с этим, но, насколько мне известно, это сработало для меня так хорошо. Но да, я все еще открыт для предложений.

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

Поэтому я решил создать SSO (централизованный сервер для управления базой данных пользователей)

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

Теперь эти 4 подключающихся приложения разработаны с использованием Meteor.

Основной задачей здесь было сделать вещи реактивными. / в режиме реального времени. Например, чат / обмен сообщениями, создание групп, отображение списка пользователей и слушателей для вновь зарегистрированных пользователей.

Таким образом, в этом сценарии база данных пользователей находилась на другом удаленном сервере (SSO), поэтому при подключении приложения я не мог просто:

Meteor.publish("getUsers")

Поэтому при подключении приложений я решил создать временную коллекцию под названием:

UserReactiveCollection

со следующей структурой:

UserReactiveCollection.{
    _id: 1,
    userId: '2',
    createdAt: new Date()
}

И я опубликовал подписку:

Meteor.publish("subscribeNewUserSso", function () {

    return UserReactiveCollection.find({});
});

Итак, для обновления UserReactiveCollection я выставил Rest Api на каждом подключаемом приложении соответственно. Эти API получают данные от SSO и обновляются в UserReactiveCollection.

Так что на стороне SSO, когда когда-либо регистрируется новый пользователь. Я пингую эти Apis (при подключении приложений) и отправляю вставленный userId в полезную нагрузку.

Итак, теперь эти подключающиеся приложения получают onDataChanged ping из подписки и получают userId.

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

Вот как я все это заработал, поэтому пока я просто отмечаю свой ответ принятым, но как Я упомянул выше, что: «Возможно, это не идеальный способ справиться с этим, но, насколько мне известно, это сработало для меня так хорошо. Но да, я все еще открыт для предложений».

И отдельное спасибо @Jankapunkt за помощь.

0 голосов
/ 06 апреля 2020

Для централизованной пользовательской базы с полной реактивной функциональностью вам необходим Сервер авторизации, который будет использоваться вашими приложениями (= Ресурс-серверы), чтобы разрешить аутентифицированный / авторизованный запрос. По сути, это трехуровневый рабочий процесс OAuth2.

См .:

https://tools.ietf.org/html/rfc6749

https://www.oauth.com/

Служба входа в систему

Вы также должны будете написать свой собственный обработчик входа (Meteor.loginWithMyCustomAuthServer), чтобы избежать DDP.connect, потому что тогда вам придется управлять две пользовательские базы (одна для самого приложения и одна для сервера авторизации), и это будет очень грязно.

Этот обработчик входа в систему затем извлекает данные учетной записи пользователя после успешного выполнения запроса авторизации Oauth2, что сделает базу пользователей Сервера авторизации единой точкой правды для любого зарегистрированного приложения (см. рабочий процесс Oauth2 о clientId и secret).

Подписка на пользователей

Сервер аутентификации - это единственная точка истины, где вы создаете, обновляете или удаляете своих пользователей там и при успешном входе в систему ваше локальное приложение будет всегда получать последнюю версию пользовательские данные синхронизируются с этим аккаунтом A Сервер (это то, как Meteor делает это и с loginWith<Service>)

Затем вы подписываетесь на своих пользователей на само приложение без какого-либо удаленного соединения ddp. Это, конечно, работает только в том случае, если пользовательские данные, которые вы хотите получить, действительно предназначены для онлайн-пользователей.

Если вы хотите подписаться на любого пользователя (где данные, возможно, еще не синхронизированы), вам все равно нужна удаленная подписка к публикации на сервере Authorizazion.

Обратите внимание, что для аутентификации пользователей с этой удаленной подпиской вам требуется аутентифицированный запрос DDP (который также поддерживается пакетами ниже).

Реализация

Предупреждение - следующее - это реализация, сделанная мной. Это связано с тем, что я столкнулся с той же проблемой и не нашел никакой другой реализации до моей.

Работает полноценный сервер учетных записей (но постоянно в работе)

https://github.com/leaonline/leaonline-accounts

он использует Oauth2 nodejs реализацию , которая была обернута в пакет Meteor:

https://github.com/leaonline/oauth2-server

и соответствующий обработчик входа также был создан:

https://github.com/leaonline/meteor-accounts-lea

...