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?
Pouvons-nous s’il vous plaît obtenir un support officiel pour Discourse dans un iframe ?
EDIT : Oups, désolé, je n’avais pas réalisé que je postais deux ans plus tard.
Il est très peu probable que cela soit jamais pris en charge.
Jeff,
Premièrement : Discourse est tout simplement génial, merci de l’avoir créé !
Deuxièmement : est-il documenté quelque part quels problèmes spécifiques on peut attendre avec une intégration de Discourse via iframe, ou quelles limitations pourraient l’affecter en principe ?
Merci !
Bonjour Adam, ça fait un moment, laissez-moi essayer de répondre ici.
L’utilisation d’un <iframe> est très sujette aux erreurs et rendrait Discourse très difficile à utiliser, avec de nombreux bogues difficiles à localiser. De plus, cela a tendance à « isoler » le forum dans une fenêtre, ce qui casse des fonctionnalités comme le défilement dans les sujets longs. En gros, les iframes mettent en sandbox de nombreuses fonctionnalités de Discourse.
Une bonne approche si vous envisagez d’utiliser un iframe serait d’ajouter un en-tête à votre forum qui correspond au reste de votre site/application/portail, y compris les liens de navigation. Lorsqu’un utilisateur clique pour accéder au forum, il verra une navigation similaire, mais sera sur une URL différente hébergée ailleurs. Lorsqu’il cliquera sur un lien hors forum dans l’en-tête, il reviendra dans le site/application/portail.
J’espère que cela vous aidera.
Merci pour votre réponse !
Pourriez-vous préciser quels sont les problèmes spécifiques attendus ? Ou les raisons précises pour lesquelles le contexte d’un iframe poserait de graves problèmes ?
Que signifie « fenêtrer » dans ce cas ?
C’est ce que nous ferons pour notre espace de discussion principal, mais cela pose problème pour ce cas d’utilisation spécifique. Nous proposons des cours en ligne. Chaque cours se déroule dans une zone privée et spécialement thématisée de notre site. Le contenu du cours comprend des supports de cours, des vidéos, un emploi du temps et un espace de discussion. Une fois le cours terminé, les étudiants peuvent poursuivre les discussions qu’ils ont engagées avec les autres participants de leur cohorte. Ils sont également ajoutés à un groupe de discussion général pour les anciens élèves du cours, et seront également invités à notre forum de discussion public plus vaste.
Pour notre cas d’utilisation, il y a deux problèmes avec l’approche suggérée ici :
-
Le thème (en-tête, styles, barre latérale, etc.) de la zone de cours sur notre site n’est pas le même que celui que nous souhaitons utiliser pour notre Discourse en général. Pour y parvenir, nous devrions pouvoir utiliser des styles et du contenu de thème différents par catégorie, ce qui ne semble pas possible.
-
La discussion du cours dans notre implémentation actuelle (non Discourse) inclut des styles, un en-tête et un menu latéral. C’est un espace à faible distraction où les étudiants peuvent se concentrer sur le contenu du cours et passer facilement de la discussion aux supports de cours, aux vidéos, etc. Pour autant que je sache, il serait difficile de modifier Discourse pour reproduire ce type d’environnement immersif. Si ce n’est pas le cas, je suis ravi d’en apprendre davantage !
Merci pour votre aide,
Adam
C’est possible. L’élément body aura une classe indiquant la catégorie actuelle, ce qui vous permet de cibler facilement le thème à l’aide de sélecteurs imbriqués en SCSS.
En général, je vous recommande d’ajouter quelques widgets Discourse à la zone de cours, comme notre fonctionnalité prise en charge de liste de sujets via iframe, documentée dans Intégrer une liste de sujets Discourse dans un autre site. De cette façon, les étudiants peuvent voir une liste des discussions les plus récentes liées à leur page de cours actuelle et peuvent y accéder en un seul clic dans un autre onglet du navigateur !
Bonjour Falco,
Merci pour votre réponse, et excusez mon retard à répondre.
Malheureusement, notre implémentation des cours est un peu plus complexe qu’un simple scope CSS personnalisé ne peut gérer sans des gymnastiques importantes. Par exemple, le menu d’en-tête inclut un menu déroulant listant les cours auxquels l’utilisateur actuel est inscrit. Ceci est généré dynamiquement à partir de la base de données de WordPress, en fonction de l’utilisateur connecté, ce qui rendrait difficile à reproduire dans Discourse.
Le menu latéral dans la zone des cours contient des liens vers divers types de contenu de cours, spécifiques à un cours particulier. Si je comprends bien, pour que ce que vous décrivez fonctionne, tout ce contenu, pour tous les cours, devrait être codé en dur dans le thème, puis affiché ou masqué par le CSS en fonction de la classe du corps. Est-ce exact ?
Une approche qui pourrait fonctionner consisterait à utiliser du JavaScript côté client dans Discourse pour récupérer du contenu depuis notre API et l’afficher. Est-il possible d’ajouter des scripts personnalisés effectuant des XmlHttpRequests vers d’autres serveurs ? Voyez-vous une raison pour laquelle cela ne serait pas possible ?
J’espère toujours recevoir une réponse à cette question.
Merci !
Oui, c’est possible. Faites simplement attention à ne pas laisser ces requêtes bloquer le rendu de la page.