Именно это я и имел в виду. Я добавлю ссылку на тему Category Group Review/Moderation, так как изначально мне было сложно найти её через поиск.
Я всегда с трудом нахожу Documentation в категории #announcements
Честно говоря, это, вероятно, хорошая идея в любом случае. У администраторов есть ВСЕ права (скачивание резервных копий, просмотр/изменение секретов конфигурации, доступ к персональным данным пользователей, доступ к личным сообщениям и т. д.), и лучше держать этот круг максимально узким.
Есть много возможностей для предоставления «высоких привилегий» без статуса полного администратора.
Спасибо вам обоим за это, я не знал, что это отдельная вещь!
Спасибо за это разъяснение, я не знал, что дело обстоит именно так. Вы правы, теперь, когда я это знаю, мы определённо ограничим это.
Я изучил лимиты и требования и передал эту информацию своей команде. К сожалению, похоже, что нам всё равно придётся использовать собственный хостинг. Предлагаемый вами бесплатный хостинг для FOSS-проектов очень щедрый, но мы просто не вписываемся в требования.
Основным ограничением являются лимиты на просмотр страниц. 50 тысяч просмотров в месяц, вероятно, более чем достаточно для большинства FOSS-проектов, но наш трафик значительно выше. Только за последние 7 дней наш основной сайт получил 1,87 млн запросов от 56,47 тысяч уникальных посетителей. Боюсь, что при таком темпе мы легко достигнем лимита просмотров страниц.
Тем не менее, спасибо, что обратили моё внимание на это!
Вероятно, стоит найти способ решения этой проблемы. Если вы знаете, какие пользователи на вашем сервере являются сотрудниками Discourse (администраторы или модераторы), возможно, стоит установить поле SSO «Электронная почта» для этих пользователей в их реальные адреса. Все дублирующиеся учетные записи с одинаковыми адресами получат вымышленный адрес электронной почты.
Есть несколько случаев, когда возможность получения сотрудниками писем от Discourse полезна. Первый из них, с которым вы, скорее всего, столкнетесь, — это то, что Discourse предоставляет маршрут /u/admin-login для сотрудников. Этот маршрут отображает форму, принимающую адрес электронной почты сотрудника. Discourse отправит одноразовую ссылку для входа сотруднику. Это удобно при настройке SSO: если вы случайно заблокируете себя на сайте во время настройки, вы сможете снова получить доступ. Это также полезно, если когда-либо возникнут проблемы с вашим сервером аутентификации.
Я согласен, и это то, о чём я уже думал (по причинам, не связанным с Discourse). Основная проблема заключается в том, что обычные участники могут стать сотрудниками и уже становились ими. Поэтому даже если бы мы требовали уникальные адреса электронной почты для пользователей-сотрудников, мы не могли бы гарантировать, что у пользователей они есть, что вызовет проблемы, когда пользователь с дублирующимся адресом почты станет сотрудником.
Тем не менее, теперь, когда стало ясно, что DiscourseConnect сначала использует уникальный идентификатор для поиска пользователей, а часть сообщения DiscourseConnect «Discourse использует адреса электронной почты для сопоставления внешних пользователей с пользователями Discourse» относится только к привязке новых пользователей SSO к существующим учётным записям Discourse, и моё недопонимание работы приглашения к входу было разъяснено, есть ли что-то, что фактически мешает нам просто отправлять дублирующиеся адреса электронной почты как есть? Или эта уникальность строго соблюдается?
Да. Я упустил один шаг в описании процесса входа. Discourse сначала попытается найти пользователя по external_id, а затем по его email. Если ни одно из этих полей не найдено, Discourse попытается создать пользователя. Именно так ваши пользователи будут изначально регистрироваться в Discourse. Discourse не допускает дублирования адресов электронной почты, поэтому, если будет предпринята попытка создать пользователя с уже используемым адресом электронной почты, Discourse выдаст ошибку.
Вам необходимо убедиться, что адреса электронной почты, отправляемые в полезной нагрузке, уникальны для каждого пользователя.
Понял, спасибо за уточнение 
Можно ли позже вручную обновить email пользователя? Теперь, когда проблема с приглашением для входа решена, я, возможно, реализую идею, которую предлагала моя команда ранее: использовать фейковые адреса электронной почты и наш собственный SMTP-сервер, который будет сопоставлять эти фейковые адреса с реальными email пользователей. Например, мы могли бы обновить email всех пользователей в Discourse на что-то вроде userid@example.com, которое сначала подключается к нашему SMTP-серверу, извлекает userid и использует его для поиска реального email пользователя. Однако это решение не будет готово в ближайшее время, поэтому, если это возможно, нам понадобится возможность обновить email пользователей в Discourse позже.
Да. Для этого необходимо включить настройку сайта auth overrides email. При включении этой опции адрес электронной почты пользователя в Discourse будет синхронизироваться с адресом, указанным в полезной нагрузке аутентификации (в вашем случае — в полезной нагрузке DiscourseConnect), при каждом входе пользователя в систему. Если эта опция не включена, адрес электронной почты пользователя будет установлен на адрес из полезной нагрузки аутентификации только при первоначальном создании учетной записи, но не будет обновляться при последующих входах.
Если auth overrides email включена, вы также можете обновить адрес электронной почты без необходимости входа пользователя, отправив API-запрос к маршруту sync_sso: Синхронизация данных пользователя DiscourseConnect с помощью маршрута sync_sso.
Также можно обновить адреса электронной почты пользователей пакетно через консоль Rails вашего сайта, но (по моему мнению) такой способ вызовет отправку пользователю письма с подтверждением от Discourse. Это не сработает для поддельных адресов электронной почты.
Возможно, вы могли бы сразу установить адреса электронной почты на что-то осмысленное. После настройки сайта Discourse проведите несколько тестов, чтобы узнать, какие домены электронной почты Discourse принимает для поддельных адресов. По памяти, я думаю, что @invalid.com принимается. Не уверен насчет других доменов. С вашей стороны вы можете сопоставить что-то вроде <userId>@invalid.com с реальным адресом электронной почты пользователя.
Вы были невероятно полезны, большое спасибо! Решение через API именно то, что я представлял, но знание о том, что оно может синхронизироваться самостоятельно, тоже работает отлично.
Да, мы могли бы. Я планировал сначала попробовать использовать плюс-адресацию, чтобы хотя бы некоторые пользователи получали письма с самого начала. Затем позже перевести всё на наш собственный сервер сопоставления SMTP, чтобы поддержать всех, включая тех, для кого плюс-адресация не сработала.
@simon @supermathie Вы оба были невероятно полезны до сих пор, и я надеюсь, что смогу немного выйти за рамки темы и попросить дальнейшей помощи?
Я установил Discourse на локальную машину для тестирования, используя в качестве руководства Install Discourse for development using Docker. Мне не удалось найти других руководств о том, как настроить его для локального тестирования? Вики-страница, похоже, охватывает только настройки для продакшена, которые требуют предварительной настройки вашего домена/DNS/SMTP. Мы не хотели выставлять форум на публику, пока всё не будет реализовано на нашей стороне, поэтому нам требовалось локальное тестирование, где всё это не было необходимо.
Мне удалось запустить его с помощью этого руководства и реализовать SSO на локальном экземпляре нашего сайта, но пока я столкнулся с двумя проблемами:
- Перенаправление на
return_sso_url, похоже, работает лишь отчасти? В моём случае URL —http://localhost:3000/session/sso_login. Перенаправление происходит успешно, однако после первоначального перенаправления меня перекидывает наhttp://localhost:3000, где отображается ошибкаRuntimeError: Discourse does not support compiling scss/sass files via Sprockets. Единственную тему, которую я нашёл об этой ошибке, можно найти здесь: Error when building: discourse does not support compiling scss/sass files via sprockets, но она, похоже, ни к чему не привела. Автор оригинального сообщения не принял ни одного решения, и единственное, что произошло, — это вопросы об объёме оперативной памяти и размере swap-файла (на машине, на которой это работает, 32 ГБ ОЗУ и 2 ГБ swap. Так что, думаю, это не проблема?) - Параметр
avatar_force_update, похоже, не учитывается? Или, по крайней мере, не для администраторов? Я включил опциюdiscourse connect overrides avatarв настройках сайта, и в полезной нагрузке ответа SSO я устанавливаю какavatar_url, так иavatar_force_update. Но при входе в учётную запись администратора (которая связана с моей внешней учётной записью) моё внешнее профильное изображение не отображается? Я вижу, чтоexternal_avatar_urlустанавливается корректно при проверке данных пользователя-администратора через API, но, похоже, не используется в интерфейсе?
Список методов установки доступен здесь: Set up a local Discourse Development Environment?. У меня есть окружение для разработки без Docker (по руководству для Ubuntu). Если у вас есть такая возможность, я считаю, что вы получите наилучшие результаты, используя подход без Docker. Одна из причин, по которой я его использую, — избежать проблем с сетью при запросах API между Discourse и другими приложениями, которые я разрабатываю локально. Это также быстрее, чем Docker.
Должно учитываться. Убедитесь, что приложение, в котором вы генерируете полезную нагрузку SSO, не преобразует булево значение true в 1. Это распространённая проблема. Чтобы обойти её, вы можете установить любые булевы значения в полезной нагрузке SSO в виде строк "true" или "false". Discourse интерпретирует их корректно. Проверьте это в первую очередь, чтобы убедиться, что проблема именно в этом. Возможно, дело в чём-то другом. Код, обрабатывающий avatar_force_update, довольно сложный, но читаемый: discourse/app/models/discourse_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub.
Редактирование: Что касается проблемы с булевыми значениями в полезной нагрузке SSO, то, пожалуй, точнее будет сказать, что в процессе генерации полезной нагрузки SSO окружение преобразует булевы значения true/false в строки. Discourse ожидает строки "true" или "false", тогда как другие среды программирования могут обрабатывать их иначе. Например:
PHP:
wp> strval(true)
=> string(1) "1"
в отличие от Ruby:
irb(main):001> true.to_s
=> "true"
Python (не уверен, как Discourse обрабатывает этот случай):
>>> str(True)
'True'
Я попробую один из этих вариантов. Спасибо, что указали мне это направление. Это довольно неочевидно. Обычно люди ищут решение на базе Docker как «быстрый и простой» способ настройки. Это первый случай, когда мне порекомендовали избегать версии с Docker. Хотя это всё же поднимает вопрос: почему это происходит именно с версией Docker? Использование другого метода установки позволяет обойти проблему на данный момент, но не решает её корень.
Оно точно не устанавливается в 1. Я работаю на JavaScript, и булево значение true всегда преобразуется в строку "true":
String(true); // 'true'
(true).toString(); // 'true'
// Именно это использует мой код
querystring.stringify({
avatar_force_update: true
}); // 'avatar_force_update=true'
Я никогда раньше не работал с Ruby, поэтому не уверен, насколько далеко смогу продвинуться, углубляясь в это. Но беглый взгляд не выявляет никаких проблем? Однако я проверил, что соответствующая настройка в панели управления Discourse и в полезной нагрузке SSO установлены:
Я не тестировал попытку изменить изображение стандартной учётной записи на что-то отличное от того, с чем она была создана, но когда я впервые вошёл в стандартную учётную запись, Discourse действительно загрузил аватар и применил его, как и ожидалось. Единственная учётная запись, которая не обновляется, — это учётная запись администратора?
Если быть справедливым, в PHP вы почти всегда захотите использовать var_export, чтобы получить «реальное» строковое представление переменной, поскольку он возвращает валидный PHP-код, необходимый для воссоздания этой переменной:
var_export(true); // true
Посмотрите на раздел DiscourseConnect, расположенный в нижней части страницы администратора пользователя. Там есть кнопка, нажав на которую, вы сможете развернуть и увидеть значения последней SSO-нагрузки, полученной Discourse.
Эту же информацию можно найти в консоли Rails. Например:
> SingleSignOnRecord.last
# или
> SingleSignOnRecord.where(external_id: 2)
Включите настройку сайта verbose discourse connect logging (подробное логирование DiscourseConnect). Это добавит дополнительные детали в логи, которые генерируются в разделе Администрирование / Логи / Логи ошибок. В случае проблемы с аватаром соответствующие записи лога могут появиться в обычных логах ошибок, а не в логах DiscourseConnect.
Возможно, проблема специфична для WordPress. Он всегда возвращает 1 для true и "1" для строкового представления true.
Это ожидаемая полезная нагрузка, и URL аватара отображается корректно:
Аватар ДОЛЖЕН быть таким:
Однако он всё ещё отображается как:
Что является моим Gravatar:
Если только я не неправильно понимаю эту настройку или если есть что-то ещё, что мне нужно настроить, я включил настройку для переопределения этих значений:
Я также пробовал это в режиме инкогнито, в разных браузерах и очистил кэш браузера, чтобы исключить проблему с кэшированием.
Это на вашем локальном dev-сайте?
Мне интересно, не произошла ли ошибка при загрузке аватара. Попробуйте включить настройку сайта verbose discourse connect logging, затем выйти из системы и войти снова. В логах должно быть хотя бы одно сообщение, связанное с аватаром:
Возможно, будет ещё одна ошибка, связанная со сбоем загрузки.
Если вы ещё не догадались, это означает: «необходимо обращаться через прокси ember-cli, а не напрямую через браузер».
Используйте bin/ember-cli -u для запуска в режиме разработки.
Я воспроизвёл вашу ситуацию с аватаром:
до:
нагрузка при входе:
после:
но:
Думаю, это ошибка: Discourse корректно устанавливает URL кастомного аватара, но не переключается с Gravatar на кастомное изображение.
Если я создаю нового пользователя:
то всё работает сразу:
поэтому подозреваю, что это вызвано наличием учётной записи с установленным Gravatar до использования DiscourseConnect.
Мне удалось заставить шаги для Ubuntu работать (после довольно значительной доработки, так как скрипт установки конфликтовал с пакетами и программным обеспечением, которые у меня уже были установлены). Это исправило исходную ошибку, но SSO всё ещё работает лишь наполовину. Теперь вместо ошибки scss/sass SSO каждый раз выдаёт сообщение: «Время ожидания входа в учётную запись истекло, пожалуйста, попробуйте войти снова». Однако, если нажать кнопку «Войти» второй раз на этой странице с ошибкой, вход успешно завершается. С моей стороны изменений в коде не было, изменился только способ запуска Discourse.
Я просто припишу всё это особенностям локального запуска. Надеюсь, что при развёртывании в продакшене подобных проблем не возникнет.
Это, похоже, ничего не дало для версии с Docker. Скрипт завершался без вывода, и со стороны Discourse ничего не происходило. Это также противоречит шагам, описанным в руководстве по Docker, что кажется странным. Есть ли причина, по которой об этом там не упоминается?
Мне кажется странным, что метод с Docker имеет такие проблемы, а официальная рекомендация — устанавливать Discourse нативно (несмотря на то, что скрипт установки не всегда работает «из коробки», так как он предполагает использование, например, bashrc и пытается установить потенциально конфликтующие версии уже установленных пакетов). Не стоит ли добавить предупреждение о возможных проблемах со всеми доступными версиями хостинга? С первого взгляда непонятно, какой вариант выбрать, и обычно люди предполагают, что если есть сборка Docker, то это и есть основной вариант.
Рад слышать, что я не один такой! 
Баги никогда не бывают приятными, но я рад, что помог найти этот.
Возможно, это так, но вы должны быть в состоянии запустить DiscourseConnect локально без каких-либо проблем. Вы обращаетесь к Discourse по адресу http://localhost:4200? Есть странная (на мой взгляд) особенность: в локальной среде разработки к Discourse можно обращаться как по localhost:4200, так и по 127.0.0.1:4200. Я бы рекомендовал использовать домен localhost. Он обрабатывается как отдельная сессия по сравнению с 127.0.0.1.
В любом случае, это лишь предположение о том, что происходит. Обязательно включите настройку подробного логирования и проверьте логи для получения деталей.
В инструкциях по установке должно быть четко указано, что запускать скрипт не нужно. Вы можете просто выполнить шаги скрипта по порядку, чтобы убедиться, что все зависимости установлены.
Да, именно так.
Те, на которые была дана ссылка ранее, этого не поясняют. Я перешёл по адресу Set up a local Discourse Development Environment? и выбрал Install Discourse on Ubuntu or Debian for Development, так как у меня установлена Ubuntu 22.04.3. На этой странице действительно сказано, что запускать весь скрипт не обязательно, но эта информация указана мелким шрифтом после раздела, где пользователей просят его выполнить.
Для меня это было неясно, поскольку при чтении инструкций сверху вниз естественно предположить, что текущий шаг нужно завершить перед продолжением. Поэтому я боролся со скриптом установки, устанавливая только то, что было необходимо, и только после завершения продолжил чтение, чтобы убедиться, что именно так всё и задумывалось изначально, и мне не пришлось ни с чем бороться.
Размещение такого предупреждения после инструкций, на мой взгляд, точно не делает их понятными.
Похоже, что система считает nonce неверным? В логах при входе я сейчас вижу следующее:
Не удалось проверить подлинность CSRF-токена. 15:44
Подробный лог SSO: Запущен процесс SSO add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 15:44
Подробный лог SSO: Nonce неверен, был сгенерирован в другой сессии браузера или истёк add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784 15:44
Подробный лог SSO: Запущен процесс SSO add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 15:44
Подробный лог SSO: Пользователь вошёл в систему как PN_Jon add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784406/normal_face.png bio: card_background_url: confirm 15:44
MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-City.mmdb) не найден: No such file or directory @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-City.mmdb 15:44
MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb) не найден: No such file or directory @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb 15:44
При более тщательном рассмотрении выяснилось, что проблема в том, что перенаправление SSO не использует localhost. Оно перенаправляет меня на 127.0.0.1. Если изначально использовать 127.0.0.1 вместо localhost, то проблема устраняется.