That was!! You save my day… Thanks a lot!
Could be wrong, but doesn’t this open up a x-site security vulnerability? See:
2 Likes
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?
Can we please get official support for Discourse in an iframe?
EDIT: Whoops, sorry, I didn’t realize I was posting two years later.
It is very unlikely this will ever be supported.
2 Likes
Jeff,
First: Discourse is completely awesome and thank you for building it!
Second: is it documented somewhere what specific issues would be expected with an iframe-embedded Discourse, or what limitations would impact it in principle?
Thank you!
Hello Adam, it has been a while, let me try and answer here.
Using an <iframe> is very error prone and would make Discourse very hard to use and full of bugs that would be difficult to track down. It also tends to “window” into Discourse which makes things like scrolling through large topics break. Basically, iframes sandboxes a lot of Discourse’s features.
A good route to take if you were considering using an iframe would be to add a header to your forum that matches the rest of your site/app/portal including navigation links. When a user clicks into the forum they will see a similar navigation but would be on a different URL hosted elsewhere. When they click on a non-forum link in the header they’d be back in the site/app/portal.
I hope this helps.
2 Likes
Thanks for your reply!
Could you share what the specific issues are that would be expected? Or specific reasons why the context of an iframe would cause serious issues?
What does “window” mean in this case?
This is what we will do for our main discussion area, but it is problematic for this specific use case. We are running online courses. Each course happens in a specially themed, private area of our site. The course content includes class materials, videos, schedule, and a discussion area. Once students have completed the course, they can continue the discussions they have started with other participants in the course cohort. They are also added to a general course alumni discussion group, and will also be invited to our larger, public discussion forum.
For our use case, there are two problems with the approach suggested here:
-
The theme (header, styles, sidebar, etc) for the course area on our site is not the same as the theme that we will want to use for our Discourse in general. In order to accommodate this, we would need to be able to use different styles and theme content per category, which doesn’t seem to be possible.
-
The course discussion in our current (non-Discourse) implementation includes styles, header, and a sidebar menu. It is a low-distraction space where students can focus on the course content and smoothly switch between discussion, class material, videos, etc. As far as I can tell, it would be difficult to modify Discourse to replicate this kind of immersive environment. If this is not the case, I am happy to learn otherwise!
Thanks for your help,
Adam
That’s possible. The body element will have a class indicating the current category that allows you to scope the theme easily using nested selectors in SCSS.
In general, I would recommend you to add a couple of Discourse widgets to the course area, like our supported iframe topic list feature documented at Embedding a list of Discourse Topics in another site. That way students can see a list of the most recent discussions related to their current course page and are a single click away to joining it in another browser tab!
3 Likes
Hi Falco,
Thanks for your reply, and pardon the delayed response.
Unfortunately our courses implementation is a bit more complex than a custom CSS scope can accommodate without significant gymnastics. For example, the header menu includes a drop-down of courses that the current user is enrolled in. This is dynamically generated from the WP DB, based on the logged in user, so would be difficult to replicate in Discourse.
The sidebar menu in the courses area includes links to various kinds of course content, which are specific to a particular course. If I understand correctly, for what you’re describing to work all of this content, for all the courses, would need to be hardcoded into the theme, and then shown or hidden by the CSS depending the body class. Is that correct?
One approach that could work would be to use some client side JS in Discourse that would pull content from our API and display it. Is it possible to add custom scripts that do XmlHttpRequests to other servers? Do you see any reason this wouldn’t be possible?
Still hoping to hear an answer to this question.
Thank you!
Yes that is possible. Just be careful to not make those requests block rendering the page.
2 Likes