После вопроса от @debryc здесь мы хотели бы кратко рассказать о проделанной работе по интеграции наших форумов Discourse с облачным хранилищем (экземпляр NextCloud) и чатом (в нашем случае — Mattermost).
Пост довольно длинный, поэтому подробности скрыты до тех пор, пока вы не нажмёте на стрелку…
Полный длинный пост
Сразу хочу подчеркнуть: я не разработчик этой системы — она была создана на C#/.NET другим членом технической команды, поэтому я не могу отвечать на детальные технические вопросы по ней. Я лишь излагаю проблему(ы), которую(ые) мы хотели решить, и то, что мы сделали.
Предыстория: Ранее мы использовали интегрированную систему (Basecamp) для обеспечения обсуждений, чата в реальном времени и интеграции хранилища файлов. В ней было много неудовлетворительных элементов как с точки зрения структуры, так и безопасности, поэтому мы решили мигрировать организацию на новые системы с открытым исходным кодом.
Мы провели множество исследований и оценок — некоторые наши решения были продиктованы необходимостью действовать быстро, другие — поиском наилучшего соответствия нашим требованиям, а третьи — потребностью сделать путь миграции для 10 000 пользователей максимально безболезненным (среди пользователей много нетехнических специалистов и значительное число людей, боящихся технологий, у всех свои устойчивые мнения — угодить всем непросто!)
В итоге мы остановились на трёх отдельных компонентах: Mattermost для чата в реальном времени, Discourse для более вдумчивых обсуждений и Nextcloud для безопасного хранения файлов и совместного редактирования (заменяя комбинацию встроенного хранилища Basecamp и Google Docs). Все они размещены на наших собственных управляемых серверах.
Теперь нам нужно было обеспечить способ бесшовной интеграции трёх необходимых систем входа, автоматически создавать учётные записи пользователей и назначать их в соответствующие группы доступа/форумы (Discourse), группы общего хранения (Nextcloud) и команды/каналы (Mattermost).
В организации есть несколько сотен отдельных групп/команд (по местоположению и функциям), и пользователи могут входить во многие из них — некоторые закрытые, некоторые открытые для присоединения любого пользователя.
Первой проблемой стало создание учётных записей пользователей в трёх системах и первоначальное обеспечение одинаковых имён пользователей (чтобы они могли узнавать друг друга) и паролей (чтобы иметь хотя бы один набор учётных данных для запоминания/хранения и, в конечном итоге, единый вход во все три системы).
Нам также требовался способ назначения людей в правильные группы при создании учётной записи — в старой системе не было хорошего соответствия между реальными группами и онлайн-группами, поэтому мы не могли просто мигрировать их.
Решение, которое мы нашли, — это отдельный веб-сайт под названием «Хаб», который отслеживает учётные записи пользователей и использует API трёх систем для создания и обновления данных о пользователях.
Хаб также позволял «техническим лидерам» каждой группы (или набора групп) приглашать людей в новые сервисы, тем самым гарантируя, что в каждом месте окажутся только нужные люди.
Таким образом, пользователь получает приглашение по электронной почте с одноразовой ссылкой на хаб, где может создать имя пользователя и пароль. Эти данные затем используются для автоматического создания соответствующих учётных записей в трёх отдельных сервисах.
Хаб также знает, к каким группам/форумам, командам/каналам и областям хранения у пользователя должен быть доступ, и добавляет его в соответствующие места через API.
По мере развития хаба в него были добавлены дополнительные функции: теперь пользователь может использовать его для поиска каналов и форумов, подачи заявок на вступление в них, а также выполнять различные административные функции как для технических лидеров, так и для обычных пользователей.
Теперь хаб также может обеспечивать форму единого входа: войдя в хаб, пользователь может войти в один из других сервисов одним нажатием кнопки. (Часть работы здесь заключалась в исключении стандартных корпоративных входов через социальные сети).
Мы рассматривали различные способы интеграции чата и обработки хранения файлов в одной системе (все три системы частично это позволяют), но всегда это влекло за собой огромные компромиссы, и в итоге получался «верблюд» (лошадь, спроектированная комитетом), как Basecamp. Лучше придерживаться специализированных решений для каждой из основных функций и делать их качественно.