Я работаю над сайтом WordPress, к которому подключён форум Discourse с примерно 200 тысячами пользователей.
С помощью плагинов OAuth Single Sign On - SSO (OAuth client) и WP-Discourse мы связываем публикации из WordPress с Discourse и позволяем пользователям входить в WordPress через учётную запись WordPress, после чего они автоматически авторизуются и в Discourse.
Однако возникла проблема: всякий раз, когда в настройках Discourse отключено требование обязательного входа в систему.
Вот наша последовательность действий:
Пользователь входит в WordPress.
Пользователь кликает по ссылке, ведущей на Discourse (тема или любая другая ссылка на Discourse).
==> Пользователь видит Discourse так, будто он не авторизован! Но на самом деле он уже авторизован в момент входа в WordPress!
Теперь пользователь кликает по ссылке входа в Discourse или по любой ссылке на тему.
Страница перезагружается, и пользователь теперь аутентифицирован!
Нам сказали, что это ожидаемое поведение, и что необходимо сделать следующее:
когда пользователь авторизован, все ссылки на Discourse с WordPress должны выглядеть так: https://our-discourse-instance.com/session/sso?return_path={ОРИГИНАЛЬНЫЙ URL ДИСКУРСА, на который мы ссылаемся, например, URL темы и т.п.}
когда пользователь не авторизован, мы можем ссылаться напрямую на {ОРИГИНАЛЬНЫЙ URL ДИСКУРСА, на который мы ссылаемся, например, URL темы и т.п.}, например: https://our-discourse-instance.com/t/topic-slug
Я сильно подозреваю, что это неправильный подход к решению проблемы, потому что:
Что, если пользователь, будучи авторизованным в Discourse, скопирует URL темы и поделится им с кем-то, кто также авторизован в WordPress/Discourse? Они получат ту же ошибку, что описана выше в пункте 2, поскольку к URL не будет добавлен такой суффикс.
Почему авторизованному пользователю нужно перенаправлять на session/sso?return_path=? Каково техническое обоснование и логика этого?
Почему проблема исчезает, как только пользователь перезагружает страницу (открывает URL темы, нажимает «Войти» и т.д.)?
Почему это не более широко документировано, если это действительно ожидаемый подход?
Почему об этом не сказано в API, где мы можем получить любой URL темы из Discourse, и нигде не указано, что авторизованные пользователи не смогут сразу получить доступ к контенту и сначала должны выполнять странные перезагрузки, или что нужно добавлять странные параметры URL, которые на самом деле ничего не меняют?
Я был бы очень признателен за авторитетное мнение, потому что я совершенно не убеждён, что это ожидаемое поведение!
Если это так, я хотел бы узнать:
почему это действительно необходимо и
что планируется сделать в связи с этим (потому что это, безусловно, не идеально, см. пункт 1 моих причин, почему этого не должно быть ожидаемым)
Если вы хотите, чтобы пользователи автоматически перенаправлялись на страницу входа при переходе по любому пути в вашем форуме, вам нужно включить настройку login required. Это действительно ожидаемое поведение.
Хотя это всё ещё кажется немного странным, я добавил перенаправление на session/sso?return_path= при входе пользователя в WordPress.
В качестве return_path я указал реферер из WordPress (если он есть) или главную страницу WordPress.
Это работает отлично и гарантирует, что пользователь будет авторизован в обоих экземплярах.
Однако мне пришлось включить в Discourse настройку, позволяющую «любые return_path», поскольку по умолчанию Discourse запрещает «внешние» return_path.
Вы видите какие-либо проблемы с включением этой настройки?
Ещё раз спасибо за ваш добрый ответ, «официальное» подтверждение и ссылку на документацию!
Обычно я не рекомендую клиентам делать автоматический перенаправление такого рода. Я понимаю, почему вы считаете это проблемой — это распространённое ощущение. Однако стандартный подход отлично работает на многих сайтах, которые по размеру равны вашему или даже больше, а автоматический перенаправление может не сработать в некоторых сценариях, что приведёт к ухудшению пользовательского опыта.
Ожидаемое вами поведение «вход один раз — автоматический вход везде» характерно для взаимосвязанных сервисов, таких как Meta (например, вход в Facebook автоматически даёт доступ к Instagram), потому что это централизованно управляемые платформы (хотя даже централизованные сервисы иногда работают так же, как DiscourseConnect).
В отличие от этого, вы имеете дело с независимыми фреймворками с открытым исходным кодом (то есть WordPress и Discourse). Их можно настроить так, чтобы они эффективно работали так, как вы ожидаете, но для этого требуется специфическая кастомная разработка, учитывающая ваш конкретный случай использования. Это никогда не будет работать так, как система аутентификации DiscourseConnect, которая обслуживает тысячи различных сценариев использования.
Нет, с оговоркой, что я бы поставил под сомнение саму необходимость её включения. Однако без дополнительной информации я не вижу проблем с её использованием.
Может ли это быть риск невалидированного редиректа, как описано здесь?
Я понимаю, как «разрешение любого возвращаемого значения» действительно позволяет перенаправлять куда угодно.
Но я не уверен, что это действительно представляет риск, поскольку в URL редиректа не передаются и не запрашиваются никакие конфиденциальные данные.
Извините, но давать вам советы по деликатному аспекту вашей настройки, не видя её лично и не имея с вами определённых отношений, было бы неуместно.
Учитывая размер вашего форума и применимые к нему нормативные требования, я рекомендую получить конкретные и квалифицированные консультации по этому вопросу.
Форум на Discourse активирует настройку, разрешающую «любой путь возврата».
Это означает, что теперь можно перейти по адресу ваш-форум.tld/session/sso?return_path=ЛЮБОЕ_ЗНАЧЕНИЕ.
ЛЮБОЕ_ЗНАЧЕНИЕ может быть внешней ссылкой.
Таким образом, это открывает уязвимость безопасности, по крайней мере, с точки зрения возможности проведения фишинговой атаки:
Злоумышленник создает веб-сайт с кнопкой, на которой написано «Перейдите в удивительное сообщество!».
Ссылка на кнопку ведет на ваш-форум.tld/session/sso?return_path=ВОЗВРАТ_НА_ВРЕДНЫЙ_САЙТ.
Пользователь нажимает кнопку, входит в систему на форуме сообщества, после чего его переадресовывают на ВРЕДНЫЙ САЙТ.
Там злоумышленник размещает страницу, которая выглядит точно так же, как страница сообщества, с сообщением: «При входе в систему произошла ошибка, пожалуйста, попробуйте снова».
Пользователь вводит данные в красиво оформленную форму входа, соответствующую стилю сообщества.
Теперь злоумышленник получил данные для входа?
Следовательно, настройку «любой путь возврата», вероятно, никогда не следует использовать на сайтах, где пользователи входят в систему, если только каждый пользователь точно не знает, на что обращать внимание.
Вы тоже видите этот риск?
Почему разработчики Discourse, создающие плагины или код, взаимодействующий с этой настройкой, не могут четко ответить «да, проблем нет» или «категорически нет»?
Ведь в этом параметре URL не может произойти много изменений. Либо он есть, либо его нет; либо он разрешает внешние ссылки, либо нет.
Возможно, я касаюсь темы, которую не следует обсуждать, например: «Не обсуждайте вопросы безопасности здесь»? Я, конечно, понимаю это; многие платформы не позволяют открыто говорить о потенциальных проблемах безопасности, которые не являются четко определенными при их включении
Я думаю, вы уже ответили на свой собственный вопрос.
Потому что полезность настроек зависит от того, как они используются; именно поэтому они являются настройками, а не просто «функциями». Если бы на ваш вопрос был простой ответ, такой настройки вообще бы не существовало.
Понимаю, что такой несколько формальный ответ может быть разочаровывающим. Однако вам нужны советы, специфичные для вашего случая использования, а я не могу дать их здесь.
