Предварительное одобрение новых пользователей при отключенном локальном входе

Поддержка
1

У нас есть приватный сайт, где:

  • Локальный вход отключён (настроены вход через Facebook и Google)
  • Все новые учётные записи пользователей должны быть одобрены сотрудниками

У нас есть большая почтовая рассылка, и мы хотели бы «заранее одобрить» все адреса электронной почты из этого списка. Если человек заходит на сайт и пытается зарегистрироваться или войти с помощью учётной записи Facebook или Google, связанной с адресом из нашего списка предварительного одобрения, ему не нужно ждать одобрения со стороны сотрудника, и он может сразу начать пользоваться сайтом.

В идеале мы также хотели бы иметь возможность заранее настроить членство в группах для каждого адреса электронной почты.

Возможно ли это? Приветствуются решения, требующие использования API Discourse.

2

Боюсь, это совсем не сработает!
В первую очередь потому, что приглашения не работают без включенного локального входа. Так что, скорее всего, вам понадобится очень кастомный плагин, который будет обрабатывать всё это, или внешняя система аутентификации, чтобы удовлетворить ваши требования.

3

Добро пожаловать, Стив!

Я думаю, что если вы импортируете адреса с помощью скрипта импорта, всё сработает как надо. Только убедитесь, что эти пользователи не помечены как активные, иначе вы рискуете завалить их уведомлениями и сводками.

Это должно быть довольно просто сделать через консоль. Если вы размещены где-то в сети, это также можно сделать через API.

Что означает «Large»?

4

“Большой” означает около 5000 — достаточно, чтобы мы не хотели вводить это вручную в интерфейсе.

@pfaffman, не могли бы вы немного прояснить, как создавать пользователей через API? Похоже, что поле ‘password’ обязательно при создании пользователей, что, как я предполагаю, невозможно, если локальный вход отключен: POST /users

Чтобы немного расширить описание сценария использования для тех, кто может рассматривать что-то подобное: мы хотим побудить пользователей входить в систему через социальные аккаунты — многие из тех, кого мы пытаемся вовлечь в Discourse, не обладают техническими навыками, и мы хотим, чтобы они знали, что им не нужно запоминать ещё одно имя пользователя и пароль.

Однако текущая функция приглашения по электронной почте в Discourse требует от пользователя выбора пароля, что противоречит нашей цели упрощения процесса для наших пользователей.

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

Спасибо всем! Я очень рад возможности привлечь больше людей к использованию Discourse.

5

Возможность не создавать пароль и требование сообщить, какой адрес электронной почты используется для входа через социальные сети, — это совсем не то же самое. Они всё равно могут обойтись без пароля, если используют вход через социальные сети. Я часто отказываюсь входить через свой аккаунт Gmail (хотя сейчас это происходит реже), а моя жена почти всегда отказывается. Кроме того, вход по электронной почте очень удобен и означает, что пароль вам вообще не нужен. Но я отвлекся.

Если API требует пароль, просто сгенерируйте случайный. Наличие пароля, который вы не знаете и который вам не нужен, практически равносильно отсутствию пароля.

В какой-то момент я создал GitHub - pfaffman/discourse-user-creator: Create an activated user, optionally assigning to group · GitHub; я не гарантирую, что он работает, но он должен помочь вам приблизиться к решению. Вам нужно создавать неактивированных пользователей, поэтому вам потребуется его модифицировать, но должно быть довольно понятно, что нужно удалить. (Если вы просто хотите решить проблему и у вас есть бюджет, пожалуйста, не стесняйтесь связаться со мной.)

6

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

Я посмотрел на пример кода, спасибо! Для справки: мне пришлось использовать этот обходной путь, чтобы выполнить соответствующие вызовы API: Using the API to create a user on an SSO only system - #13 by DylannCordel. Тем не менее, я не думаю, что это соответствует сценарию, который я имел в виду, поскольку это вызывает отправку пользователю письма для активации, чего я надеялся избежать в пользу бесшовного опыта «просто работает», если/когда они в конечном итоге войдут на сайт.

Я также немного поэкспериментировал с этим решением: How to manually add user in discourse? - #10. Думаю, с его помощью можно было бы внедрить учетные записи пользователей, которые должны существовать, но в конечном итоге я не уверен, что стоит рисковать, напрямую изменяя среду внутри контейнера для внесения этих изменений.

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

Спасибо всем!

7

Вы немного путаете несколько разных вещей.

  • Социальные логины обходят пароль, так как аутентификация обрабатывается Facebook, Twitter, Google и другими.

  • Пригласительные ссылки делают пароль временнó необязательным, но вам нужно снова перейти по ссылке-приглашению, чтобы «войти». Я полагаю, мы настолько ужесточили эту функцию, что она фактически больше не работает. После этого вам придётся запросить сброс пароля через email, чтобы войти, что требует установки пароля.

Это долгая история, но пригласительные ссылки созданы для того, чтобы быстро и без лишних хлопот привлечь людей и начать общение, однако они НЕ предназначены для того, чтобы позволять пользователям никогда не устанавливать пароль.

8

Пока это работает следующим образом:

  1. Отправить пользователю приглашение по электронной почте (для этого должна быть включена локальная авторизация).
  2. Когда пользователь перейдёт по ссылке из приглашения, он может оставить поле пароля пустым и сразу войти в систему.
  3. При следующем посещении сайта, когда потребуется вход, он сможет авторизоваться через социальный аккаунт, привязанный к этому адресу электронной почты.

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

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

9

Этот путь приемлем, но имейте в виду, что отсутствие пароля является временной мерой по причинам, указанным ранее.

Таким образом, пользователю в любом случае потребуется выполнить «какое-то действие», и не существует постоянного состояния, при котором пароль вообще не требуется.

10

Логично. В конечном итоге пользователю нужно будет создать пароль или привязать свою учетную запись в социальной сети. Спасибо!

11

Если вас устраивает вход по электронной почте (или через социальные сети), вам никогда не понадобится пароль.