Persönliche öffentliche Dateien (gelöst) (Webframeworks, Sonstige Fragen zur Webprogrammierung mit Perl)

[thread]21205[/thread]

Persönliche öffentliche Dateien [gelöst]

Tags: perl5 Ähnliche Threads

Leser: 8

Articles: hide open all | hide show old branches

+13 replies
bianca

2021-06-26 10:36

User since
2009-09-13
7016 Artikel
BenutzerIn

Guten Morgen!

In dieser Frage geht es zunächst um die richtige Strategie. Es gibt einen passwortgeschützten persönlichen Bereich in einer Perl CGI-Webanwendung wo man auch Dateien hochladen kann. Um diese anzuschauen/zu öffnen legt ein Script im Moment des Anklickens die Datei im öffentlichen Bereich des Webservers in ein Unterverzeichnis mit der Session-ID als Name und sendet dem Browser ein HTTP 303 dort hin.

Das mache ich extra so, damit der Browser je nach installierten Komponenten (z. B. PDF-Reader, Office usw. je nach Datei Extension) die Datei direkt in der zugewiesenen lokalen App anzeigt/öffnet und nur im Notfall den hier unerwünschten Download Dialog anzeigt. Stichwort MIME sniffing.

Das ganze Unterverzeichnis wird dann später wieder gelöscht, sobald der User sich abmeldet oder seine max. Anmeldezeit abläuft, Zuordnung über erwähnte Session-ID.

Klappt super!

Aber: die Datei liegt viel zu lange völlig schutzlos in diesem öffentlichen Verzeichnis.
Wie bekomme ich im Script mit, wenn der Browser die Datei fertig geladen hat, damit ich die sofort wieder löschen kann?
Oder kann man sowas wie einen Verzeichnisschutz definieren nur für diesen Benutzer?
Oder kann man die Datei irgend wie zum Browser streamen wie es der Webserver macht? Ich hatte in meinen Versuchen meistens den unerwünschten Download Dialog anstatt die Anzeige der Datei.
Wie würdet ihr das lösen oder habt es vlt. schon mal gelöst?
Auch ganz andere Ansätze würden mich interessieren. Ich kann das oben beschriebene auch komplett verwerfen und gegen eine andere Lösung ersetzen.

Danke für alle Hinweise
10 print "Hallo"
20 goto 10
- +2 replies
- GwenDragon
  
  2021-06-26 11:03
  
  User since
  2005-01-17
  14748 Artikel
  Admin1
  
  Idee: Zugriffschutz per OTP und Datei per Skript an Browser senden (nicht in ein offenen verzeichnis leegen).
  die Drachin Gwen
  
  Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
  - gelöscht 2021-10-11 18:26
