Per un forum completamente privato (senza accesso anonimo), la mancanza di un’opzione per i media sicuri nella configurazione di archiviazione locale predefinita mi sembra una grave omissione. Non mi sorprenderebbe se molte persone che gestiscono forum privati non si rendessero conto che tutti gli allegati dei loro post sono accessibili pubblicamente (se si conosce l’URL). Se il testo del mio post non può essere accessibile in modo anonimo, intuitivamente penserei che nemmeno gli allegati del post lo siano.
Vale la pena aprire una issue richiedendo questa funzionalità per vedere che tipo di supporto riceverebbe? Ne esiste già una? Questa singola questione è attualmente un ostacolo insormontabile per il mio piccolo gruppo con risorse limitate, che sta cercando di attivare Discourse in un ambiente in cui possediamo già l’hardware di hosting e non vogliamo pagare per l’archiviazione cloud (specialmente ai prezzi di AWS S3) solo per garantire che i nostri media non siano visualizzabili in modo anonimo.
Inoltre, perdonate la possibile ingenuità di questa domanda. Ma esiste già il supporto per bucket distinti per gli upload e i backup, giusto? Sarebbe difficile supportare un terzo bucket per gli upload sicuri? Gli upload pubblici andrebbero nel bucket pubblico, gli upload sicuri nel bucket sicuro, e non sarebbero necessari ACL per oggetti singoli. E se lo stato di sicurezza di un oggetto cambiasse, potrebbe semplicemente essere spostato tra i bucket?
Penso che richieda un bel po’ di lavoro. Almeno una giornata, ma forse una settimana?
L’hosting di Cdck, che finanzia lo sviluppo, utilizza S3 per i caricamenti, quindi l’interesse si concentra solo sui siti auto-ospitati che richiedono il login e non hanno budget per S3.
Se i tuoi utenti vedono i link per condividere le tue risorse, potrebbero semplicemente scaricarle per condividerle. Non sembra un grosso problema.
Non sono pazzo a pensare che sia strano che il testo dei post sia protetto ma gli allegati no, giusto?
C’è però una grande differenza tra condivisione intenzionale e accidentale. Ovviamente, non esiste un modo reale per prevenire la prima. Ma la seconda può verificarsi proprio ora semplicemente perché le persone non comprendono la tecnologia sottostante. Considera le notifiche email per i post che includono link a immagini allegate, inviate inavvertitamente a utenti non iscritti. Un’opzione per rimuovere gli allegati dalle email, non legata alla funzionalità dei media sicuri, potrebbe essere una buona alternativa in questo caso.
Anche quando le persone condividono intenzionalmente i link agli allegati, potrebbero aver semplicemente dimenticato che provenivano da una categoria protetta. Ma in un mondo ideale, il link all’allegato dovrebbe essere inutile per chiunque non abbia accesso a quella categoria.
Un bug attuale o futuro in una delle implementazioni S3 potrebbe anche potenzialmente consentire l’enumerazione anonima delle risorse in un bucket o la capacità di indovinare e forzare gli URL degli oggetti. In un mondo ideale, vorrei che la mia interfaccia S3 on-prem fosse isolata dal resto di Internet tramite firewall, in modo che solo il server Discourse possa raggiungerla direttamente.
Non sei impazzito: implementare caricamenti sicuri per configurazioni diverse da S3 è certamente qualcosa contro cui non mi oppongo a sviluppare. È solo che non abbiamo alcuna urgenza o spinta per realizzare questa funzionalità e il cambiamento non è banale.
Occasionalmente abbiamo tirocinanti e progetti di prova; questo è certamente un tipo di progetto che potrebbe rientrare in una di queste categorie.
Ho una piccola soluzione che credo possa garantire caricamenti sicuri per i siti che richiedono il login.
In sostanza, configurate Authentication Based on Subrequest Result | NGINX Documentation per i caricamenti. L’unico problema è che non riesco a trovare un URL che restituisca un 403/401 quando l’opzione “login-required” è attiva, quindi l’accesso a un caricamento senza essere loggati genera un errore 500. Questo accadrebbe solo se qualcuno avesse un URL di caricamento e tentasse di accedervi senza essere loggato, quindi non sembra un problema grave.
È qualcosa del genere:
# JP
location = /auth {
internal;
proxy_pass http://discourse/categories;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
# END JP
location ~ ^/uploads/ {
auth_request /auth; #$JP
# NOTA: è davvero fastidioso non poter definire le intestazioni
# a livello superiore e ereditarle.
#
Non abbiamo intenzione di creare una funzionalità specifica per i bucket dedicata agli upload sicuri, né prevediamo di rendere gli upload sicuri compatibili con configurazioni non S3 o configurazioni senza ACL. Potremmo valutare questa possibilità in futuro se ci sarà una domanda sufficiente da giustificare l’impiego di tempo e risorse per questo progetto.
Perché sta utilizzando https://hashhackersforum.s3.us-east-2.amazonaws.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc invece di https://forum.cdn.hashhackers.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc, dato che ho inserito correttamente l’URL del CDN?
Non mi dispiace ignorarlo, ma abbiamo attivato i media sicuri, il che significa che non è possibile utilizzare un CDN. Questo messaggio non dovrebbe essere visualizzato sui siti con secure_media abilitato.
Una CDN può comunque essere utilizzata per tutte le risorse JS, rendendo il tuo sito molto più veloce da visualizzare per gli utenti di tutto il mondo.
Dopo aver aggiornato alla versione 2.8.0.beta1, i miei badge che utilizzano URL S3 autenticati non funzionano. Prima dell’aggiornamento funzionavano correttamente.
Ho controllato la tabella uploads e il valore della colonna secure è true.
Ah… ancora un posto che rende sicure le caricazioni che non dovrebbero esserlo. I badge non dovrebbero essere contrassegnati come sicuri perché sono essenzialmente immagini pubbliche, come avatar, loghi delle categorie e altre cose. Dovrò applicare una correzione per assicurarmi che le immagini dei badge non siano contrassegnate come sicure e uno script di migrazione per correggere quelle che lo sono già.
Sono sorpreso che abbia funzionato per te in qualche modo; nulla nella versione 2.8.0 avrebbe dovuto influenzare questo aspetto.
Grazie per la tua risposta. È la prima volta che uso Ruby e sono entusiasta di quanto sia chiara questa lingua. Dopo alcune ore di debug, credo di aver individuato dove guardare. Immagino di aver fatto esattamente l’opposto di quanto hai detto Ho inserito alcune righe nel modello Badge e ora riesce a caricare le immagini. Ho anche notato che c’è un flag for_site_setting. Credo che si basi su queste informazioni per regolare l’ACL per gli oggetti su S3, impostando il valore falso per quella colonna.
app/models/badge.rb
def image_url
if image_upload_id.present?
return upload_cdn_path(image_upload.url) if !image_upload.url.include?(SiteSetting.Upload.absolute_base_url)
uri = URI.parse(image_upload.url)
Rails.application.routes.url_for(
controller: "uploads",
action: "show_secure",
path: uri.path[1..-1],
only_path: true
)
end
end
Darò un’occhiata a cosa cambierà nel prossimo aggiornamento per saperne di più.
Potresti dirmi qual è la versione migliore da utilizzare in produzione?
Grazie!
Spero di poter contribuire ulteriormente al codice in futuro.
La modifica che hai apportato al modello badge funzionerà sicuramente, ed è fantastico che tu sia riuscito a realizzarla al primo utilizzo di Ruby! Tuttavia, procederò comunque a correggere il problema principale per cui i badge non dovrebbero essere contrassegnati come sicuri.
Il nostro ramo tests-passed è la versione migliore da utilizzare in produzione, poiché riceverà tutte le correzioni più recenti non appena saranno disponibili, anche se alcune persone potrebbero preferire rimanere sul ramo beta, che riceve correzioni e modifiche ogni qualche settimana circa.
Ti farò sapere quando avrò completato la correzione per i badge contrassegnati come sicuri.
…ma mi chiedo se il problema sia correlato al tuo commento qui?
È supportato l’upload di avatar da parte degli utenti quando il caricamento di media sicuri è attivo? Al momento ricevo un errore, ma mi chiedo se ciò sia dovuto al fatto che gli avatar vengono caricati nello stesso bucket in cui l’accesso pubblico non è consentito…
1 Mi Piace
Canapin
(Coin-coin le Canapin)
Ha separato questo argomento il
126
Ho recentemente rinominato “media sicuri” e le impostazioni correlate in “upload sicuri” poiché non si applica solo a immagini/video ecc. e tutti in generale lo chiamano comunque upload sicuri. Il commit principale pertinente è qui:
L’OP di questo argomento è stato ora aggiornato per riflettere questo.
Ho inserito alcune righe nel modello Badge e ora riesce a caricare le immagini. Ho anche notato che c’è un flag for_site_setting. Credo che si basi su queste informazioni per regolare l’ACL per gli oggetti su S3, impostando il valore falso per quella colonna.