Отключение требования об активации по электронной почте для приглашенных пользователей

Разработка
1

Всем привет! У меня есть сценарий использования, который сейчас поддерживается не очень хорошо: мне нужно отключить email с активацией для приглашённых пользователей — включая пользователей, приглашённых по ссылке.

После того как я создал тему выше, это было реализовано, но только для пользователей, приглашённых по email.

Мой экземпляр Discourse работает только по приглашениям, и я действительно отправляю ссылки-приглашения по email, но не используя встроенную рассылку Discourse. Я генерирую ссылки-приглашения через POST-запрос к /invites/link, сохраняю их во внешней БД, а оттуда отправляю ссылки пользователям. Таким образом, когда пользователи переходят по ссылке, они уже фактически подтвердили свой email, но затем их просят сделать это ещё раз.

Я понимаю, что мой сценарий не особенно распространён, поэтому решил попробовать создать простой плагин, чтобы изменить необходимые части Discourse и заставить всё работать так, как мне нужно.

У меня уже есть набросок, запущенный и работающий, и я добавил настройку сайта (no_activation_enabled). После поиска по основному репозиторию я предположил, что, возможно, редактировать нужно этот файл:

Я не до конца уверен, но, кажется, что условное (если SiteSetting.no_activation_enabled и если пользователя пригласил сотрудник, возможно, invite.invited_by.staff?) изменение active на true в user.attributes могло бы сработать:

    user.attributes = {
      email: invite.email,
      username: available_username,
      name: name || available_username,
      active: false,
      trust_level: SiteSetting.default_invitee_trust_level,
      ip_address: ip_address,
      registration_ip_address: ip_address
    }

Но как мне изменить это из плагина? Входит ли это вообще в возможности плагинов? Или они могут только добавлять что-то, но не изменять? Или мне нужно заменить весь файл invite_redeemer.rb?

Я прошёл введение по созданию плагинов, а также это руководство, но после часов попыток разобраться в коде, включая изучение других плагинов, я чувствую, что бьюсь головой о стену… Так что, если у кого-то есть советы для меня, буду очень благодарен!

2

Если вы обрабатываете это с внешнего сайта, почему бы не доверить ему SSO и просто передать подтверждение в полезной нагрузке?

3

Привет, Стивен, спасибо за твой вклад.

Я не управляю учетными записями пользователей на внешнем сайте. У меня есть мастер-система на базе Airtable + Zapier + GCF, которая связывает несколько сервисов (ESP и др.), но Discourse является основной базой данных пользователей. Я просто не хочу использовать обычную форму регистрации Discourse, так как она не очень эффективна для конверсии и не может быть интегрирована, например, в сообщения блога. В любом случае, Discourse выступает провайдером SSO для сайта на Jekyll: он отправляет fetch-запросы, чтобы проверить, авторизован ли пользователь в Discourse, и на основе этого адаптирует страницы с контентом.

4

Привет, добро пожаловать :slight_smile:

Как и @Stephen, я не до конца уверен, что это правильный инструмент, но я доверяю, что вы всё обдумали достаточно тщательно.

Я бы избегал этого любой ценой. Почти всегда существует другое решение, даже если вам придётся использовать monkey patch для класса. О monkey patch в Discourse читайте здесь: Override existing Discourse methods in plugins.

В данном случае, похоже, что в методе, на который вы обращаете внимание, уже есть код, делающий то, что вам нужно: discourse/app/models/invite_redeemer.rb at main · discourse/discourse · GitHub

Проблема в том, что сгенерированные вами приглашения не имеют правильного emailed_status_type, поэтому условие не выполняется. Я думаю, решение здесь — с самого начала генерировать другие приглашения. Именно на этом я бы сосредоточился.

5

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

Именно поэтому код для работы с этим уже существует, но для его использования потребуется некоторая кастомизация.