Vernünftiger Dateischutz

[the_scrat]

Hallo zusammen,

ich stehe gerade vor der Herausforderung, dass wir online Dateien für registrierte Mitglieder zum Download anbieten. Es gibt verschiedene Bereiche für die sich die "Kunden" freischalten lassen können. Inhaltlich überhaupt kein Problem, da alles über Gruppen geregelt wird. Es soll jedoch auch für jede "Gruppe" eine Downloaddatei geben (zentral abgelegt).
Der Link ist natürlich auch nur dem registrierten Mitglied sichtbar.

Schütze ich die Datei mittels Zugriffsschutz funktioniert dieser zwar wenn der generierte Link ".html?file=tl_files/Beispieldatei1.zip" aufgerufen. Sobald ich mich auslogge funktioniert dieser Link nicht mehr. Lösche ich aber .html?file= raus und setze den Pfad einfach so: http://hostname.tld/tl_files/Beispieldatei1.zip gehts natürlich wieder.

Schalte ich den Ordnerschutz an, kann niemand, auch kein registriertes Mitglied mehr etwas runterladen.

Ich würd gerne ausschließlich registrierten Mitgliedern zugriff auf die für sie bestimmten Dateien gewähren. Zugriffe von außen (nicht angmeldet) sollten generell verboten werden.

Gruß
Michael

[downunder006]

Hallo,

da muss ich mich mal ranhängen an diese Problematik.

Habe sowas ähnliches gerade bei mir auch mal ausprobiert und musste feststellen, dass man ohne angemeldet zu sein Zugriff auf Bilddateien hat, die sich in Artikeln befinden. Die Bilder selber sind unter tl_files und Unterordnern abgelegt.

MFG

Volker

[juli0r]

Hallo!

Ich häng mich mal an, dass mich eine Lösung des Problems auch interessieren würde. Ich seh das Thema nicht zum ersten mal, aber kenne bisher keine gute Lösung.

[downunder006]

Hey,

ich werde das morgen nochmal genauer testen.

Für heute ist erstmal Feierabend.

Gruß

Volker

[the_scrat]

Wow cool, wär ja echt super wenn du das Thema mal angehen könntest @downunder006

Wenn ich dir irgendwie helfen kann, sagst einfach Bescheid.

[andre.5tz]

Eigentlich funktioniert der Verzeichnisschutz sehr gut.

Ein echter Schutz mit Contao kann nur funktionieren, wenn die Verzeichnisse, in denen die Dateien liegen, in der Dateiverwaltung geschützt werden (Schlosssymbol).
Sonst besteht immer die Möglichkeit des direkten Zugriffs.

Weiter muss der Server dazu in der Lage sein, die automatisch angelegte .htaccess-Datei zu verarbeiten. "mod_rewrite" muss demnach auf dem Server laufen, um den Zugriff zu steuern.

Schaut daher mal, ob in dem geschützten Verzeichnis eine .htaccess Datei angelegt wird und dann klärt mal ab, ob der Server mod_rewrite unterstützt.

Um Bilder vollständig zu schützen würde ich dazu noch die Erweiterung tl_fileProtect emfpehlen, dann geht der Schutz noch eine Stufe weiter.

[the_scrat]

Hi,

der Verzeichnisschutz ist nicht das Problem. Der wird ja sozusagen durch die file= Methode ausgetrickst, da die Datei vom System ausgelesen und an den Browser geschickt wird.

Das Problem was bleibt ist, dass man als angemeldetes Mitglied alleine durch raten Dateien runterladen könnte, die einem garnicht gehören.

Deine Empfohlene Erweiterung scheint aber dieses Probelm zu lösen. Habs grad installiert, sieht echt gut aus und scheint auch zu funktionieren. Muss ich morgen noch genauer Testen, aber vielen Dank schonmal dafür :-)

[andre.5tz]

Das Problem was bleibt ist, dass man als angemeldetes Mitglied alleine durch raten Dateien runterladen könnte, die einem garnicht gehören.

Da hatte ich Dich wohl falsch verstanden, da ich davon ausgegangen bin, Du bist ausgeloggt.

Das Problem was bleibt ist, dass man als angemeldetes Mitglied alleine durch raten Dateien runterladen könnte, die einem garnicht gehören.