- +7 replies
- haj
  
  2021-06-26 18:54
  User since
  2015-01-07
  555 Artikel
  BenutzerIn
  Zunächst mal: Du kriegst nicht wirklich verläßlich mit, wann der Browser eine Datei fertig geladen hat, zumal dann nicht, wenn eine andere Anwendung im Spiel ist. "Sicher" geht das also nur, wenn Du tatsächlich den Request selbst auf Berechtigung prüfst.
  
  Wie GwenDragon schon schreibt: Ein übliches Verfahren ist, die Datei nicht per Apache ausliefern zu lassen (denn ich vermute, das ist mit "Ablegen im öffentlichen Bereich" gemeint), sondern mit einen Skript. Ein One-Time-Passwort wäre dann auch nicht unbedingt nötig, Du kannst mit der "normalen" Autorisierung Deines passwortgeschützten Bereichs arbeiten. Das Skript prüft die Autorisierung, liest dann die gewünschte Datei und baut die Response zusammen.
  
  Dabei gibt es einiges zu beachten, was der Apache auch so still und leise im Hintergrund macht:
  
  MIME sniffing hast Du genannt. Du musst allerdings nicht sniffen, das macht Apache auch nicht. Der geht auf eine Datei mit Namen mime.types (konfigurierbar), auf meinem System hat die grade 845 Einträge. Es gibt auch einen Modul MIME::Types, der dabei hilft, aus einer Dateierweiterung den Typ zu ermitteln. Du könntest schon beim Hochladen der Datei prüfen, ob Deine Anwendung dafür einen MIME-Typ kennt und falls nein, den Anwender danach fragen. Ein richtiger Content-Type verhindert den Download-Dialog!
  Der MIME-typ, den Du für eine Datei ermittelst, kann aus Hygienegründen noch auf Verträglichkeit mit dem Accept: Header des Requests geprüft werden. MIME::Types hilft auch dabei. Das Problem stellt sich nicht, wenn Deine Anwendung die Auswahl der anzeigbaren Dateien mit normalen <a href=....>-Elementen anbietet. Es hilft aber beispielsweise gegen Fehler wie <img src="a.pdf">.
  Etwas mühsamer: Moderne PDF-Reader fordern in jedem Request nur "Häppchen" der gesamten Datei an. Das passiert mit dem Range: Header, der auch mehrfach in einem Request vorkommen kann (wenn der Reader z.B. Bookmarks und eine Seite lädt). Es funktioniert zwar, wenn die Anwendung das ignoriert und immer das gesamte Dokument zurückliefert (Plack::App:File macht das), aber es ist alles andere als effizient. Du müsstest also die Datei aufmachen und nur die gewünschten Portionen zur Response zusammenbauen.
  - +5 replies
  - bianca
    
    2021-06-28 10:00
    
    User since
    2009-09-13
    7016 Artikel
    BenutzerIn
    
    Moin!
    
    Es gibt noch einen Grund, warum ich das im Moment so mache. Und zwar steht in der URL Zeile der echte Dateiname der Datei und vor allem: wenn ich es Rechtsklicke zum speichern steht im Dialog der richtige Dateiname und nicht der Scriptname drin.
    
    Es "fühlt" sich eben wie üblich beim Anzeigen von Dateien im Browser an.
    
    Wie bekomme ich dieses Verhalten bei Auslieferung per Script hin?
    10 print "Hallo"
    20 goto 10
    - +3 replies
    - haj
      
      2021-06-28 11:11
      
      User since
      2015-01-07
      555 Artikel
      BenutzerIn
      
      Du kannst auch bei einem Skript den Dateinamen an die URL hintendranhängen. Wenn Dein Skript download.pl heißt, dann kannst Du die URL download.pl/datei.pdf zum Runterladen von datei.pdf anbieten. Wenn Du überhaupt alles mit einer einzigen URL /app erledigst, kannst Du zur Klarstellung auch /app/download/datei.pdf in deine Hyperlinks schreiben.
      
      Apache gibt das, was nach den Schrägstrich des Programms kommt, als Umgebungsvariable PATH_INFO an das Skript weiter.
      
      Einen Schritt mehr Aufwand ist es, wenn Du den Dateinamen über ein HTML-form einsammelst. Dann müsste das Skript zunächst eine Redirection auf /app/download/datei.pdf durchführen.
      
      Ach ja, es gibt noch eine weitere Eigenschaft, die Du damit erhältst: Wenn Du für solche URLs GET-Requests zuläßt, dann können Deine Benutzer Bookmarks auf die URL /app/download/datei.pdf setzen und müssen nicht jedesmal über Deine Anwendung gehen.
      - bianca
        
        2021-07-07 10:59
        
        User since
        2009-09-13
        7016 Artikel
        BenutzerIn
        
        2021-06-28T09:11:16 haj
        Wenn Dein Skript download.pl heißt, dann kannst Du die URL download.pl/datei.pdf zum Runterladen von datei.pdf anbieten. Wenn Du überhaupt alles mit einer einzigen URL /app erledigst, kannst Du zur Klarstellung auch /app/download/datei.pdf in deine Hyperlinks schreiben.
        
        Apache gibt das, was nach den Schrägstrich des Programms kommt, als Umgebungsvariable PATH_INFO an das Skript weiter.
        
        Habe ich so gemacht und hat auch fast (sch... Cache) auf Anhieb geklappt :)
        
        2021-06-28T09:11:16 haj
        Einen Schritt mehr Aufwand ist es, wenn Du den Dateinamen über ein HTML-form einsammelst. Dann müsste das Skript zunächst eine Redirection auf /app/download/datei.pdf durchführen.
        
        Ich denke, dass das nicht nötig sein wird. Über das Cookie bekomme ich die Anmelde-ID und über die GET-Parameter das gewünschte Bild. Und $ENV{PATH_INFO} führt zu einem sauber vorbelegtem Dateinamen im "Bild speichern unter"-Dialog.
        Perfekt!
        Bedanke mich tüchtig bei dir!
        
        2021-06-28T09:11:16 haj
        Wenn Du für solche URLs GET-Requests zuläßt, dann können Deine Benutzer Bookmarks auf die URL /app/download/datei.pdf setzen und müssen nicht jedesmal über Deine Anwendung gehen.
        
        Ja das stimmt. Muss ich auf jeden Fall berücksichtigen, weil der User das ungefragt aus der Adressenzeile kopiert. Von daher sind Benutzernamen, Anmelde-ID's und Passwörter im Request erst recht tabu.
        
        Nochmal danke auch an alle Mitleser!
        10 print "Hallo"
        20 goto 10
      - gelöscht 2021-10-11 18:26
    - gelöscht 2021-10-11 18:26
  - gelöscht 2021-10-11 18:26
- +2 replies
- bianca
  
  2021-06-27 08:45
  
  User since
  2009-09-13
  7016 Artikel
  BenutzerIn
  
  Danke euch beiden!
  
  Das OTP klingt im Moment für den Endnutzer etwas umständlich. Ich versuche mich zunächst nochmal mit haj's Tipps an der Auslieferung per Script.
  
  P.S.: Sind wir drei eigentlich mittlerweile die Einzigen hier?
  10 print "Hallo"
  20 goto 10
  - Gast Gast
    
    2021-07-01 17:02
    
    Nicht ganz - es gibt noch vereinzelte Leser
    Last edited: 2021-07-01 17:09:36 +0200 (CEST)
- gelöscht 2021-10-11 18:26

View all threads created 2021-06-26 10:36.