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 „Gefällt mir“
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?
Könnten wir bitte offizielle Unterstützung für Discourse in einem iframe bekommen?
EDIT: Ups, sorry, mir war nicht klar, dass ich zwei Jahre später poste.
Es ist sehr unwahrscheinlich, dass dies jemals unterstützt wird.
2 „Gefällt mir“
Jeff,
Erstens: Discourse ist absolut großartig, danke, dass du es entwickelt hast!
Zweitens: Ist irgendwo dokumentiert, welche spezifischen Probleme bei einer in einem iframe eingebetteten Discourse-Installation zu erwarten sind oder welche Einschränkungen sie grundsätzlich betreffen?
Vielen Dank!
Hallo Adam, es ist eine Weile her, lass es mich hier versuchen zu beantworten.
Die Verwendung eines <iframe> ist sehr fehleranfällig und würde Discourse sehr schwer bedienbar machen und voller Bugs, die schwer zu finden sind. Außerdem führt es oft zu einer „Fensterung“ innerhalb von Discourse, was dazu führt, dass Funktionen wie das Scrollen durch große Themen kaputtgehen. Im Grunde genommen sandboxt ein Iframe viele Funktionen von Discourse.
Ein guter Ansatz, falls du die Verwendung eines Iframes in Betracht ziehst, wäre, deinem Forum einen Header hinzuzufügen, der dem Rest deiner Website/App/Portal entspricht, einschließlich Navigationslinks. Wenn ein Nutzer auf das Forum klickt, sieht er eine ähnliche Navigation, befindet sich aber auf einer anderen URL, die woanders gehostet wird. Wenn er auf einen Nicht-Forum-Link im Header klickt, ist er wieder auf der Website/App/Portal.
Ich hoffe, das hilft.
2 „Gefällt mir“
Danke für deine Antwort!
Könntest du konkretisieren, welche spezifischen Probleme dabei zu erwarten wären? Oder nenne bitte konkrete Gründe, warum der Kontext eines Iframes zu ernsthaften Problemen führen würde?
Was bedeutet „einbetten“ (window) in diesem Fall?
Das werden wir für unseren Hauptdiskussionsbereich tun, aber für diesen speziellen Anwendungsfall ist es problematisch. Wir bieten Online-Kurse an. Jeder Kurs findet in einem speziell gestalteten, privaten Bereich unserer Website statt. Der Kursinhalt umfasst Unterrichtsmaterialien, Videos, einen Zeitplan und einen Diskussionsbereich. Sobald die Studierenden den Kurs abgeschlossen haben, können sie die Diskussionen, die sie mit anderen Teilnehmern der Kursgruppe begonnen haben, fortsetzen. Sie werden zudem einer allgemeinen Diskussionsgruppe für Kursabsolventen hinzugefügt und erhalten eine Einladung zu unserem größeren, öffentlichen Diskussionsforum.
Für unseren Anwendungsfall gibt es zwei Probleme mit dem hier vorgeschlagenen Ansatz:
-
Das Design (Header, Styles, Seitenleiste usw.) für den Kursbereich auf unserer Website entspricht nicht dem Design, das wir für unser allgemeines Discourse verwenden möchten. Um dies zu ermöglichen, müssten wir pro Kategorie unterschiedliche Styles und Theme-Inhalte verwenden können, was offenbar nicht möglich ist.
-
Die Kursdiskussion in unserer aktuellen (nicht-Discourse) Implementierung enthält Styles, einen Header und ein Seitenleistenmenü. Es ist ein ablenkungsarmer Raum, in dem sich Studierende auf den Kursinhalt konzentrieren und nahtlos zwischen Diskussion, Unterrichtsmaterial, Videos usw. wechseln können. Soweit ich das beurteilen kann, wäre es schwierig, Discourse so anzupassen, dass es diese Art von immersiver Umgebung nachbildet. Falls dies nicht der Fall ist, freue ich mich, das Gegenteil zu erfahren!
Vielen Dank für deine Hilfe,
Adam
Das ist möglich. Das body-Element erhält eine Klasse, die die aktuelle Kategorie angibt, sodass Sie das Thema einfach mithilfe verschachtelter Selektoren in SCSS einschränken können.
Im Allgemeinen empfehle ich Ihnen, dem Kursbereich einige Discourse-Widgets hinzuzufügen, wie z. B. unsere unterstützte Funktion für die Einbettung einer Topic-Liste in einem iframe, die in Eine Liste von Discourse-Topics in einer anderen Website einbetten dokumentiert ist. Auf diese Weise können Studierende eine Liste der neuesten Diskussionen sehen, die sich auf ihre aktuelle Kursseite beziehen, und mit einem einzigen Klick in einem anderen Browser-Tab daran teilnehmen!
3 „Gefällt mir“
Hallo Falco,
vielen Dank für deine Rückmeldung und entschuldige bitte die verzögerte Antwort.
Leider ist unsere Kursimplementierung etwas komplexer, als dass sie sich ohne erhebliche Umwege mit einem benutzerdefinierten CSS-Scope abbilden ließe. Beispielsweise enthält das Kopfmenü ein Dropdown-Menü mit den Kursen, in denen der aktuelle Nutzer angemeldet ist. Dies wird dynamisch aus der WordPress-Datenbank basierend auf dem angemeldeten Benutzer generiert und wäre daher schwierig in Discourse nachzubilden.
Das Seitenmenü im Kursbereich enthält Links zu verschiedenen Arten von Kursinhalten, die spezifisch für einen bestimmten Kurs sind. Wenn ich dich richtig verstehe, müssten für die von dir beschriebene Funktionalität all diese Inhalte für alle Kurse im Theme hart kodiert werden und dann je nach Body-Klasse über CSS ein- oder ausgeblendet werden. Stimmt das?
Ein Ansatz, der funktionieren könnte, wäre die Verwendung von clientseitigem JavaScript in Discourse, das Inhalte über unsere API abruft und anzeigt. Ist es möglich, benutzerdefinierte Skripte hinzuzufügen, die XmlHttpRequests zu anderen Servern durchführen? Siehst du irgendeinen Grund, warum dies nicht möglich sein sollte?
Ich hoffe immer noch, eine Antwort auf diese Frage zu erhalten.
Vielen Dank!
Ja, das ist möglich. Achten Sie jedoch darauf, dass diese Anfragen das Rendern der Seite nicht blockieren.
2 „Gefällt mir“