Das interessiert mich jetzt aber auch. Daran hab ich noch gar nicht gedacht.

[the_scrat]

Also soweit ich jetzt getestet habe funktioniert die Erweiterung genau nach dem Prinzip wie ich es gewollt habe.

Mitgliedsgruppe 1 erhält nur Zugriff auf Datei z.B. "Mitgliedsgruppe1.zip"
Mitgliedsgruppe 2 erhält nur Zugriff auf Datei z.B. "Mitgliedsgruppe2.zip"

Mitgliedsgruppe 1 erhält jedoch keinen Zugriff auf "Mitgliedsgruppe2.zip" und umgekehrt.

Und ein ausgeloggtes Mitglied erhält überhaupt keinen Zugriff auf Mitgliedsgruppe1&2.

Somit sind ja alle Szenarien abgedeckt. Schade, dass ich jetzt auf die "Online Hörprobe" verzichten muss, weil das Verzeichnis jetzt durch die .htaccess geschützt ist und Nesium MP3-Player direkten Zugriff auf die Dateien benötigt.

Die Funktionalität gehört meiner Meinung nach direkt in den Core. Denn ein Zugriffsschutz auf Dateibasis heißt für mich nicht "ausblenden" sondern tatsächlich physisch sperren oder zumindest per Script dafür zu sorgen, dass nur Berechtigte Zugriff erhalten.

Gruß
Michael

[downunder006]

Guten Morgen,

also der Verzeichnisschutz (Schlosssymbol) funktioniert genau so wie er soll.


EDIT: ich habe einen Ordner, in dem ich Dateien zum Download anbiete und eine Seite Downloads mit Direktlinks zu diesen Dateien.

Über den Direktlink auf der Downloads-Seite können diese Dateien problemlos aufgerufen werden.

Füge ich jetzt jedoch innerhalb eines Artikels auf einem Wort einen Link zu einer dieser Dateien ein bekomme ich eine Fehlermeldung, dass der Zugriff nicht erlaubt ist.
Das ist doch so irgendwie nicht korrekt. Entweder der Ordner ist geschützt und von überall aufrufbar, sofern man angemeldet ist oder er ist halt nicht geschützt. Aber so wie es jetzt ist, ist es noch eine Mischform in meinen Augen.


Dann ist das wohl die Erweiterung, die ich brauche, um die Dateien zu schützen.

@the_scrat: "das thema mal angehen" heisst bei mir höchstens ich versuche es zu testen usw., bin nämlich auch absoluter anfänger bei contao.

Schönen Tag allerseits.

Gruß

Volker

[dirkweimar]

Hmm, das ist m. E. schon ein nicht ganz unwichtiges Thema. Wenn man z.B. vertrauliche Domkumente in der Dateivervaltung hinterlegt, die nur Mitglieder einer bestimmten Gruppe einsehen dürfen, können diese durch direkten Aufruf im Browser ohne weiteres aufgerufen werden.

Gab es dazu schon mal ein Ticket?

Die oben erwähnte Erweiterung scheint zwar genau diese Problematik zu lösen, wird aber vom Entwickler ausdrücklich nicht für Live-Installationen empfohlen.

[the_scrat]

Hi,

sehe ich genauso. Mit der Erweiterung die hier im Thread gepostet wurde funktioniert es zwar prima, aber ich finde auch, dass ein vernünftiger Dateischutz in den Core gehört.
Zudem sollte auch nicht der komplette Pfad ersichtlich sein wie es im Moment der Fall ist.

Eine perfekte Lösung wäre, wenn man einem Benutzer oder einer Gruppe ein Verzeichnis gibt in der die Files liegen. Eine physikalische Pfadangabe sollte nicht ersichtlich sein. Zudem müsste dann der Zugriff der Datei generell verboten werden und nur für Gruppen oder Mitglieder explizit freigegeben werden.

Ein Ticket existiert dazu meines Wissens noch nicht.
Kannst aber ja gerne mal eins aufmachen...... schaden kannst jedenfalls nicht.

Gruß
Michael

[dirkweimar]

Ich habe mal ein Ticket dazu angelegt: http://dev.contao.org/issues/2724

[weke]

Hi Michael,

