Hi Support team!
When I try embedding with the provided js snippet, it will stuck at “Loading Discussion” and I get the following error:
Invalid X-Frame-Options: “ALLOWALL” header from ...
How can I resolve this issue?
Thanks!
Potrebbe essere in ritardo, ma ho riscontrato lo stesso problema e avrei apprezzato una risposta qui. Il mio problema si presentava solo quando si utilizzava Firefox. Chrome funzionava, nessun problema. L’ho risolto aggiungendo il sito che incorpora i contenuti all’impostazione “cors origins”. Ho trovato la soluzione qui.
Ho appena notato che anche i nostri siti stanno riscontrando questo problema, ma solo con i nuovi post, non con quelli esistenti per cui era già stato creato un topic companion. L’header Invalid X-Frame-Options sembra essere più un avviso di Firefox che un vero e proprio errore, dato che appare sempre, anche quando l’embedding ha successo.
Un esempio funzionante (con un topic esistente quando l’embedding funzionava)
Mentre questa landing page:
alla fine riceve una risposta 400 bad request dalla nostra istanza di Discourse..
Ho esaminato a fondo questi forum e la documentazione per capire perché ciò possa accadere, ma non ho ancora trovato nulla.. Pensavo potesse essere correlato all’inclusione del nome utente di Discourse nel payload di embedding, ma ciò si verifica anche per i contenuti creati da utenti correttamente sincronizzati (ad esempio, Winter School on Agent-Based Modeling of Social-Ecological Systems)
Cose che ho verificato:
DISCOURSE_ENABLE_CORS: trueè impostato- i host CORS sono corretti nelle impostazioni di Discourse con https
- gli host consentiti sono impostati correttamente (anche l’embedding funziona per i post di Discourse già creati)
C’è qualcos’altro che dovrei prendere in considerazione? L’unica altra cosa a cui riesco a pensare è che abbiamo recentemente integrato i nostri siti con CloudFlare, quindi forse c’è qualche configurazione di CloudFlare da impostare per far funzionare tutto correttamente. Sono ancora perplesso sul motivo per cui i topic esistenti funzionino correttamente…
Dovresti provare a disabilitare temporaneamente Cloudflare e vedere se questo aiuta. È abbastanza facile da fare…
Ottima idea, l’ho provato sul nostro sito di staging, ma purtroppo non ha risolto il problema..
Su Chrome vedo errori come questo:
Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://test-discourse.comses.net') does not match the recipient window's origin ('https://test.comses.net').
(da https://test.comses.net/codebases/f0613922-9cb1-4656-a26c-af57f823fb69/releases/3.2.0/)
Altri qui sembrano aver risolto assicurandosi che DiscourseEmbed.discourseEmbedUrl fosse uguale all’URL di riferimento, ma ho verificato che fosse ancora corretto.. Ho dato un’occhiata ai log di Discourse (dovrei guardare /var/discourse/shared/standalone/log/rails/production.log ?) ma non ho visto errori nemmeno lì.. hai altre idee su dove cercare per risolvere il problema?
Un esempio dai log di Discourse:
Started GET "/embed/comments?embed_url=https%3A%2F%2Ftest.comses.net%2Fcodebases%2Ff0613922-9cb1-4656-a26c-af57f823fb69%2Freleases%2F3.2.0%2F" for 72.201.57.141 at 2020-08-05 05:15:40 +0000
Processing by EmbedController#comments as HTML
Parameters: {"embed_url"=>"https://test.comses.net/codebases/f0613922-9cb1-4656-a26c-af57f823fb69/releases/3.2.0/"}
Rendering embed/loading.html.erb within layouts/embed
Rendered embed/loading.html.erb within layouts/embed (Duration: 0.4ms | Allocations: 134)
Completed 200 OK in 91ms (Views: 1.8ms | ActiveRecord: 0.0ms | Allocations: 16308)
Started GET "/service-worker-c8000968830b6f6bd33f1e842dffdd569664119d449f93dc7d428d963a71635d.js" for 72.201.57.141 at 2020-08-05 05:15:42 +0000
Processing by StaticController#service_worker_asset as */*
Rendering text template
Rendered text template (Duration: 0.0ms | Allocations: 1)
Completed 200 OK in 27ms (Views: 1.3ms | ActiveRecord: 0.0ms | Allocations: 6617)
Ho lo stesso problema. Puoi vederlo in azione, ad esempio, su: Making sure you're not a bot! dove in basso è incorporata una discussione tratta da @mock/mock - Fedora Discussion. Si noti che discussion.fedoraproject.org è un’istanza a pagamento fornita come servizio da Discourse.
Ciò che mi lascia perplesso è che la discussione a volte si carica, altre volte no. Sono in grado di riprodurla (quasi sempre) in modalità privata su Firefox (versione 80).
Gli strumenti per sviluppatori mostrano:
È stato rilevato un header X-Frame-Options non valido durante il caricamento di “@mock/mock - Fedora Discussion”: “ALLOWALL” non è una direttiva valida.
E infatti, la documentazione X-Frame-Options header - HTTP | MDN non riconosce ALLOWALL come valore valido.
Sembra che l’argomento a cui hai fatto riferimento in https://discussion.fedoraproject.org/t/mock-mock/3107 appartenga a una categoria protetta: non riesco ad accedervi come utente anonimo. Finché il tuo forum Discourse e il tuo sito web condividono lo stesso dominio radice, mi aspetto che i commenti incorporati vengano caricati per gli utenti che hanno effettuato l’accesso al forum, ma non per quelli che non sono loggati. Questo corrisponde a ciò che stai riscontrando?
Mi aspetto che i commenti incorporati vengano caricati per gli utenti che hanno effettuato l’accesso al forum, ma non per quelli che non hanno effettuato l’accesso. Questo corrisponde a ciò che stai osservando?
Effettivamente sembra essere così. Sono riuscito a riprodurre questo comportamento sia su Google Chrome che su Firefox. Tuttavia, la discussione non viene caricata in modalità privata su nessuno dei due browser; non so se ciò significhi qualcosa. Ma immagino che ci indichi comunque di aggiornare la categoria, in modo che possa essere visibile a tutti.
Grazie. Dopo aver modificato la categoria e, nella scheda Sicurezza, aver aggiunto “tutti” con permessi “crea/rispondi/visualizza”, l’embedding funziona di nuovo.
Quindi, dopo l’ultimo aggiornamento di Discourse, tutte le pagine incorporate segnalano un errore ![]()
Un messaggio di errore tipico che vediamo ora è più o meno questo, che sembra indicare che il browser sta rimuovendo l’header Referer, causando il fallimento dei controlli di validazione del codice di incorporamento di Discourse:
Referer: `https://www.comses.net/`
Il referer non è stato inviato o non corrisponde a nessuno dei seguenti host:
* www.comses.net/codebases/.*
Pagina di esempio: Artificial Anasazi
Su Chrome, anche con Privacy Badger e tutte le altre estensioni disattivate, il messaggio di errore relativo al referer appare sempre ed è probabilmente dovuto a A new default Referrer-Policy for Chrome - strict-origin-when-cross-origin | Blog | Chrome for Developers AGGIORNAMENTO: ora funziona per gli argomenti esistenti dopo aver aggiunto un’header Referrer-Policy esplicito al sito di origine (ad esempio, https://www.comses.net), quindi per haproxy qualcosa come: http-response set-header Referrer-Policy "no-referrer-when-downgrade"
Su Firefox e Chrome, le pagine con argomenti esistenti funzionano, ma le pagine che tentano di creare un nuovo argomento falliscono come in questo caso: The Bronze Age Collapse model (BACO model).
Ho modificato la configurazione del nostro haproxy per impostare gli header di risposta per Content-Security-Policy frame-ancestors, il che ha risolto l’errore X-Frame-Options ALLOWALL not recognized non valido in Firefox, ma ora la richiesta va in timeout e alla fine genera un errore 400 Bad Request dal nostro forum Discourse..
L’errore sembra essere correlato a postMessage:
Impossibile eseguire 'postMessage' su 'DOMWindow': l'origine di destinazione fornita ('https://forum.comses.net') non corrisponde all'origine della finestra di destinazione ('https://www.comses.net').
Avrò più tempo per approfondire verso la fine di questo mese, quando avrò più tempo libero, ma volevo fare un brain dump mentre è ancora relativamente fresco - spero che qualcuno trovi una soluzione alternativa nel frattempo! ![]()
Mi succede lo stesso. Spero che qualcuno qui possa dare una mano con questo errore. Nel mio caso ho un blog di test e un blog ufficiale… entrambi realizzati con Webflow… nel blog di test tutto funziona bene, ma nel blog live restituisce questo errore…
### Errore di incorporamento
Referer: `https://www.pynk.io/blog/what-to-invest-in-look-around-you`
Il referer non è stato inviato o non corrisponde a nessuno dei seguenti host:
[spazio vuoto qui]
Scusa per il ritardo nella risposta. Puoi provare ad aggiungere discourseReferrerPolicy: 'no-referrer-when-downgrade' all’oggetto DiscourseEmbed impostato nel frammento di codice di incorporamento? Qui trovi un esempio completo di un frammento di codice che aggiunge questa proprietà: Embed Discourse comments on another website via Javascript - #353.
Se lo provi, facci sapere se risolve il problema per te.
Penso che questo sia stato risolto qui: Embed Discourse comments on another website via Javascript - #365. In quel caso, il problema era un sottodominio www mancante nel record dell’host incorporabile di Discourse.
Modifica: questo problema è stato ora corretto nel codice principale di Discourse. Non è più necessario impostare la variabile discourseReferrerPolicy su 'no-referrer-when-downgrade'. Discourse imposta ora la politica del referrer su 'no-referrer-when-downgrade' per impostazione predefinita. Per i dettagli su questo, vedi https://meta.discourse.org/t/embedding-discourse-comments-via-javascript/31963#setting-the-referrer-policy.
Aggiungendo discourseReferrerPolicy il problema è stato risolto - grazie, @simon!! ![]()
Questo potrebbe causare problemi con l’SSO. Ho un current.discourse.example che utilizza sso.discourse.example come host SSO. Quando sei loggato, l’elenco dei topic viene visualizzato correttamente. Ma quando sei anonimo, non viene mostrato e appare l’errore sopra indicato. L’URL /embed/topics?... mostra una pagina vuota.
Penso – o spero – che questo dovrebbe essere risolto con:
Content-Security-Policy: frame-ancestors https://current.discourse.example https://sso.discourse.example;