That was!! You save my day… Thanks a lot!
Could be wrong, but doesn’t this open up a x-site security vulnerability? See:
I don’t know much in these matters, but here is my reasoning:
- “same site cookie” is enabled by default, so it is probably much better this way.
- “same site cookie” can be disabled, so it’s probably not a security hole by itself, rather a weakness that could be exploited in conjunction with others. Disable it at your own risks.
Anyone understands why disabling same site cookie enforcement prevents users from log in within an iframe?
Можно ли, пожалуйста, получить официальную поддержку Discourse в iframe?
РЕДАКТИРОВАНИЕ: Ой, извините, я не понял, что пишу спустя два года.
Очень маловероятно, что это когда-либо будет поддерживаться.
Джефф,
Во-первых: Discourse — это совершенно потрясающе, спасибо за его создание!
Во-вторых: есть ли где-то документация о том, какие конкретные проблемы могут возникнуть при встраивании Discourse через iframe, или какие ограничения в принципе могут на это повлиять?
Спасибо!
Привет, Адам, давно не виделись, давай попробую ответить здесь.
Использование <iframe> очень ненадёжно и сделает Discourse крайне неудобным в использовании, а также приведёт к множеству ошибок, которые будет сложно отследить. Кроме того, это часто приводит к тому, что iframe «выпадает» из контекста Discourse, из-за чего такие функции, как прокрутка длинных тем, перестают работать. По сути, iframe изолирует многие возможности Discourse.
Если вы рассматриваете вариант с использованием iframe, хорошей стратегией будет добавить в свой форум заголовок, соответствующий остальной части вашего сайта/приложения/портала, включая ссылки навигации. Когда пользователь перейдёт в форум, он увидит похожую навигацию, но будет находиться на другом URL, размещённом в другом месте. При нажатии на ссылку, не относящуюся к форуму, в заголовке пользователь вернётся на сайт/в приложение/портал.
Надеюсь, это поможет.
Спасибо за ваш ответ!
Не могли бы вы рассказать, какие именно проблемы могут возникнуть? Или привести конкретные причины, почему контекст iframe может вызвать серьезные проблемы?
Что означает «оконно» в данном контексте?
Мы поступим именно так для нашей основной зоны обсуждений, но для данного конкретного случая это проблематично. Мы проводим онлайн-курсы. Каждый курс проходит в специально оформленном, приватном разделе нашего сайта. В содержание курса входят учебные материалы, видео, расписание и зона обсуждений. После завершения курса студенты могут продолжать обсуждения, которые они начали с другими участниками своей группы. Их также добавляют в общую группу выпускников курса, и им будет предложено присоединиться к нашему большому публичному форуму.
Для нашего случая у предложенного подхода есть две проблемы:
-
Тема (заголовок, стили, боковая панель и т. д.) для раздела курса на нашем сайте не совпадает с темой, которую мы хотим использовать для нашего Discourse в целом. Чтобы это учесть, нам нужно было бы иметь возможность использовать разные стили и темы для каждой категории, что, похоже, невозможно.
-
Обсуждения курса в нашей текущей (не на Discourse) реализации включают стили, заголовок и боковое меню. Это пространство с минимальными отвлекающими факторами, где студенты могут сосредоточиться на материалах курса и плавно переключаться между обсуждением, учебными материалами, видео и т. д. Насколько я понимаю, модифицировать Discourse для воспроизведения такой иммерсивной среды было бы сложно. Если это не так, я с радостью узнаю об обратном!
Спасибо за вашу помощь,
Адам
Это возможно. Элемент body будет иметь класс, указывающий текущую категорию, что позволяет легко ограничивать область действия темы с помощью вложенных селекторов в SCSS.
В целом, я рекомендую добавить несколько виджетов Discourse в область курса, например, поддерживаемую нами функцию списка тем в iframe, описанную в статье Встраивание списка тем Discourse на другой сайт. Таким образом, студенты смогут видеть список последних обсуждений, связанных с их текущей страницей курса, и смогут присоединиться к ним в новой вкладке браузера всего одним кликом!
Привет, Фалько,
Спасибо за твой ответ и извини за задержку с моим.
К сожалению, реализация наших курсов немного сложнее, чем может обеспечить кастомная область CSS без значительных ухищрений. Например, в верхнем меню есть выпадающий список курсов, в которые зарегистрирован текущий пользователь. Он динамически генерируется из базы данных WordPress на основе вошедшего в систему пользователя, поэтому его будет сложно воспроизвести в Discourse.
Боковое меню в разделе курсов содержит ссылки на различные виды контента курсов, которые специфичны для конкретного курса. Если я правильно понимаю, для того чтобы описанный тобой подход работал, весь этот контент для всех курсов нужно было бы прописать вручную в теме, а затем показывать или скрывать с помощью CSS в зависимости от класса body. Так ли это?
Один из возможных подходов — использовать клиентский JavaScript в Discourse, который будет получать контент из нашего API и отображать его. Возможно ли добавить кастомные скрипты, выполняющие XmlHttpRequest к другим серверам? Видишь ли ты какие-либо причины, по которым это может быть невозможно?
По-прежнему надеюсь получить ответ на этот вопрос.
Спасибо!
Да, это возможно. Просто убедитесь, что эти запросы не блокируют отрисовку страницы.