Schade, dass ich jetzt auf die "Online Hörprobe" verzichten muss, weil das Verzeichnis jetzt durch die .htaccess geschützt ist und Nesium MP3-Player direkten Zugriff auf die Dateien benötigt.

hast du das mit dem Nesium MP3-Player schon versucht? Durch die .htaccess wird ja der Zugriff transparent erlaubt, wenn der Benutzer die entsprechenden Rechte für diesem Ordner besitzt. Ich kenne diesen Player leider noch nicht. Sollte er jedoch serverseitig auf die MP3-Datei zugreifen, dann stört ihn die .htaccess eigentlich nicht. Wird es durch eine Flash oder ähnliches vom Browser aufgerufen, dann müsste es eigentlich gehen, sofern angemeldet.
Wenn die MP3-Datei jedoch immer verfügbar sein soll (also auch ohne Anmeldung) dann benötigst du hierfür nur einen Ordner der nicht geschützt ist.

Ich habe mal ein Ticket dazu angelegt: http://dev.contao.org/issues/2724

Wie befürchtet abgelehnt! Wie das allerdings mit einer .htaccess geht und was daran auch noch problemlos sein soll, das werde ich vielleicht nie erfahren. Oder kann mir jemand diesen Trick erklären?

[the_scrat]

Hi Weke,

den Player habe ich natürlich probiert. Der Player an sich greift zwar direkt auf die Datei zu, aber das passiert wohl über Javascript, also direkt im Client. Der Client benötigt einen direkten Link zur Datei, dies ist aber mit der aktuellen Methode nicht möglich. Denn in dem Ordner liegt physisch immer die .htaccess, also ist für niemand der Zugriff erlaubt.
Durch die Erweiterung greift jedoch php auf die Zieldatei zu und liest diese aus bzw. schickt sie weiter an den Browser (so hab ich das zumindest jetzt verstanden).

Dass das Ticket abgelehnt wurde, war mir eigentlich klar. Die Erklärung ist jedoch absolut lächerlich, denn problemlos ist mit der bisherigen "Sicherungsmethode" garnix. Es gibts erlaubt oder gesperrt, aber eine Abstufung ist so nicht wirklich möglich (außer mit der Extension)

Vielleicht sollte man das Ticket einfach nochmal öffnen und detaillierter erklären um was es geht bzw. was für Anforderungen gestellt werden. Die Funktionalität der Extension gehört meiner Meinung nach fest in den Core rein. Der jetzige Dateischutz ist lächerlich!

[weke]

Hi Michael,

Der Player an sich greift zwar direkt auf die Datei zu, aber das passiert wohl über Javascript, also direkt im Client. Der Client benötigt einen direkten Link zur Datei, dies ist aber mit der aktuellen Methode nicht möglich. Denn in dem Ordner liegt physisch immer die .htaccess, also ist für niemand der Zugriff erlaubt.

hmm, also die .htaccess bewirkt, dass bei einem direkten Aufruf einer physischen Datei der Aufruf an eine php-Datei weitergegeben wird, welche dann die Datei (falls erlaubt) an den Browser zurück übermittelt. Sollte daher funktionieren. Du kannst eigentlich die Datei auch direkt per deep link aufrufen.
Ich muss aber mal prüfen, ob ich alle Dateitypen mit dem passenden header zurück liefere. Dann erkennt evtl. der client seitige Player den Dateityp nicht richtig und weigert sich die Datei abzuspielen. Bisher habe ich das nur für Grafiken vorgesehen. Aber du hast mich da auf eine Idee gebracht!

Nachtrag
Habe soeben mal nachgesehen. Ich nutze schon die Methoden aus der File Klasse. Demnach wird auch eine MP3-Datei mit content type MP3-Audiodatei übertragen. Der Client sollte eingentlich nicht erkennen, dass es sich um eine serverseitge Umleitung handelt. Werde das noch mal mit der MP3 Erweiterung testen....

2. Nachtrag
Habe das soeben auch mit dem Nesium MP3-Player getestet und es hat bei geschützten und ungeschützten Verzeichnissen funktioniert. Bei den geschützten Verzeichnissen natürlich nur, solange ich als berechtigtes Mitglied angemeldet war. Bin jetzt erst mal ratlos...

[the_scrat]

Ich probiers gleich nochmal aus... vielleicht hab ich auch beim ersten mal was falsch gemacht.

[the_scrat]

Nein, tut mir leid.

Sobald ich die Dateien schütze (per .htaccess) und über die Erweiterung einer oder mehreren Mitgliedergruppen freigebe. Kann ich sie zwar downloaden (über das Modul). Ein direkter Zugriff auf eine .mp3 Datei funktioniert nicht und endet in der Meldung "No input file specified."

Füge ich den Nesium MP3-Player ein sehe ich zwar den Player und die Playliste, sehe auch die Links zu den einzelnen Dateien. Doch wähle ich die Datei aus und starte den Player, einscheint nur "Nicht geladen!".

Im Quelltext sehe ich, dass der Player die Datei direkt anspricht, also absoluter Pfad, ohne Umweg über eine php Datei.
np1.initialPlayer("tl_files/absoluterpfad_zur/datei.mp3", false, false);

Aber das ^^ kann ja nicht funktionieren, da die Datei direkt ja nicht aufgerufen werden kann. Denn offiziell ist die Datei erstmal geschützt per .htaccess und Zugriff gibts sozusagen nur per PHP Script.

[weke]

Hallo Michael,

Nein, tut mir leid.

... Aber das ^^ kann ja nicht funktionieren, da die Datei direkt ja nicht aufgerufen werden kann.

die Beschreibung lässt mich da was vermuten.
Was steht denn in deiner .htaccess drin? Die Dateien sollen sich dank der speziellen (neuen) .htaccess, die von der Erweiterung tl_fileprotect erzeugt wird, direkt aufrufen lassen!
Es müsste sowas wie das hier drinnen stehen:

RewriteEngine On
RewriteBase /
RewriteRule (.*)  protect.php?id=$1 [L] 

Die RewriteBase kann abweichen, je nach installation.

Ein häufiges Problem ist, dass ein Verzeichnis, dass geschützt wurde bevor tl_fileprotect installiert wurde eine andere .htaccess erhält. In diesem Fall muss das Verzeichnis wieder freigegeben werden und erneut gesperrt. Das erfolgt nicht automatisch! Contao erzeugt standardmäßig sowas:

order deny,allow
deny from all 

Damit ist dann ein Zugriff eines Client grundsätzlich ausgeschlossen.

