In den Fehlerprotokollen ist nichts zu sehen, soweit ich das beurteilen kann.
Es ist auch für ein anderes eingebettetes Iframe von einer anderen Quell-Domain fehlgeschlagen, die ich erlaubt habe.
Genau die gleiche Art von eingebettetem Iframe von der gleichen Quell-Domain funktionierte beim letzten Mal, als ich es versuchte, vor vielleicht 6 Monaten oder einem Jahr. Jetzt bin ich auf Discourse v3.3.1 +5 (stable branch).
Auf der neuesten Version des Tests-bestanden-Branches wird das iframe ohne Probleme eingebettet. Beachten Sie, dass die von Ihnen gesetzten Attribute style und title von Discourse entfernt werden. Sie können jedoch die Attribute width und height festlegen. Zum Beispiel:
Failed to load resource: net::ERR_CONNECTION_REFUSED beacon.min.js:1
Aber das scheint eine DNS-Blacklist zu sein, die ich verwende. Wenn ich mich über ein VPN verbinde, gibt es keine Fehler. Und es scheint mehr als ein Zufall zu sein, dass ein anderer Benutzer mit einem völlig anderen Computer und Netzwerk ursprünglich das gleiche Problem an mich gemeldet hat.
OK Firefox zeigt mir eine weitere Konsolennachricht:
Partitioned cookie or storage access was provided to “https://www.tickcounter.com/widget/countdown/4471981” because it is loaded in the third-party context and dynamic state partitioning is enabled. [Mehr erfahren]
Ich sollte auch erwähnen, dass ich den iframe-Code in eine statische HTML-Datei eingefügt und sie im Browser geöffnet habe und der iframe ordnungsgemäß geladen wurde.
ok this iframe used to work for you… Are you on Cloudflare by chance? if so, perhaps take a look and see if disabling the speed brain thing does anything? (if it is enabled) I know that it is relatively new thing.
[Zitat=“Lilly, Beitrag:8, Thema:327852”]
Etwas blockiert es in deinem Forum
[/Zitat]
Hmm ja, so sieht es aus. Aber sollte Discourse nicht einen Fehler in /logs/ haben?
Ich betreibe nichts, von dem ich wüsste, das dies auf dem Server blockieren würde. Ich habe den DNS des Hosting-Providers in meiner /etc/resolv.conf verwendet, und ich habe versucht, ihn auf 8.8.8.8 umzustellen, ohne dass sich etwas an diesem Problem geändert hat.
nur wenn es einen Fehler verursacht. Etwas könnte es aus Gründen der ordnungsgemäßen Funktionalität blockieren. Ich würde versuchen herauszufinden, ob/was sich geändert hat, als dies aufhörte zu funktionieren. Ich frage mich, ob eine Änderung der Content Security Policy dies beeinträchtigt haben könnte.
Es ist ein DNS-Dienst, der Domains mit schlechtem Ruf blockiert. Aber das ist nicht das Problem, denn 1) wenn ich über ein VPN verbinde, verwende ich ein anderes DNS und dieses Problem besteht weiterhin, und 2) der Benutzer, der mich auf dieses Problem aufmerksam gemacht hat, verwendet eine völlig andere Konfiguration, 3) die DNS-Konfiguration ist nur für mein LAN und nicht auf dem Discourse-Server, der das richtige HTML serverseitig nicht generieren kann, und 4) diese HTML-Datei lädt den iframe korrekt:
Oh wow, das war’s, es fehlte der letzte /
Vielen Dank!
Irgendetwas hat sich in Discourse geändert, denn ich habe letztes Mal, als ich das versucht habe, https://www.tickcounter.com hinzugefügt und es hat funktioniert. Meiner Meinung nach sollte entweder die verwendete Regex-Logik oder die Beschreibung der Einstellung angepasst werden, denn es heißt:
Eine Liste von iframe src-Domainpräfixen, die Discourse sicher in Beiträgen zulassen kann
Wenn ich an ein “Domainpräfix” denke, denke ich an einen Domainnamen und/oder eine Subdomain, die beide kein / enthalten. Oder wenn es eine präzisere Logik für komplexe iframe src-URLs verwenden soll, dann sollte es etwas sagen wie:
Eine Liste von iframe src-URL-Präfixen, die Discourse sicher in Beiträgen zulassen kann
Die Links, die vor mehr als 2 Monaten hinzugefügt wurden (bevor der Sicherheitsfix zusammengeführt wurde), sind das Problem. Damals erhielten Sie keine Fehlermeldung und selbst die Standardlinks enthielten kein drittes ‘/’.
Dies ist mindestens das zweite Support-Thema deswegen
hmmm. Das scheint auch für mich wie erwartet zu funktionieren.
