Когда Discourse выступает в роли провайдера идентификации, сохраняет ли он внешние ID пользователей?

Спасибо, @david. Как ни странно, я сделал именно это для ссылок в обратном направлении (из профилей пользователей моего Rails-приложения в профили пользователей Discourse) с помощью этого плагина Discourse (/user-by-id/123/summary), так как мое Rails-приложение хранит ID пользователя Discourse вместо имени пользователя (поскольку имена пользователей могут меняться).

Это решение могло бы сработать и в обратном направлении, за исключением того факта, что не у всех пользователей форума есть профили пользователей в моем Rails-приложении. Пользователь Rails создается только тогда, когда пользователь Discourse «вступает» в организацию, тогда как форум Discourse может содержать и не-участников.

Так что, полагаю, у меня есть два варианта:

A) Создать JavaScript-плагин, который отправляет AJAX-запрос в мое Rails-приложение, чтобы определить, является ли пользователь Discourse также пользователем Rails-приложения, и если да, то отобразить ссылку; или

B) В момент создания пользователя Rails-приложения и его привязки к пользователю Discourse, помимо хранения ID пользователя Discourse в базе данных Rails-приложения, каким-то образом сохранить ID пользователя Rails в профиле пользователя Discourse (например, как пользовательское поле).

Мне кажется, что вариант (B) — лучшее решение (при условии, что пользовательское поле нельзя изменить, кроме как администраторам), хотя я не знаком с пользовательскими полями или тем, доступны ли они через API.

РЕДАКТИРОВАНИЕ: Теперь я вспомнил, что выяснял это в прошлый раз: проблема в том, что пользовательские поля могут редактироваться самим пользователем, что делает их плохим местом для хранения системной ссылки, сгенерированной автоматически :confused: