webEdition - Forum

Hallo zusammen,
wie bereits in einem schon ein paar Jahre alten Thread (http://forum.webedition.org/viewtopic.php?f=87&t=11686) diskutiert, möchte ich für registrierte Kunden Download-Dateien (zB PDF) anbieten, welche aber nicht über die Direkt-URL aufrufbar sind (und somit auch von Suchmaschinen nicht ausgelesen werden können. Nach der Anleitung im og Thread sieht meine Struktur so aus:

index.php download.php Soweit funktioniert alles wunderbar. Wenn nun aber das Verzeichnis /daten/ via .htaccess geschützt wird (um eben die Direkt-URL zu verhindern), sind die heruntergeladenen Dateien 0 kB groß und somit nicht brauchbar. Ich hätte in der .htaccess schon alles probiert (von "deny" bis "redirect").

Hat hier jemand einen Tipp, woran's hakt? Vielen Dank im Voraus!

das ist durchaus logisch, daß es so nicht funktioniert. Du willst deine Datei ja ebenfalls per http lesen in $MyDownloadFile baust du dir ja selbst die URL zusammen und innerhalb der htaccess Datei verbietest du dann den Zugriff.

Der Kode für die Linkgenerierung ist auch schon sehr betagt. Den sollte man so besser auch nicht mehr einsetzen - den Block und den Link von Hand auseinanderzunehmen wird früher oder später kaputt gehen.

Bei der hier angerissenen Lösung sollte man auch bedenken, daß sich hiermit nahezu beliebige Dateien des Servers auslesen lassen - zumindest enthält der hier gezeigte Kode keine derartigen Prüfungen. Besser wäre es generell erst mal nur die ID sich übergeben zu lassen und diese dann auf Gültigkeit innerhalb der definierten Bereiche zu prüfen. Die Ausgabe aller Daten ausschließlich als Octetstream läßt im Browser idr. nur einen Speichern Dialog zu und nicht das direkte Öffnen in einer Anwendung.

Hallo Statist,

Ich muss Marc hier recht geben. Der von dir gepostete Code ist steinalt und sollte so eigentlich nicht mehr verwendet werden.

Hast du die Doku Downloads nur für eingeloggte Kunden gesehen? Der berücksichtigt zwar auch nicht alle von Marc genannten Hinweise, aber vielleicht hilft dir das ja ein Stück weiter.

Liebe Grüße,
Sascha

Danke für Eure Antworten. Ja, so funktioniert's, und ist auch "klarer". Allerdings musste ich noch Folgendes in der .htaccess ergänzen:

Hallo zusammen,
dieser Thread ist zwar schon einige Zeit her, das Thema möchte ich dennoch noch einmal anschneiden, da es für mein Projekt von großer Wichtigkeit ist.
Ich habe - so meine ich - alles bezüglich der "download.php" gelesen, allerdings habe ich folgendes Problem:

In meinem Falle geht es nicht um pdf.Dateien, sondern um Bild-Galerien (ausschließlich jpg-Dateien), die nur für angemeldete Kunden zur Verfügung stehen sollen, und zwar für alle angemeldeten Kunden, nicht für einen spezifischen.

Dazu habe ich eine jQuery Galerie eingebaut, die ich mit einer LV type="document" beliefere. Diese läuft im öffentlichen Bereich ohne Probleme, allerdings werden sowohl Thumbnails, als auch die Galeriebilder selbst bei eingeloggten Usern nicht angezeigt (Galeriescript meldet: Grafik konnte unter der URL nicht gefunden werden) - und das, obwohl der URL vom Thumbnail aus absolut korrekt ist.

In einem Verzeichnis "private" befinden sich die Bilder. Das Verzeichnis habe ich mit der .htaccess mit folgendem Inhalt geschützt:

RewriteEngine on
RewriteBase /
# Alle Dateiaufrufe in diesem Verzeichnis werden an die
# Datei "download.php" umgeleitet. Der Pfad zur angeforderten
# Datei wird als Parameter "file" weitergegeben.

RewriteRule (.+) /de/download.php?file=$1
RewriteCond %{REQUEST_FILENAME} !download.php

Zwar konnte ich mit der download.php, in der ich übrigens in den korrekten Document-Root eingetragen habe, den Aufruf bzw. den Download durch Direkteingabe der URL verhindern (bei nicht eingeloggten Usern), aber wie oben schon erwähnt, kann ein eingeloggter User dennoch diese Galerie nicht betrachten.
Schalte ich die .htaccess aus, werden sowohl Thumbnails, als auch die Bilder einwandfrei ausgeliefert.

Nun habe ich noch probiert, die Zeile "header('Content-Type: application/octet-stream');" wie folgt auf den MIME für Bilder zu setzen, aber leider führte auch dies nicht zum Erfolg.
// Download-Header setzen
header('Content-Type: image/jpeg');
header('Content-Disposition: attachment; filename="'.basename($str_file).'"');
// Datei einlesen und ausliefern (ausgeben)
readfile($str_file);

Darüber hinaus habe ich noch das "private"-Verzeichnis einmal auf "Alle angemeldeten Kunden haben Zugriff" zu setzen und in der LV für die Galerie den cfilter="true" gesetzt. Auch das führte nicht zum Erfolg.

Nun bin ich mit meinem Latein etwas am Ende und hoffe, dass mir hier jemand weiterhelfen kann.

Mein Beitrag von oben hat sich erledigt.

Nun funktioniert es - Alles steht und fällt offensichtlich mit der ersten Zeile der download.php:

Statt...
<we:sessionStart/>
<we:ifRegisteredUser>
<?php
$str_file = (string) $_GET['file'];

sollte doch alles in der ersten Zeile stehen...
<we:sessionStart/><we:ifRegisteredUser><?php
$str_file = (string) $_GET['file'];

Hi,
du änderst den Header der Datei, das funktioniert nur wenn vorher noch nichts ausgegeben wurde.
In deinem Fall wurden vorher schon 2 Umbrüche ausgegeben, dann funktioniert das ändern des Leaders nicht mehr.

Grüße Elko

Hallo Elko,

vielen Dank für Deine Antwort.

Nun, ich habe die Umbrüche entfernt, die Datei sieht jetzt so aus:

<we:sessionStart/><we:ifRegisteredUser><?php
$str_file = (string) $_GET['file'];

// Grobe Manipulationen am Pfad abfangen
$str_file = str_replace('../', '..', $str_file);

$str_file = $_SERVER['DOCUMENT_ROOT'].'/content-private/'.$str_file;

// Nur wenn die angeforderte Datei auch existiert...
if (file_exists($str_file))
{
// Download-Header setzen
header('Content-Type: image/jpeg, video/mpeg, application/octet-stream');
header('Content-Disposition: attachment; filename="'.basename($str_file).'"');
// Datei einlesen und ausliefern (ausgeben)
readfile($str_file);
}
?>
<we:else/>
.....

Dennoch bekomme ich die Bild und Video-Dateien nicht ausgeliefert mit einer Ausnahme: im Firefox.
Alle anderen Browser (IE11, Edge, Opera, Vivaldi und Chrome) versagen mit die Dienste und geben mir in der Header-Text-Antwort die Meldung zurück "Sie haben nicht die Berechtigung..... "

Hi,
ich glaube, du hast hier einen Denkfehler.
Das Script ist für deinen Zweck nicht gemacht. Es ist ja gerade _nicht_ dafür gemacht, die Dateien im Browser anzuzeigen, sondern den Download zu erzwingen.
Dass FF die Bilder anzeigt, ist eher ein Fehler. Denn wenn du die Bilder angezeigt bekommst, müsstest du auch den Pfad auslesen können.
Ein Schutz für Binaries ist geplant, aber bisher glaube ich noch nicht umgesetzt.
Ich denke das beste wäre, du würdest das mit .htaccess absichern.

Grüße Elko

Hallo Elko,
an dieser Stelle erst mal recht herzlichen Dank für Deine Rückmeldungen.

Ja, zwischenzeitlich bin ich auch zu der Überzeugung gelangt, dass das so nicht funktionieren kann. Eigentlich enttäuschend, dass es in WE eine solche Unterstützung immer noch nicht gibt. Ich habe daran nun mehr als 8 Stunden probiert und probiert, da ich der Meinung war, dass das Anzeigen von Grafiken und Videos im weitesten Sinnen eh nichts anderes ist, als ein Download - na gut, da beginnen die Feinheiten.

Ich soll die Seite für einen Fotografen machen, der seinen Kunden im geschützten Bereich Galerien und Videos von Hochzeiten u. ä. zur Verfügung stellt bzw. präsentieren möchte - > Fehlanzeige. Eine htaccess wäre zwar möglich, aber das hat mit Professionalität gar nichts mehr zu tun, sieht bescheuert und billig aus und lässt darüber hinaus die eigentlich tolle Kundenverwaltung gänzlich außen vor.

Ich begreife das ehrlich gesagt nicht, dass die Macher das bisher außer Acht gelassen haben. Nun muss ich auf ein anderes CMS ausweichen - und das wegen einer Funktion, die eigentlich eine Selbstverständlichkeit sein sollte.

Irgendwie bin ich gerade richtig sauer!

@Scarabaeus

da ist einiges schon darüber in der Bugbase geschrieben worden, siehe hier
http://qa.webedition.org/tracker/view.php?id=3986
http://qa.webedition.org/tracker/view.php?id=8219
http://qa.webedition.org/tracker/view.php?id=9953

Sofern Du Dich da noch nicht angemeldet hast, tu das doch einfach mal und schreibe was dazu. Ich denke, wie mehr Leute ihr Interesse bekunden, um so eher wird da evtl. was umgesetzt

Also diese Funktion ist keines Wegs Selbstverständlich, hängt stark von der Architektur des CMS ab und ist ebenfalls durchaus auch selbst zu realisieren. In der Bugbase sind ~400 FR's - da wird sortiert und bewertet. Bisher gab und gibt es hierfür kein großes Interesse.

@max

Vielen Dank für Deine Links bzw. Hinweise.

Aber wenn ich den Beitrag von mokraemer so lese, brauche ich mir wohl gar nicht erst die Mühe machen, mich dort anzumelden. Es scheint ohnehin keinen Sinn zu machen.

@mokraemer

Ich finde es sehr schade, dass Du das "scheinbar" geringe Interesse an einer solchen Lösung so in den Vordergrund stellst, während andere CMS eine solche Funktion schon von haus aus liefern. Woher nimmst Du die Erkenntnis, dass es ein geringes Interesse dafür gibt

Das Argument, es käme auf die Architektur des CMS an, kann ich so nicht gelten lassen. Schließlich bin ich mir sicher, dass es so gut wie kein CMS gibt, das von vornherein entwickelt wurde, um eine solche Lösung anzubieten. Vielmehr wurde eine solche Lösung nach meinem dafürhalten im Nachhinein (gemäß den heutzutage immer mehr erforderlichen Anforderungen) implementiert.

Und der Hinweis auf die "eigene Realisierung" scheint mir adhoc nichts zu bringen. Denn was soll ich denn realisieren, wenn das System nicht mitspielt?
Nun ist WE sicherlich ein tolles CMS, mit einer integrierten Kundenverwaltung - die man aber in letzter Konsequenz nicht mehr ohne weiteres nutzen kann.
Einfach nur schade!

Hallo Scarabaeus,

Ich kann verstehen, dass es manchmal frustrierend ist, wenn etwas nicht so klappt wie man sich das vorstellt. Aber lass deinen Frust bitte nicht hier ab.

Deine Anforderung ist zwar nicht ganz untypisch, aber sicher auch nicht alltäglich. Das wird sicher nicht von jedem CMS out-of-the-box angeboten.

Die wE EntwicklerInnen sind hier auf die Rückmeldungen und Anfragen in der Bugbase angewiesen, erst dann lässt sich festlegen ob und wann etwas auf die Roadmap kommt. So gesehen zahlt es sich also schon aus, wenn du dein Anliegen in der Bugbase einbringst. Du kannst dich auch zu bestehenden Tickets dazu hängen und wirst so über ev. Updates informiert.


Nun zu deinem Problem:
Der Header "Content-Disposition: attachment" ist jedenfalls falsch. Du willst ja nicht den Download der Dateien erzwingen. Kommentiere die Zeile doch mal aus.

Ganz grundsätzlich sollte das in der Form funktionieren. Es ist allerdings immer eine gewisse "Spielerei" bis da Setup richtig sitzt.

Liebe Grüße,
Sascha

@Scarabaeus: bitte keine PM's mehr - ich lese das Forum aktiv - da brauche ich keine besondere Aufforderung einen speziellen Beitrag zu lesen.

Dein Anliegen hat grundsätzlich nichts mit der KV zu tun. Der "Dateischutz" hängt beim CMS davon ab, ob ein CMS grundsätzlich mit der Dateiauslieferung des Webservers arbeitet, also Dateibasiert ist, oder nicht.
Viele CMS machen hier einen Pseudoschutz, d.h. man kann den Dateinamen nicht so leicht erraten, aber die Dateien sind generell einfach so aufrufbar.
Eine generische Lösung ist bei dateibasierten CMS'en auch nicht möglich, weil man zumindest Apache vorraussetzen muß, da dieser der einzige Webserver ist, dem man per .htaccess den Zugriff auf ein Verzeichnis verbieten kann. Bei den meisten anderen Servern muß das vom Admin direkt in einer zentralen Config gemacht werden.

Deine Anforderung ist jetzt alle Dateien eingeloggten Kunden zur Verfügung zu stellen, die von anderen ist es auch hier sicherzustellen, daß nur der eine Kunde genau seine Dateien sehen kann. Und auch hier gibt es wieder ganz verschiedene Anforderungen. Dies bis auf die Thumb-Generierung herunter zu realisieren ist dann schon ein Problem. Auch haben andere CMS'e ein zentrales Bild-Verzeichnis, wodurch die Steuerung zentral geregelt werden kann oder geregelt wird.

Das Durchpumpen der Daten durch den PHP Prozess hat auch Nachteile, da man hier für den Browser den korrekten Dateityp ermitteln muß, außerdem wird die Verarbeitung deutlich langsamer, bei Downloads funktioniert der Resume nicht mehr, ....

Bzgl. wer hier was benötigt: bei vielen Seiten wird überhaupt kein Schutz von Grafiken oder Dateien gebraucht. Bei anderen Seiten ist der Schutz auch eher Pseudo, dadurch das die Dateien verteilt und individuelle Namen haben, kann man es nicht erraten und die Links sind nur intern. Wenn man natürlich ein Bilderverzeichnis hat mit 001.jpg, 002.jpg,... oder Links auf die Bilder per Mail weiterwandern reicht der "Schutz" nicht mehr und man muß sich wirklich eine eigene Lösung überlegen.