Das Problem ist, dass CDN das fehlerhafte Verhalten erhält, was du ausdrücklich nicht willst. Nur Nicht-CDN funktioniert korrekt, indem beim Klicken auf „Herunterladen
Ah ja, dann sollten wir das beheben.
Das ist verständlich. Gibt es Beispiele für die Anpassung des Lightboxes, die ich als Ausgangspunkt nutzen kann?
Dies ist überhaupt nicht leicht zu hacken, wie hier zu sehen:
Sie müssten sich Magnific Popup: Responsive jQuery Lightbox Plugin durchlesen und prüfen, ob es sich irgendwie dynamisch neu konfigurieren lässt.
Schade, ich schaue mal, ob ich eine Lösung finde.
Nur aus Neugier – warum wählt Discourse hier eine ‘Herunterladen’-Aktion statt ‘Vollgröße anzeigen’? Aus Nutzersicht scheint das Anzeigen der Vollgröße eine häufigere Aktion zu sein.
Ich dachte, es handele sich um ein MIME-Problem, aber beim Blick auf den Header könnte es sein:
x-download-options: noopen
Dies verhindert, dass eine Datei beim Herunterladen geöffnet wird. Ich hoffe, Sam kann das klären.
Das liegt wohl an @codinghorror. Das ist eine Möglichkeit, den ursprünglichen Dateinamen des Uploads sauber beizubehalten, was manchen Nutzern wichtig ist. Außerdem scheint das das zu sein, was Flickr ebenfalls so handhabt.
Ich denke nicht, dass wir daran etwas ändern werden. Wir werden die App lediglich über eine dedizierte Route oder Ähnliches einen Proxy dafür stellen lassen. Die Anzahl der Nutzer, die auf „Herunterladen“ klicken, ist verschwindend gering, sodass ein Umgehen des CDNs hier akzeptabel sein könnte. Wie auch immer, @pmusaraj kann entscheiden, was die beste Lösung ist. Soweit ich das sehe, müssen wir entweder AWS anweisen, uns eine signierte URL mit einer speziellen Content-Disposition zu geben, oder die Datei proxyen. In beiden Fällen würde das ein Umgehen des S3-CDNs bedeuten. Wenn wir über die App proxyen, können wir zumindest das App-CDN nutzen.
Nach etwas mehr Recherche scheint content-disposition: attachment; und x-download-options: noopen für dieses Verhalten verantwortlich zu sein.
Ich verstehe, dass dies das Wie und nicht das Warum ist. Wenn es jedoch aus Sicherheitsgründen ist, ergibt das absolut Sinn.
Dieser PR sollte dies beheben, indem:
- ein
data-download-hrefzum Lightbox-Download-Link hinzugefügt wird, wenn S3-Uploads aktiviert sind - die verwendete URL das neue Short-URL-Schema mit einem
dl=1-Parameter nutzt, wodurch der Controller eine signierte S3-URL mit der korrekten Content-Disposition und dem Dateinamen generiert
Mit anderen Worten: Der Download-Link in der Lightbox sieht nun so aus: /uploads/short-url/mTGbg4Ld2iBYAbfTvEjGXP2LtVm.pdf?dl=1, was auf eine signierte S3-URL mit content-disposition: "attachment; filename=original.png" umleitet.
Ich denke, dies ist die einfachste und direkteste Option. Ein Proxy über die App wäre etwas weniger effizient, da die heruntergeladene Datei von S3 zum Discourse-Server und dann zum Client weitergeleitet werden müsste.