Здравствуйте!
Мы отправляем приглашение в Discourse нашим пользователям сразу после того, как они создают учётную запись в нашем приложении. У нас уже есть их имя и необходимые для нашего сообщества пользовательские поля, но пользователю приходится вводить их заново в Discourse.
Существует ли возможность автоматически заполнять эти поля в их профиле?
Спасибо!
Я думаю, что лучше всего, чтобы ваше приложение выступало в роли SSO-сервера. Если вы не хотите этого, то ваше приложение может создавать пользователя через API и включать соответствующие настройки. Вы можете узнать, как это сделать, в статье Как провести реверс-инжиниринг API Discourse.
Мы не хотим создавать пользователей через API, так как хотим, чтобы пользователь сам создал пароль и выбрал имя пользователя. Я рассматривал возможность создания пользователя на промежуточном этапе со всеми данными, но, похоже, это невозможно сделать через API.
Другой вариант, который я могу предложить, — расширить функционал приглашений, чтобы добавить возможность использования пользовательских полей и информации профиля.
Возможно, стоит использовать плагин, который получает данные из вашего приложения через вебхук или вызов API? Например, плагин может выполнять запрос типа get yoursite/user/<email_address> и заполнять поля пользователя при обновлении записи. Что-то в этом роде. SSO всё ещё кажется лучшим решением.
Да, пожалуйста, ознакомьтесь с Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso). Это именно тот случай для использования единого входа (SSO).
При использовании SSO вам не потребуется приглашать пользователей. Они просто зайдут на ваш экземпляр Discourse и автоматически войдут в систему, если уже авторизованы в вашем приложении. Если они ещё не вошли в ваше приложение, Discourse перенаправит их туда для входа, а затем автоматически вернёт обратно в Discourse.
Дело в том, что мы используем Discourse в качестве провайдера SSO, и это хорошо работает для нас, но да, я согласен, что это было бы проще, если бы Discourse сам использовал провайдера SSO.
@blake Я всё ещё думаю, как мы можем это сделать, так как в качестве нашего провайдера SSO используется Discourse. В данный момент я не хочу мигрировать на что-то другое, так как это потребует гораздо больше работы. У тебя есть другие идеи? Если придётся написать собственный код, это не проблема, но мы хотим внести минимальное количество изменений в текущую настройку.
Спасибо!
Я просто запутался в вашей настройке и этих двух предложениях, потому что тогда у вас получается не единый вход (Single Sign-On), а двойной вход?
Если бы Discourse был вашим провайдером SSO, новые пользователи вашего приложения должны были бы сначала перенаправляться в Discourse для создания аккаунта, а затем возвращаться обратно в приложение после аутентификации. Тогда вся информация хранилась бы в одном месте.
Исходя из моего текущего понимания, я бы превратил ваше приложение в провайдера SSO, чтобы Discourse использовал его. Или перенаправлял бы пользователей вашего приложения на регистрацию сначала в Discourse, а затем возвращал бы их обратно в приложение, поскольку, похоже, сейчас всё настроено иначе?
Или, если вы хотите иметь настройку с двойным входом, то после регистрации в вашем приложении автоматически создавайте им аккаунт в Discourse через API со случайным паролем, который вы никогда не передадите пользователю, и автоматически заполняйте их профиль данными, которые они указали в вашем приложении. Затем перенаправляйте их на страницу сброса пароля в Discourse для нового аккаунта, вместо того чтобы отправлять им приглашение.
Мы проводим регистрацию через наше приложение, но наше приложение не управляет сессиями. Мы просто взимаем плату с пользователя и сохраняем его информацию в нашей базе данных.
Нам потребуется заставить пользователя сначала создать аккаунт, и мы как раз хотим убрать этот шаг, потому что хотим сделать процесс максимально простым.
На это мы не хотим идти, потому что добавление управления сессиями, восстановления пароля, двухфакторной аутентификации и всех функций, которые предоставляет Discourse, потребует огромной работы.
Это не то, чего мы хотим.
Именно это я изначально и сделал, но нам пришлось задавать случайное имя пользователя, а это не то, чего мы хотим. Хотя это будет работать, мы хотим, чтобы пользователь мог персонализировать свой аккаунт перед началом использования сообщества.
Но да, я полагаю, ответ всё тот же — использовать внешнего провайдера SSO. Я пойду по этому пути и перестану думать о том, как заставить Discourse работать так, как мы хотим.
Спасибо за помощь, @blake!
Или отказаться от своего приложения и позволить Discourse Subscriptions заниматься финансами?