Grundsätzlich gilt, wenn du als berechtigtes Mitglied angemeldet bist und die mp3-Datei nicht per deep-link aufrufen kannst (in Deinem Fall über http://DeineContaoURL/tl_files/absol..._zur/datei.mp3 oder so ähnlich) dann stimmt der Verzeichnisschutz noch nicht und muss neu gesetzt werden.

[the_scrat]

Hallo,

also, habe mir jetzt gerade die aktuelle .htaccess vom Server runtergeladen die in dem Verzeichnis liegt in dem die *.mp3s liegen.

In ihr steht, wie du schon bereits geschrieben hast, nur dieser Inhalt:

RewriteEngine On
RewriteBase /
RewriteRule (.*)  protect.php?id=$1 [L]

Nicht mehr und nicht weniger.
RewriteBase hab ich nicht. Ich habs jetzt sogar mal getrennt und habe 2 Ordner erstellt. Beide Ordner wurden geschützt. In Ordner 1 liegt eine .zip Datei. In Ordner 2 liegen mp3 Dateien (die zur Hörprobe hergenommen werden sollen).
Beides wurde mit dem Ordnerschutz geschützt (.htaccess Inhalt siehe oben).

Ein direkter Aufruf geht überhaupt nicht.
Nur über ".html?file=tl_files/pfad_zur_datei/datei.mp3"

Ich habe jetzt mehrfach den Dateischutz deaktiviert und neu aktiviert. Danach nochmal in die Mitgliedergruppen gegangen und dort nochmal expliziet das Verzeichnis gewählt und gespeichert, damit das System sicher weiß welche Gruppe welche Dateien aufrufen darf.

[weke]

Hallo,

die .htaccess sieht ja richtig aus.

Ein direkter Aufruf geht überhaupt nicht.

Mit genau dieser .htaccess sollte der direkter Aufruf ermöglicht werden (sofern angemeldet).
Kannst du in der protect.php im Contao root Verzeichnis mal die Zeile 175
von

//die('File not found! Errorcode:'.$Die); 

in

die('File not found! Errorcode:'.$Die); 

ändern und dann die mp3 noch einmal direkt aufrufen.
Was ich dann bräuchte ist der Errorcode nach File not found!
Bei mir funktioniert das auf mehreren Servern und ich hoffe das Problem anhand des Fehlercodes zu erkennen.

[the_scrat]

Hi,

also, protect.php entsprechend abgeändert.

Ich muss auch noch dazusagen, dass ich mit dem Subdomainhack arbeite, der hier im Forum angegeben wurde.
Daher wird der Link intern umgewandelt in http://files.

Rufe ich den Link exakt so auf wie er im Quelltext steht:
http://files.domain.tld/pfad_zur_datei/dateiname.mp3 erhalte ich folgende Meldung

No input file specified.

Ändere ich den Link ab in http://www.domain.tld/tl_files/pfad_zur_datei/dateiname.mp3 erhalte ich folgende Meldung:

File not found! Errorcode:1

Um mich selbst zu prüfen, damit bei der Eingabe der Pfade kein Fehler passiert, habe ich auf der gleichen Seite noch ein Downloads-Modul eingerichtet, welche mir die selben mp3 Dateien zum Download anbietet (mit der Contao Funktion .html?file=tl_files/pfad_zur_datei/usw.mp3). Funktioniert tadellos.

[weke]

OK, da beißen sich wohl zwei Verfahren.
Die Fehlernummer sagt mir, dass die Datei nicht im tl_files Ordner liegt. Das ist wohl aufgrund der geänderten Domain. Muss ich mal mit dem Subdomainhack testen.
Wo finde ich den denn?

[the_scrat]

http://www.contao-community.de/showt...eed-optimieren

[the_scrat]

Hab den Subdomainhack mal deaktiviert. Trotzdem funktioniert der Direktzugriff leider nicht.

Ich habe jetzt testweise mal oben in der protect.php folgendes eingegeben.

echo $_REQUEST['id'];
die(); 

Und als Ausgabe kommt tatsächlich der Dateiname. Also zumindest funktioniert die Weiterleitung und auch die korrekte Übermittlung des Dateinamens.

Danach übersteigt der Code mein Verständis. Ich hab nach der Stelle gesucht an der die id ausgelesen wird, leider ohne Erfolg.

Gruß
Michael

[krumpel]

Ich möchte das Thema noch mal aufgreifen! Habe ich Tomaten auf den Augen und finde im aktuellen Contao 3.1.3 keine Lösung für das Problem? Wie schütze ich Dateien vor dem direkten Zugriff via Deeplink und behalte das Betrachten / Downloaden nur Mitgliedern vor???

Das Thema muss doch auch für andere Relevant sein!
Geht das denn mit htaccess? Was ich nicht will, ist, dass ein eingeloggtes Mitglied beim Download einer Datei vorher nochmal einen Benutzernahmen und Passwort eingeben muss, weil das die htaccess-Datei verlangt.

Gibt es eine Erweiterung, die ich bisher noch nicht gefunden habe? Für Contao 3.1.x?

Danke euch!

[xchs]

Über die Bearbeitungsfunktion von Dateien und Ordner kann die Option "Geschützt" gesetzt werden. Diese Ressourcen sind dann vor dem direkten Zugriff geschützt.

[krumpel]

Über die Bearbeitungsfunktion von Dateien und Ordner kann die Option "Geschützt" gesetzt werden. Diese Ressourcen sind dann vor dem direkten Zugriff geschützt.

OK. Aber dann ist auch der Aufruf für angemeldete Benutzer über eine Galerie oder als Bildelement nicht mehr möglich. Der Download funktioniert glaube ich.
Oder sehe ich das falsch???

[dertimmerle]

Hallo krumpel und xchs,

das geschilderte Problem im letzten Post beschäftigt mich auch gerade noch in Contao 3.2.8.
Konntet ihr eine Lösung finden?

Gesendet von meinem FP1 mit Tapatalk

[krumpel]

Hallo krumpel und xchs,

das geschilderte Problem im letzten Post beschäftigt mich auch gerade noch in Contao 3.2.8.
Konntet ihr eine Lösung finden?

Nein, leider bisher nicht. Vielleicht ist es auch noch für andere interessant? Wäre echt schön, wenn es eine elegante Lösung gäbe.

[highjack]

Hallo,

ich bin ebenfalls an einer adäquaten Lösung für das genannte Problem interessiert! Irgendwie muss es doch möglich sein, dass man Dateien für den öffentlichen Zugriff (Deep-Link) zwar sperren, diese aber zeitgleich für angemeldete Benutzer als Inhaltselemente in einem geschützten Bereich ausgeben kann.

Weder kann es die Lösung sein immer auf das Download-Modul zurückgreifen zu müssen, z.B. beim Videostreaming, noch erscheint mir eine Erweiterung im Beta-Status [tl_fileProtect] als besonders geeignet. Durch den Einsatz von Cron-Jobs usw. macht zumindest zuletzt genannte doch einen ziemlich frickeligen Eindruck, mal ganz abgesehen von den angegebenen unterstützten Versionen.

Wie handhaben es denn alle anderen von euch? Ich kann mir nicht vorstellen, dass dieser Anwendungsfall in mittleren bis großen Installationen so selten ist...

Viele Grüße

[4lmnts]

Hallo zusammen

Via Dateiverwaltung kann ein Ordner zwar geschützt werden,
aber so wie ich es sehe gibt es momentan folgende Probleme:

• Es gibt keine Ausnahmeregelung für angemeldete Frontendbenutzer / Mitglieder
• Die Bilder (runtergerechnete Varianten der Originalbilder im geschützten Ordner) im assets-Ordner sind trotzdem zugänglich

Beide Punkte müssen von einem CMS erfüllt werden können, oder nicht?!
Also müsste es einen zusätzlichen asset-Ordner geben, wo geschützte Inhalte reinkommen...
Denn ich will nicht, dass Bildinhalte aus dem geschützten Bereich doch (unangemeldet) aufrufbar sind.

Komisch, dass das so scheinbar noch nicht funktioniert... oder irre ich mich?

Beste Grüsse
Nick

[do_while]

Hallo Nick,

zu 1)
Der Schutz beruht auf einer .htaccess und verhindert, dass man die Datei per URL erreicht. Die Download-Elemente in Contao haben jedoch Zugriff und beachten dabei die Rechte der Mitglieder bzw. der Mitgliedergruppe.

