Poiché Discourse non utilizza Apache, come si può proteggere con password, ad esempio, un ambiente di staging (un droplet Digital Ocean con Discourse Docker) come si farebbe con .htaccess (Apache)?
Non è presente Apache, ma NGINX è in esecuzione all’interno del container Discourse. Questo argomento potrebbe essere d’aiuto:
3 Mi Piace
Perfetto, grazie @david 
1 Mi Piace
L’ho appena aggiunto, ma ora ogni immagine da https://cdn-uploads.example.com e https://cdn-origin.example.com richiede l’inserimento della password di autenticazione. Esiste un modo per proteggere solo https://discourse.example.com?
Altrimenti ora ottengo questo:
Non sono sicuro esattamente di come ottenere ciò, ma forse qualcun altro interverrà se ha qualche idea. Dovrebbe essere possibile con alcune modifiche alla configurazione di nginx.
Come soluzione temporanea e dato che si tratta di un server di staging, potresti semplicemente disabilitare la CDN? Se utilizzi lo stesso dominio per le risorse, l’intestazione di autenticazione verrà inviata automaticamente, quindi non dovrai più inserire la password di autenticazione.
1 Mi Piace
Sì, certo, se questo è l’approccio consigliato per un ambiente di staging quando si utilizzano bucket S3 per backup e upload, nonché CloudFront come CDN per gli upload e come origine per la produzione.
Non è davvero necessario avere tutto questo per un ambiente di staging?
Questa modifica a nginx non dovrebbe assolutamente influire sui caricamenti su S3 o sulla CDN S3. NGINX non è coinvolto in alcun modo in quel processo. Avevo assunto che stessi utilizzando caricamenti locali con una CDN?
La situazione ideale è configurare il sito di staging in modo identico al sito di produzione.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-east-1
DISCOURSE_S3_ACCESS_KEY_ID: XXXXXXXXXXXXXXXXXXXXXX
DISCOURSE_S3_SECRET_ACCESS_KEY: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
DISCOURSE_S3_CDN_URL: https://cdn-uploads.example.com
DISCOURSE_S3_BUCKET: example-uploads
DISCOURSE_S3_BACKUP_BUCKET: example-backup
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_CDN_URL: https://cdn-origin.example.com
E il dominio principale per lo staging è attualmente https://staging.example.com
Tuttavia, con il codice proposto, vengo ancora richiesto di autenticarmi per ogni singola richiesta da cdn-origin quando accedo a https://staging.example.com
Aggiornamento per chi riscontra lo stesso problema:
Abbiamo dovuto abilitare l’elaborazione delle intestazioni Authorization in CloudFront per cdn-origin.
Sembra che non mi sia stato richiesto l’autenticazione per cdn-uploads.
Funziona ora.
2 Mi Piace
Ho attivato l’opzione ‘Login richiesto’ sul sito di staging. Puoi farlo tramite una variabile d’ambiente nel file app.yml, in modo che rimanga persistente.
Non è abbastanza buono se Google o chiunque altro sta trovando il sito. Comunque ora funziona.
1 Mi Piace
Vedranno il sito, ma non potranno visualizzare alcun contenuto. Giusto?
Nel nostro caso, dobbiamo essere in grado di vedere come il sito reagisce anche agli utenti anonimi. Quindi va bene, ora funziona con basic_auth.
2 Mi Piace
Beh, mi hai fatto ripensare a come faccio questo!
Ciao @Terrapop
Ecco un’idea per te, ed è così che lo facciamo noi.
Se esegui il tuo ambiente di staging dietro Apache2 (o nginx) come reverse proxy, puoi impostare le regole di accesso nel reverse proxy come faresti con .htaccess, con cui sei già familiare.
Ci sono una miriade di vantaggi nell’eseguire Discourse dietro un reverse proxy e la facilità di controllo degli accessi è solo uno dei benefici.
Spero sia utile.
Esiste una guida pratica infallibile per nginx? Stiamo ospitando su DigitalOcean tramite Droplet e Docker.
Ciao @Terrapop
Su Meta ci sono molti ottimi tutorial su come configurare Discourse in una configurazione a “due container” dietro un reverse proxy.
Puoi provare a cercare su Meta:
two container reverse proxy
Spero che questo ti sia utile.
Tieni presente che per la semplice messa in staging, molte persone non configurano “due container” e lo fanno solo in produzione; ma se vuoi replicare esattamente l’ambiente di produzione, allora la configurazione a “due container” è sicuramente un’ottima scelta. Tuttavia, non hai bisogno di “due container” per eseguire un’applicazione web dietro un reverse proxy. Io eseguo regolarmente applicazioni web ROR e Docker dietro un reverse proxy sia in produzione che in sviluppo.
3 Mi Piace
Ciao. Vorrei solo sapere come avete correttamente inserito gli header di autorizzazione nella whitelist in CloudFront? Ho aggiunto “auth_basic” in app.yml come indicato sopra. La protezione con password funziona quando si naviga da desktop, ma ottengo questo messaggio quando navigo da mobile (dopo aver inserito nome utente e password):
Ho questa configurazione in “cdn-origin”:
Politica “whitelist-authorization-headers”:
Sono abbastanza nuovo di CloudFront e potrei semplicemente aver trascurato qualcosa di molto ovvio (per la configurazione mobile).