Come rilassare la Content Security Policy

Sviluppatore
1

Ciao

Vorrei fare dei test su Discourse senza necessariamente passare per il suo nome di dominio pubblico configurato. Ad esempio, se Discourse è stato installato e configurato come https://uat.mysite.com, posso ovviamente aprire il mio browser e navigare su https://uat.mysite.com, il che significa che il mio browser uscirà dalla mia rete interna verso Internet pubblico per risolvere il nome di dominio al suo indirizzo IP pubblico e caricare le pagine tramite il suo indirizzo IP pubblico.

Ho appena provato a navigare su Discourse tramite l’indirizzo IP interno del server (ad esempio 192.168.1.2 mostrato di seguito) e giustamente non si carica a causa della Content Security Policy. Gli errori che sto ricevendo sono del seguente tipo.

Refused to load the script 'http://192.168.1.2:12000/assets/locales/en-a9c88e45eb548bd7c807aecfd37d218891e213b5c1fd254857e0f16c72d73996.js' because it violates the following Content Security Policy directive: "script-src http://uat.mysite.com/logs/ http://uat.mysite.com/sidekiq/ http://uat.mysite.com/mini-profiler-resources/ http://uat.mysite.com/assets/ http://uat.mysite.com/brotli_asset/ http://uat.mysite.com/extra-locales/ http://uat.mysite.com/highlight_js/ http://uat.mysite.com/javascripts/ http://uat.mysite.com/plugins/ http://uat.mysite.com/theme-javascripts/ http://uat.mysite.com/svg-sprite/ 'sha256-rwfDVOTzygQmkOwFNAeX564B66beHoel4+gRLgQUgHg='". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

                                           --------------------------------------------
                                          |                                             |
                                           ------------
uat.mysite.com risolve a 98.1.2.3 -->   |  IP Pubblico |  Server che esegue Discourse.     |
                                          |  96.1.2.3. |
                                           ------------                                 |
                                          |                                             |
                                          |                  ----------------           |
                                          |                  |  IP Privato  |           |
                                          |                  | 192.168.1.2  |           |
                                           --------------------------------------------
                                                                         ^
                                                                         |
192.168.1.2   ------------------------------------------------------------

Il motivo per cui vorrei accedere a Discourse tramite l’IP interno del server è perché voglio fare dei test. Ad esempio, se voglio fare dei test di caricamento, non voglio necessariamente caricare la rete che serve Internet. Oppure, se voglio installare un’istanza di test sul mio laptop o su un server di build senza necessariamente configurare il DNS.

Suppongo di poter sempre sovrascrivere questo impostando una voce personalizzata in /etc/hosts, ma c’è un modo per disabilitare CSP o impostarlo per fidarsi di altre origini per consentire i test?

1 Mi Piace
2

Quindi configura la tua macchina per risolvere quell’indirizzo nell’IP locale del server discourse. Ci sono molti modi per farlo, ma dipendono dal sistema operativo, quindi dovresti includere il sistema operativo nella tua ricerca su Google. (In Linux e penso anche in Mac, puoi semplicemente modificare /etc/hosts.)

1 Mi Piace
3

Ho provato anche /etc/hosts ma ho ancora lo stesso errore a causa di CSP. Pensavo che ci fosse un flag o un’impostazione che potesse essere utilizzata per attivare questa opzione, in modo da consentire agli sviluppatori di fare tutto all’interno del proprio laptop senza dover configurare una soluzione DNS. Guardando Install Discourse on macOS for development - documentation / developers - Discourse Meta sembra che si avvii in qualcosa che funziona con http://localhost:3000 piuttosto che con un IP.

La sfida che ho è che ho un’automazione per installare Discourse e voglio usare lo stesso processo per configurare ambienti di sviluppo, UAT e produzione e non voglio necessariamente che l’ambiente di sviluppo sia accessibile da Internet, il che sembra essere un requisito al momento perché necessita di risolvere un FQDN corretto. Ci sono molteplici casi d’uso, uno dei quali è, ad esempio, automatizzare l’aggiornamento di Discourse nell’ambiente di sviluppo ogni settimana ed eseguire una serie di test per vedere se qualcosa si rompe.

Comunque, se c’è un modo per allentare il requisito per consentire l’accesso diretto tramite IP, sarebbe utile saperlo. Altrimenti, immagino che l’unica altra soluzione sia creare un piccolo servizio DNS e poi configurare il laptop per utilizzare il servizio DNS personalizzato, ma sembra essere un po’ complicato.

4

C’è un’impostazione del sito chiamata content security policy. Puoi deselezionarla e salvare per disabilitare CSP.

Finché questo non viene fatto in un’istanza di produzione, va bene.

3 Mi Piace
5

Non è una buona idea. Non funzionerà mai. Un ambiente di sviluppo è necessariamente diverso in quanto ha asset precompilati e un sacco di altre cose che rendono impossibile lo sviluppo. A meno che tu non stia sviluppando plugin, non hai affatto bisogno di un ambiente di sviluppo. Quindi, se questo è il caso, allora puoi avere il tuo ambiente di sviluppo come un’installazione docker, semplicemente non è quello che verrebbe chiamato un ambiente di sviluppo qui.

Vuoi lanciare i tuoi ambienti di staging e produzione usando docker come descritto nell’installazione standard.

3 Mi Piace
6

Ciao! Lo faccio regolarmente, ma con installazioni Docker. Supponendo che tu utilizzi la nostra installazione Docker standard in produzione, allora per i tuoi test di accettazione dovresti usare la stessa cosa. C’è un ampio margine di differenze tra le installazioni dev e Docker (configurazione, versioni dei pacchetti gem e JS, ecc.) che possono trasformarsi in emicranie al momento del deploy.

Le installazioni Docker utilizzano e impongono HTTPS per impostazione predefinita. A meno che tu non voglia personalizzare il template del container (che ho scoperto avere una certa complessità nascosta), puoi semplicemente disattivare l’imposizione di HTTPS con un’altra impostazione del sito.

Questo è il mio snippet per “rilassare la sicurezza in un’installazione Docker locale”, che può essere altrettanto facilmente ripristinato prima di andare in produzione:

SiteSetting.content_security_policy = false
SiteSetting.force_https = false

Quindi si tratta solo di far sì che il tuo browser sia in grado di trovare la porta 80 sul container Docker a http://uat.mysite.com – nota che userai http invece di https.

Per questo, il trucco di /etc/hosts di @pfaffman è la strada giusta; dettagli per ogni sistema operativo qui.

2 Mi Piace