zu 2)
Die skalierten Bilder im Cache haben einen Dateinamen, der einen Hash enthält. Es sollte einen großen Aufwand bedeuten, diesen Dateinamen zu "erraten". Bilder in Originalgröße befinden sich normalerweise nicht im Cache.

[4lmnts]

Hallo Nick,

zu 1)
Der Schutz beruht auf einer .htaccess und verhindert, dass man die Datei per URL erreicht. Die Download-Elemente in Contao haben jedoch Zugriff und beachten dabei die Rechte der Mitglieder bzw. der Mitgliedergruppe.

zu 2)
Die skalierten Bilder im Cache haben einen Dateinamen, der einen Hash enthält. Es sollte einen großen Aufwand bedeuten, diesen Dateinamen zu "erraten". Bilder in Originalgröße befinden sich normalerweise nicht im Cache.

Hi do_while

Bei 2) gebe ich dir Recht. Ist für mich ok mit deiner Argumentation.
Bei 1) ist aber offensichtlich ein Wunsch von (ein paar) Leuten da
... habe mich schon gefragt, ob man händisch im htaccess Ausnahmen auf member oder membergroup Basis reinschreiben könnte. Habe dazu im Netz aber nichts auf die Schnelle gefunden...

[MacKP]

Ich glaube da solltest du lieber schauen, was mit Contao 4 so geht, da sich das Verhalten dort komplett ändert.
Eventuell kann da dann eh eine Logik aufgebaut werden, für das Anzeigen von Bildern etc. was ja bisher so noch nicht möglich ist.

Viele Grüße

[izanagi]

Hallo ihr lieben,
hat denn wer eine Lösung für 3.2+ ?
Ich muss dringend ein Video und ein paar Templatebilder dem Zugriff von aussen verbieten, für eingeloggten Member jedoch erlauben damit das Template entsprechend zu sehen ist.
Also Downloadbereich o.ä. bringt mir nix. Ich möchte den direkten URL Aufruf verhindern und sollte nur als Member zu sehen sein.

