В данный момент у меня нет локальной установки Discourse, поэтому я не уверен, насколько смогу помочь.
Ответ 404 заставляет меня задуматься, действительно ли Discourse Connect включен на вашем сайте Discourse:
Похоже, что вы тестируете это с локальным Angular-приложением и продакшн-сайтом Discourse. Я ожидал, что это всё ещё будет работать, но возможно, это вызывает проблему. Вы определённо должны получать какой-либо ответ, отличный от 404.
@simon спасибо за ваш ответ,
это уже неоднократно подтверждалось с моей стороны,
у меня также есть тестовый продакшн-сайт, размещённый на родительском домене этого сайта Discourse. Если вы сможете посмотреть эту [ссылка удалена],
чтобы протестировать продакшн-поток, я обновил URL Discourse Connect до “https://domainsite.com/login”. Пожалуйста, войдите через провайдера Google и проведите тест. В консоли разработчика вы увидите ошибку и выведенный мной ответ, который имеет статус 404.
так как я сейчас занимаюсь только POC, не могли бы вы, если вам не сложно, оставить свой адрес электронной почты? Тогда я смогу назначить вас администратором, чтобы вы могли подробно изучить конфигурацию моего сайта Discourse. Ещё раз большое спасибо за ваше время и помощь.
единственная часть, в которой я не уверен, это sig и sso — правильно ли я делаю это из кода?
кроме этой части. я пробовал оба варианта api-ключа: генерировать для всех и только для системы, результат одинаковый. если возможно, предоставьте рабочий пример для postman или кода на основе angular
Я упустил это, когда впервые посмотрел на скриншот вашего кода:
mode: 'no-cors'
Я не очень хорошо знаком с приложениями на Angular, но похоже, что вы пытаетесь выполнить аутентифицированный запрос к API Discourse с клиента. Я не уверен, где именно в коде Discourse это происходит, но, насколько я понимаю, Discourse блокирует запросы к API администратора, выполняемые с клиента. Это связано с тем, что невозможно выполнить такой запрос, не раскрыв API-ключ на клиенте. В связи с этим вам следует немедленно сменить свой API-ключ.
Спасибо, что указали на это.
Кажется, мы делаем ещё один шаг вперёд.
Я также пытаюсь отправить запрос через Postman.
Если вы считаете, что блокировка происходит на стороне клиента из-за mode: 'no-cors', поскольку Discourse отказывается принимать вызовы с API-ключами из фронтенда, то, по вашему мнению, отправку через Postman можно считать корректной? Но результат тот же.
sig и sso получены из вывода ssoPayload и подписи, которые я выводил в процессе.Я даже запустил сервер и попытался инициировать отправку запроса с API-ключом на стороне сервера, но результат остался прежним. Это заставляет меня думать, что я что-то упустил в настройках сайта Discourse.
Хорошая идея — проверить, что это работает из Postman или даже просто из командной строки. Судя по скриншоту, который вы прислали, параметры api-username и api-key находятся в теле запроса. Эти параметры должны быть в заголовке запроса. В теле запроса должны содержаться пары ключ/значение sig и sso. Если это поможет, вот как это обрабатывает плагин WP Discourse: wp-discourse/lib/plugin-utilities.php at main · discourse/wp-discourse · GitHub.
Вау! Вот оно, теперь всё работает!
1000 спасибо @simon
Проблема была именно в том, о чём вы упомянули:
sso и sig должны быть единственными двумя парами ключей в теле запроса,
а api-key и api-username должны находиться в заголовках.
Как это будет работать, если я включу эту опцию на сайте, который в настоящее время не использует external_id? Сможет ли система выполнить вход пользователей, опираясь только на их email?
В более общем смысле, поскольку email и external_id являются двумя обязательными полями в полезной нагрузке, не могли бы вы уточнить, как они используются на стороне Discourse (при получении полезной нагрузки от аутентифицирующего сайта) для определения учетной записи пользователя, в которую нужно выполнить вход?
external_id? Будет ли система использовать email и затем связать external_id с этим email для будущих входов?email и external_id (каждый из них связан с другой учетной записью Discourse)? Система будет использовать external_id или email для определения пользователя для входа? Или же возникнет ошибка?Спасибо!
Я думаю, что ваш главный вопрос касается поля external_id. Вам необходимо установить поле external_id в полезной нагрузке DiscourseConnect. Значение этого поля должно быть некоторой строкой, связанной с пользователем, которая никогда не изменится. Я предполагаю, что в вашем приложении есть таблица пользователей. В качестве значения поля external_id хорошо использовать первичный ключ записи пользователя в этой таблице.
Если пользователь создал учетную запись в Discourse до того, как вы добавили аутентификацию DiscourseConnect с вашего веб-сайта, то при первом входе в Discourse через DiscourseConnect система попытается найти пользователя по адресу электронной почты, указанному в полезной нагрузке DiscourseConnect. После нахождения пользователя в базу данных Discourse будет добавлена запись, содержащая external_id из полезной нагрузки DiscourseConnect. При следующем входе пользователя система будет находить его по external_id, а не по адресу электронной почты. (Обратите внимание, что это не работает, если вы установите параметр require_activation в полезной нагрузке DiscourseConnect в значение true.)
В Discourse предусмотрены надежные механизмы отката для большинства крайних случаев. Существуют проблемы, связанные с наличием у пользователей нескольких учетных записей и адресов электронной почты, которые могут вызывать ошибки. Некоторые подробности о том, как справляться с такими случаями, можно найти здесь: Отладка и исправление распространенных проблем DiscourseConnect.
Очень полезно, спасибо! Звучит так, будто всё работает так, как я и ожидал 
Мы успешно используем DiscourseConnect с WordPress в качестве провайдера уже несколько лет, и конфигурации Discourse и WP не менялись. Сегодня я заметил, вероятно, новое поведение.
Раньше при выходе из системы меня перекидывало на экран входа в WordPress. Теперь же я попадаю на экран входа в Discourse. Если я пытаюсь войти через экран Discourse, получаю ошибку «Неизвестная ошибка», но суть в том, что я вообще не должен там оказаться — я должен быть на экране входа в WP.
Обратите внимание: у меня включена локальная авторизация (не совсем понятно, зачем, раз я использую WP). Если я отключу локальную авторизацию и попробую войти, система сообщит, что методы входа недоступны. Похоже, она не видит моё подключение к WP, хотя я не менял конфигурации ни с одной, ни с другой стороны. Я подтвердил, что Discourse Connect включён, URL подключения верен, а секретные ключи совпадают с обеих сторон.
Версия 3.5.0.beta5-dev. Также плагин WP Discourse обновлён до актуальной версии.
У меня тоже самое происходит, я попробую разобраться, чтобы найти проблему.
Мы тоже используем DiscourseConnect и сталкиваемся с той же проблемой.
У нас система работает уже несколько лет, и всё функционировало без сбоев. Сегодня мы обновились до версии 3.5.0.beta8-dev [e91024a221].
По сути, обратный вызов от системы SSO на URL Discourse добавляет /login (https://discourse.domain.ext/login), и мы видим тот же экран, что и у @markschmucker.
Мы также заметили, что при клике на логотип в шапке мы попадаем на https://discourse.domain.ext/, и вход выполняется успешно (требуется лишь один клик по кнопке).
Похоже, что в предыдущей версии контроллер сессий работал иначе: он, вероятно, определял, что вызов инициирован внешним SSO, и обрабатывал его корректно.
Я обратил внимание, что за последний месяц @zogstrip внес несколько изменений, которые могут быть связаны (хотя я не уверен на 100%) с этой ошибкой.
На данный момент мы применили обходное решение в методе обратного вызова, которое добавляет /login к URL Discourse, и всё, похоже, работает правильно.
Если я что-то упустил, например, документацию с рекомендациями о потенциально разрушительных изменениях в этой части кода, пожалуйста, дайте знать.
Спасибо всем за поддержку.
@markschmucker, @jimkleiber и @marco.palumbo, у вас, случайно, не та же проблема, о которой говорится в No login methods when using Discourse Connect only?
Если да, то решение заключается в том, чтобы убедиться, что включена настройка сайта «auth immediately».
У меня включена функция «авторизация сразу».
Спасибо за вашу помощь в этом вопросе, @zogstrip. К сожалению, если я включу «авторизацию сразу», я теряю возможность иметь страницу «Добро пожаловать» для анонимных пользователей.
Похоже, что удалить имя или avatar_url через DiscourseConnect SSO невозможно. Я пробовал устанавливать эти поля в пустую строку (подтверждено, например, что avatar_url= попадает в параметр sso в base64), но, похоже, код игнорирует пустые поля.
Имена и фотографии в моей системе необязательны, но при текущем поведении, как только они установлены, их нельзя снять, можно только заменить. Возможно, я что-то делаю не так? (Если нет, может быть, это можно исправить?)
[Edit]: Я уже искал ответ, но, конечно, сразу после публикации вышеупомянутого сообщения я попробовал поискать по другим ключевым словам и нашёл Allow name removal using SSO - #9 by mentalstring. Я проголосовал за эту тему, но не жду особых надежд. 
У меня возникла та же проблема с перенаправлением при входе, которую описывают выше @markschmucker, @jimkleiber и @marco.palumbo. Я обнаружил её несколько недель назад и знаю, что она работала корректно где-то в мае. Прочитав ваши комментарии, я убеждён, что это регрессия в Discourse, внесённая в одном из обновлений мая, так как проблема затронула всех нас одновременно, у всех нас работал код SSO, и при этом у нас нет общего кода SSO.
Я опубликовал отчёт об ошибке в надежде, что мы сможем это исправить.
Проблема с перенаправлением исправлена для меня в версии 3.6.0-beta1.
@markschmucker и @marco.palumbo
Похоже, это было исправлено несколько недель назад, и в версии v3.6.0.beta1 должно работать корректно.