Re: Централизованное хранение профилей и их синхронизация
От: Sharov Россия  
Дата: 14.04.16 14:15
Оценка: 3 (1)
Здравствуйте, vers, Вы писали:

V>Есть несколько веб-приложений, каждое приложение расположено на отдельном субдомене одного и того же домена второго уровня (site.com). Нужно реализовать сквозную аутентификацию пользователей: если пользователь вошел на одном из сайтов, ему не нужно входить на всех остальных (наподобие того, как это сделано у Яндекса или Гугла, например).

V>Было решено вынести работу с учетными записями и профилями на отдельный (центральный) сайт: если пользователь нажимает кнопку "Войти" на sub.site.com, его редиректит на site.com, после аутентификации site.com устанавливает cookie (которая доступна всем субдоменам site.com) и редиректит пользователя обратно.
V>Проблема в том, что в некоторых приложениях отображаются данные из профилей пользователей: например, имя пользователя рядом с его комментарием (до 1000 комментариев на странице). Поскольку пользователь редактирует свое имя на site.com, то приложение на sub.site.com ничего об этом не знает и продолжает отображать прежнее (закэшированное) имя. Я сейчас хожу и думаю, как бы реализовать синхронизацию этих данных, с архитектурной точки зрения.

V>Варианты, которые я пока придумал:


V>[list=1]

V>После редактирования профиля отправлять server-to-server запрос (например, REST или SOAP) от site.com на все субдомены.
V> Минусы: придется реализовать этот механизм во всех приложениях; это может снизить производительность редактирование профиля с точки зрения пользователя; проблемы, если какой-то из сайтов в этот момент офлайн.

Это не самый худший вариант, т.к. редактирование профиля не самая частая операция.

V>Делать периодический server-to-server pull-запрос от всех приложений к site.com для проверки на наличие изменений и синхронизации.

V> Минусы: раз периодический, это означает задержку в синхронизации и соответствующие жалобы пользователей: "Я поменял имя, а в комментарии оно не обновилось".

Это, кмк, вообще бред.

V>Почитать про репликацию БД (MS SQL). Посмотреть, поможет ли.

V> Минусы: никогда не делал репликацию БД. Даже не знаю, помогает ли она в этом случае.

Почитать всегда полезно, но как это поможет в Вашем случае я Мож MS SQL умеет как-то реплицировать отдельные таблицы, если в них были изменения.

V>Есть ли какие-то еще варианты?


V>PS. Если ничего не понятно из того, что я написал, то вот простая аналогия: аутентификация на сайте через OAuth, например, через ВКонтакте: сайт достает имя аутентифицировавшегося пользователя и отображает его рядом с его комментариями на сайте -> через день пользователь меняет свое имя во Вконтакте, но сайт об этом ничего не знает и продолжает отображать старое имя. Отличие моей ситуации в том, что центральный сайт с профилями (ВКонтакте в этом примере) разрабатываю тоже я, поэтому могу сделать в нем все, что хочу.


Вообще говоря, один update должен все сделать. Т.е. при построении страницы данные из базы считываются, соотв. задача в консистентном обновлении баз(ы). Я думаю MS SQL это умеет. На прикладном уровне городить ничего не следует. Только работа с базой данных. Ну т.е., если пользователь увидел свой старый ник в комментариях, то F5 должно ситуацию исправилть.
Кодом людям нужно помогать!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.