Comprendre/travailler avec CSP, iframes, ancêtres

Soutien
1

Nous avons Discourse installé sur site1. Nous possédons/administrons site2.tld et voulons accéder au forum via un iFrame depuis une page là-bas. Je ne suis pas doué dans l’art du CSP, donc votre aide est appréciée.

Je ne veux pas désactiver les restrictions d’ancêtre, mais temporairement, j’ai décoché le CSP frame ancestor :

image

Le HTML jusqu’à présent est :

<iframe
  style="position:absolute;width:100vw;height:100vh"
  src="https://forum.site1.tld">
</iframe>

Cela résulte toujours en :

Firefox ne peut pas ouvrir cette page
Pour protéger votre sécurité, forum.site1.org ne permettra pas à Firefox d’afficher la page si un autre site l’a intégrée. Pour voir cette page, vous devez l’ouvrir dans une nouvelle fenêtre.

J’ai regardé Embedding mais cette fonctionnalité semble servir un objectif différent. Nous ne voulons pas limiter à un seul sujet, et l’utilisateur ne sera pas connecté. Initialement, il est acceptable que l’utilisateur ne se connecte pas et que l’intégralité du forum soit disponible en lecture seule.

Des suggestions ? Des questions ?

Merci !

2

Quelqu’un d’autre intègre-t-il son site1 Discourse dans son site2 ? Merci !

3

Nous ne recommandons pas, et nous ne testons pas, l’intégration complète de Discourse dans un autre site via des iframes.

Nous recommandons plutôt d’avoir chaque site sur son propre domaine, en utilisant des liens, une authentification unique et en stylisant Discourse pour qu’il corresponde à l’aspect visuel de votre site principal.

2 « J'aime »
4

Compris. Merci !

5

Comprendre les conséquences à long terme, nous avons temporairement désactivé CSP mais recevons toujours un avertissement CSP de Firefox. Un redémarrage est-il nécessaire ?

image
image722×316 10.1 KB

Voici l’application/le défi. Il existe peut-être une solution simple…

Il y a un serveur Discourse et, comme d’habitude, un nombre quelconque de comptes utilisateurs et d’invités. Les utilisateurs enregistrés disposent d’une application qui héberge un serveur web local. Une page web est créée dans cette application et accessible depuis un navigateur local sous http://192.168.1.1:8080. Cette page web propose le forum via un IFrame.

Nous n’avons aucun contrôle sur les sous-réseaux qui servent le contenu, donc l’IP peut provenir de n’importe quel NAT/DHCP courant. Mais nous avons un contrôle total sur les éléments suivants :

  • L’installation et le serveur Discourse.
  • Le contenu qui est servi.
  • Le numéro de port est généralement 8080, configurable par l’utilisateur, mais ne sera jamais 80 ou 443.
  • Comme il s’agit de contenu local et non critique, il n’est pas sécurisé par SSL.
  • Les utilisateurs doivent avoir un compte Discourse et se connecter à Discourse pour avoir un accès en écriture.

En ce qui concerne la sécurité :

  • Le forum public est accessible via un nom d’hôte.
  • L’accès réseau est bien sûr toujours sécurisé par SSL.
  • Personne ne peut créer de contenu de forum s’il n’est pas connecté.
  • Donc oui, la page locale avec l’IFrame est servie en HTTP : mais la source de l’IFrame est HTTPS://forum.site.tld. (Cette différence de protocole pourrait être la cause de l’échec d’accès au forum même avec CSP désactivé.)
  • Une fois que l’utilisateur lance son navigateur, pour accéder au serveur local, il doit entrer un mot de passe. Nous pourrions activer le SSL pour cette page si nécessaire afin de maintenir la cohérence entre cette page parente et l’IFrame vers le site du forum activé par SSL.
  • Nous n’avons pas l’intention de scripter via l’IFrame dans Discourse. Tout ce que nous voulons faire, c’est héberger le forum dans un conteneur.

Voici quelques idées aléatoires qui n’ont peut-être aucun mérite :

  1. Permettre aux utilisateurs d’obtenir une clé API depuis leur page de compte Discourse, qu’ils peuvent mettre dans l’application, qui sera ensuite transmise à Discourse dans un cookie ou d’une autre manière. Cela confirme que, bien que l’utilisateur ne soit pas conforme CORS ou CSP, il est autorisé à accéder aux ressources.
  2. Demander à l’application d’injecter un jeton dans l’URI de l’IFrame vers Discourse. Simultanément, utiliser un appel API pour que Discourse autorise les connexions entrantes avec ce jeton. (Oui, cela nécessiterait du codage)
  3. Devenir encore plus gênant… Créer une page sur un site communautaire qui ouvre un IFrame pour le contenu du sous-réseau, et un autre IFrame vers le forum. Ce site unique peut être autorisé pour l’accès inter-origines.
  4. Abandonner l’idée de contourner les politiques et utiliser target=window pour ouvrir Discourse en dehors de la fenêtre de l’application.

Sans recourir immédiatement à l’option 4… des idées ? Merci !