[ele]

Hallo Hagen,
das kann ich so nicht bestätigen bei Contao 3.5.28.

Ich habe einen Ordner geschützt.
Wenn ich die Dateien als Audio-Element aufrufe spielen diese nicht ab. Auch nicht, wenn ich eine Mitgliedergruppe zuordne.
Wo kann ich Mitgliedergruppen Ordner zuordnen. Das geht doch nur pro Mitglied und auch dann spielt es nicht ab.

Gibt es hier eine Lösung?
Gruß ele

zu 1)
Der Schutz beruht auf einer .htaccess und verhindert, dass man die Datei per URL erreicht. Die Download-Elemente in Contao haben jedoch Zugriff und beachten dabei die Rechte der Mitglieder bzw. der Mitgliedergruppe.

zu 2)
Die skalierten Bilder im Cache haben einen Dateinamen, der einen Hash enthält. Es sollte einen großen Aufwand bedeuten, diesen Dateinamen zu "erraten". Bilder in Originalgröße befinden sich normalerweise nicht im Cache.

[GOVILI]

Ich habe das bei mir auch mal versucht aufzubauen:
Ich habe einen geschützten Bereich der Downloads (PDFs) inkl. Vorschaubilder (separate jpgs) zur Verfügung stellen soll. Da es sich um sensible Daten handelt, dürfen die Sachen nicht über die Dateistruktur aufrufbar sein, solange man nicht eingeloggt ist.

Wenn ich nun die Verlinkungen über ein Download-Element zur Verfügung stelle, funktioniert das auch soweit.
Ich möchte nun aber das ganze über ein Text-Element inkl. verlinkten Bild zur Verfügung stellen. Die direkte Verlinkung klappt nicht, da die Ressourcen geblockt werden. Somit habe ich den funktionierenden Link vom Download-Element verwendet: Dieser wird von
files/xxxdateinamexxx.pdf
auf
/xxxseitennamexxx.html?file=files/xxxdateinamexxx.pdf
erweitert.
Das funktioniert aber nur solange wie ich das downloads-element ebenfalls auf der Seite habe. Sobald ich es lösche oder auch nur ausblende funktioniert der link nicht mehr (verlinkt dann plötzlich auf die selbe Seite als Fallback).

Kann das jemand erklären, bzw. Abhilfe schaffen?

PS: Contao 3.5.35


Edit: Mit der Erweiterung von spooky funktioniert es:
https://contao.org/de/erweiterungsliste/view/file_access.en.html
Version 1.1.2 aktuell getestet

[4lmnts]

Hallo zusammen

Ich habe in Contao 3.5 einen Bild-Ordner geschützt. Auch die Seite, wo sich die Bilder befinden, sind über ein Mitglieder-Login geschützt und unbefugten wird eine 301-Meldung geliefert. Das will ich so, damit die Suchmaschinen die Bilder nicht indexieren. Jetzt habe ich aber festgestellt, dass die Suchmaschinen die Bilder aus assets/images indexiert, und zwar halt auch die, die von den eigentlich geschützten Bildern als Vorschaubilder generiert worden sind. Wie kann ich das verhindern? Die Bilder haben (noch) kein gemeinsames Merkmal im Dateinamen, über die man vielleicht eine htaccess-Regel definieren und vom indexieren ausschliessen könnte. Gibt es eine Erweiterung hierzu?

Beste Grüsse
Nick

[Spooky]

Das kannst du nur verhindern, in dem du die geschützen Bilder nicht von Contao bearbeiten lässt. Das heißt:

• In einem Text Element, wo du ein geschütztes Bild ausgewählt hast, keine Bildgröße auswählen.
• In einem Bild Element, wo du ein geschütztes Bild ausgewählt hast, keine Bildgröße auswählen.
• In einer Galerie, wo du geschützte Bilder ausgewählt hast, keine Bildgröße auswählen.
• Die System Einstellung "maximale Frontend Breite" nicht verwenden.

Hat natürlich den Nachteil, dass du den Benutzern das Bild nur über das Download Inhaltselement zur Verfügung stellen kannst. Oder nur die Originale ausgeben lässt mit Hilfe der file_access Extension.