При массовом добавлении пользователей в группу через интерфейс, описанный здесь, если адрес электронной почты в списке входных данных еще не существует в системе Discourse, отправляется приглашение по электронной почте.
Если вы перейдете по ссылке, вас перенаправит на страницу создания учетной записи внутри Discourse:
Если вы заполните форму, будет создана учетная запись. У созданной учетной записи нет информации об SSO.
Причина, по которой это является проблемой, очевидна:
Обход нашей системы аутентификации SSO — это очень плохо.
Без предупреждения о том, что «X человек получат письмо по электронной почте», я случайно рассылал спам, так как не осознавал, что сообщения отправляются.
Ожидаемое поведение:
При массовом добавлении в группу, если включен SSO, игнорировать любые адреса электронной почты, которых еще нет на сайте.
Спасибо за сообщение об этой проблеме. Я могу воспроизвести её на своём тестовом сайте. Когда включен SSO, любые email-адреса, которых еще нет на сайте, должны игнорироваться при добавлении в группу. Мы исправим это. Извините за доставленные неудобства.
@Grayden_Shand На самом деле мы сейчас рассматриваем возможность добавления аутентификации через SSO на странице активации приглашений. При активации приглашения пользователю придется пройти аутентификацию через SSO вместо заполнения формы регистрации. Подходит ли это для вашего сценария?
@sam Я обдумываю процесс приглашений, и один момент, в котором я не уверен: должен ли адрес электронной почты, на который было отправлено приглашение, совпадать с адресом SSO? Кажется, что мы могли бы требовать этого для приглашений по электронной почте, но не для приглашений по ссылке. Как вы считаете?
Для нашего сценария было бы гораздо лучше полностью отключить отправку писем с приглашениями. Для большинства наших сайтов (временных сообществ для онлайн-курсов) существует ограниченное окно для регистрации (и взимается плата). Поэтому я представляю, как расстроится человек, получивший приглашение на сайт, а затем пришедший и увидевший, что присоединиться уже нельзя. Нет ни одной ситуации, в которой мы хотели бы, чтобы кто-то получал приглашение на один из наших сайтов.
Если вы всё же решите реализовать это, я бы попросил также добавить предупреждение примерно следующего содержания: «Вы собираетесь отправить письма XX пользователям, которые не являются пользователями вашего сайта: bob@example.com, alice@example.com, …». Тогда мы сможем найти этих пользователей и удалить их из списка массового добавления.
Могли бы вы в таком случае использовать ссылки-приглашения для вашего сценария? Так вы сможете избежать рассылки писем и установить срок действия ссылки.
Я всё ещё поддерживаю «ниндзя-режим», позволяющий обойти отправку писем, чтобы вы могли добавить большое количество адресов в белый список, но мне интересно, решает ли функция ссылок-приглашений вашу задачу.
Я так не думаю, но, возможно, я неправильно понял вопрос. Позвольте мне объяснить, как мы используем Discourse, функцию SSO и почему изначально столкнулись с этой ошибкой.
Мы работаем над платформой электронного обучения, которая использует временный форум Discourse для каждой сессии каждого семинара (курса).
Мы используем SSO с собственной системой аутентификации по двум причинам:
Чтобы пользователю нужно было создать только один набор учетных данных для доступа к любому курсу, на который он зарегистрирован.
Чтобы применять политики доступа к каждому форуму на основе произвольных данных в нашей базе данных. Например, в нашей конечной точке SSO для Discourse мы проверяем, что у пользователя есть действительная регистрация и что дата находится в пределах наших дат открытия и закрытия.
Я столкнулся с этой ошибкой, когда мы хотели создать группу только для участников одного семинара, которые состояли в другом (например, группу выпускников). Поэтому я добавил полный список класса из другого семинара в модальное окно массового добавления и случайно отправил приглашения всем в этом списке, кто не зарегистрировался на текущий семинар.
Таким образом, мы на самом деле никогда не будем использовать функцию приглашений в Discourse (будь то через ссылку или по электронной почте). Если бы нам всё же понадобилась функция приглашений, нам, вероятно, пришлось бы реализовать её самостоятельно, поскольку нам нужно было бы наложить определённую бизнес-логику на любые отправляемые приглашения. Например, если период регистрации на семинар закрыт, мы хотели бы отображать сообщение об ошибке на ссылке. Или, возможно, мы хотели бы включить скидку в ссылку.
Всё это к тому, что всё работает, если нам не приходится использовать эту функцию, но нам очень не хотелось бы беспокоиться о том, чтобы случайно отправлять письма людям без аккаунта в этом форуме Discourse.
