[TYPO3-german] /fileadmin und Zugriffsrechte

Dr. Dieter Porth typo3 at mobger.de
Thu Dec 22 19:04:35 CET 2016


Hallo Michael,

ich habe keine Ahnung, wie es den anderen Mitlesern geht. Aber ich 
denke, dass in diesem Forum die Variante 'ein Problem = ein Post' 
bewährt hat. Es ist nicht verboten, zwei Thread kurz nacheinander zu 
eröffnen.

Du möchtest ein Tutorial haben und erwartest auf deine Tapete von Text 
Antworten auf viele unterschiedliche Fragen.  Das funktioniert meist 
nicht wirklich gut. Im besten Fall wird zufällig eine Frage beantwortet 
und der Rest bleibt unerledigt. Schlimmer noch, Dank der Suchmaschinen 
werden spätere Surfer in die Irre geführt.

Mein Tipp: Bringe dein Problem kurz und knapp auf den Punkt.

Je konkreter die Beschreibung, desto wahrscheinlicher ist eine Antwort. 
Bedenke, dass jeder Forenthread einen Dialog darstellt – und wie jedes 
Gespräch kreist auch ein Thread immer nur um ein Thema.

Mit besten Grüßen

    Dieter


Am 22.12.2016 um 10:17 schrieb Michael_OF:
> Gruezi Renzo und Hallo Michael,
>
>
> vielen lieben Dank für Eure Antworten!
>
> Ich habe mir die von Euch erwähnte Extension "secure_downloads" angesehen und
> vorgestern Nacht im IRC Channel #TYPO3 parallel noch als weiteren Tipp die (anscheinend ähnliche) Extension "FAL Secure
> Download" bekommen.
>
> Die Dokumentation zu beiden Extensions weisen darauf hin, dass Sie nur einen Layer über den Zugriff legen, der von TYPO3
> über "File Storages" implementiert ist und per Konzeption von TYPO3 direkt durch den Webserver erfolgt.
>
> Dazu habe ich aber direkt noch ein paar Fragen:
>
> Die Doku über den File Abstraction Layer
> (https://docs.typo3.org/typo3cms/FileAbstractionLayerReference/singlehtml/Index.html#document-Administration/Storages/Index)
> weist extra darauf hin (rote Box):
>
> "This does not magically protect your files if they are within your web root (e.g. below the fileadmin folder). They
> will still be available to anyone who knows the path to the file. To implement a strict access restriction the Storage
> must point to some path outside the web root or the folder it points to must contain web server restrictions to block
> direct access to the files it contains (for example, in an Apache .htaccess file)."
>
> Ich habe versucht, testweise ein paar weitere File Storages / Dateispeicher anzulegen. Angelehnt an den existierenden
> Daten für fileadmin/. Hat einen Moment gedauert (nichts in der Doku dazu gefunden) bis ich verstanden habe, dass man den
> physikalischen Ordner selber extern anlegen muss. Im Gegensatz zum Ordner für fileadmin/, den legt TYPO3 während der
> Erstinstallation selber an.
>
> Generell hatte ich da ein paar schräge Fehlermeldungen:
>
> Fehlt der Ordner des Dateispeichers, ist (manchmal :-S) die Baumstruktur unter Datei/Dateiliste "kaputt", Fehlermeldung
> aus dem Log: Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1314516810: Folder "/" does not exist. |
> TYPO3\CMS\Core\Resource\Exception\FolderDoesNotExistException thrown in file
> /srv/www/typo3_src-7.6.14/typo3/sysext/core/Classes/Resource/Driver/LocalDriver.php in line 285. Requested URL:
> http://localhost:10080/typo3root/typo3/index.php?route=%2Ffolder%2Ftree&token=a9a525732a980b1eee9596ac665ef9cbf1092dee
>
> Verschwindet, wenn der Ordner existiert und betriebssystemseitig die passenden Rechte hat. Konkrete Frage: Bei mir unter
> OpenSuse "gehören" alle Apache Daten dem User "wwwrun" in der Gruppe "www". Für den fileadmin/ Ordner hat TYPO3 auf
> Gruppenebene das "sticky Bit" gesetzt (https://de.wikipedia.org/wiki/Sticky_Bit) - soll/muss das für alle
> "Dateispeicher" Ordner so sein?
>
> Solche schrägen "manchmal" Fehler habe ich noch öfters: Wenn ich z.B. unter Datei/Dateiliste mit der rechten Maustaste
> auf das Icon einer beliebigen hochgeladenen Datei geklickt habe, kam die Meldung "uid must be positive integer, 0 given"
> (Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1437656456: $uid must be positive integer, 0 given |
> InvalidArgumentException thrown in file
> /srv/www/typo3_src-7.6.14/typo3/sysext/backend/Classes/Form/FormDataProvider/AbstractDatabaseRecordProvider.php in line
> 39. Requested URL:
> http://localhost:10080/typo3root/typo3/index.php?route=%2Frecord%2Fedit&token=d468e2c4f137992958358e9a0235346ff2229f83&edit%5Bsys_file_metadata%5D%5B0%5D=edit&returnUrl=%2Ftypo3root%2Ftypo3%2Findex.php%3FM%3Dfile_FilelistList%26moduleToken%3Dc49c5bf5a7a01f7b13fb1e4f42b12502d9de6983%26id%3D5%253A%252FSub1%252F
> )
>
> Als Neuling hab ich gesehen, dass eine System-Extension "advanced file metadata" existiert, aber nicht aktiviert war. Da
> das "passend" klang, habe ich diese mal aktiviert, und tatsächlich, der "uid must be positive integer, 0 given"-Fehler
> ist jetzt weg. Lustigerweise sogar immer noch, wenn man die Extension "advanced file metadata" wieder deaktiviert :-S
> Ich bekomme dann ganz normal den "abgespeckten" "Datei-Metadaten "<DATEINAME>" auf Wurzelebene bearbeiten" Dialog.
>
> Generelle Frage dazu: Ich halte das für einen (harmlosen) Bug. Welche ich bei allen anderen Open Source Themen wenn
> möglich gerne irgendwo eintrage. Für TYPO3 finde ich jetzt aber unter TYPO3.org nicht wirklich direkt einen Hinweis, wie
> das Bug Tracking organisiert ist. Gibt es irgendwo eine Bugzilla Instanz oder sowas?
>
> Letzte Fragen, generell, zum Thema .htaccess:
>
> Die Apache Doku (und jeder, mit dem man in #httpd chattet :-)) weist deutlichst darauf hin, dass die Verwendung von
> .htaccess Dateien einen nicht unerheblichen Performance-Verlust des Webservers bedeutet, da in der Ordnerstruktur im
> gesamten Baum bei Zugriffen Existenz und ggf. Inhalt dieser .htaccess Dateien geprüft werden muss. Sofern man - gilt für
> mich, da alles auf eigenem VPS - "root"-Zugriff hat, könnte man auf .htaccess durch server-seitige Direktiven verzichten.
>
> Um hier möglichst einfach upgrade-fähig zu bleiben, das default-.htaccess kann sich ja jederzeit mit neuen
> TYPO3-Releases ändern, habe ich einfach den Inhalt der .htaccess Datei in die "Directory" Direktive der VHOST Definition
> mit aufgenommen und ansonsten .htaccess Dateien deaktiviert:
>
>          <Directory "/srv/www/htdocs/typo3root">
>                  Options +FollowSymLinks
>                  AllowOverride None
>                  Require all granted
>                  Include /srv/www/htdocs/typo3root/.htaccess
>          </Directory>
>
> Mache ich genauso bei allen anderen .htaccess "Kandidaten" auf meinem VPS. Also z.B. bei meiner OwnCloud Instanz auf dem
> gleichen VPS.
>
> Wie macht Ihr das, gibt es da Empfehlungen? Ich hätte an sich gerne in der Direktive auch ein "Require all denied"
> stehen, dann "fliegt" mir aber fast alles um die Ohren, da z.B. nichts mehr aus fileadmin/ direkt vom Apache serviert
> werden darf. Z.B. .css Dateien, Grafiken, usw.... Auch hier die allgemeine Frage: Wie macht Ihr das? "All denied" und
> öffnende Sonderregeln für diverse Ordner?
>
>
>
> Viele Grüße und schöne Weihnachts-Feiertage für alle Mitleser dieser Liste,
> Michael
>
>
>
>
> Am 21.12.2016 um 12:00 schrieb typo3-german-request at lists.typo3.org:
>> Date: Tue, 20 Dec 2016 22:25:42 +1100
>> From: Michael Schams <typo3 at 2016.schams.net>
>> Subject: Re: [TYPO3-german] /fileadmin und Zugriffsrechte
>> To: German TYPO3 Userlist <typo3-german at lists.typo3.org>
>> Message-ID: <mailman.5061.1482233159.628.typo3-german at lists.typo3.org>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> Hi,
>>
>> Dateien, die nicht fuer die Oeffentlichtkeit bestimmt sind, haben meiner
>> Meinung nach generell nichts in "htdocs" (oder irgendeinem Verzeichnis
>> darunter) etwas zu suchen.
>>
>> Sorge dafuer, dass sie *ausserhalb* abgelegt werden und (wie Renzo
>> erwaehnt hat) ein Script (bzw. eine TYPO3 Extension) diese liest und
>> (nach entsprechender Berechtigungspruefung) an den Client sendet.
>>
>> Das gilt fuer vertrauliche Dokumente ebenso wie fuer Backups, MySQL
>> Dumps, Git Repositories und aehnliches.
>>
>>
>> Cheers
>> Michael
>
> -------------------------------------------------
>> Message: 1
>> Date: Tue, 20 Dec 2016 07:53:09 +0100
>> From: Renzo Bauen <typo3 at conpassione.ch>
>> Subject: Re: [TYPO3-german] /fileadmin und Zugriffsrechte
>> To: typo3-german at lists.typo3.org
>> Message-ID: <mailman.5019.1482216794.628.typo3-german at lists.typo3.org>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> Hallo Michael
>>
>> die Dateien kann man nur sch?tzen, wenn im entsprechenden Verzeichnis
>> der Zugriff gesperrt ist via .htaccess und man einen PHP-Script der die
>> Rechte pr?ft f?r den Zugriff verwendet.
>> All das macht z.B. die Ext secure_downloads
>>
>> Beste Gr?sse, Renzo
>>
>
> -------------------------------------------------
> Originale Email:
> -------------------------------------------------
>
>
> TYPO3 7.6.14 / Apache 2.4.23 / OpenSuse Leap 42.2
>
>
> Hallo zusammen,
>
>
> ich möchte als TYPO3-Neuling eine Webseite mit geschützten Inhalten aufbauen.
>
> Für Seiten(inhalte) an sich kein Problem, da kann TYPO3 extrem viel.
>
> Was ich aber jetzt lernen musste ist, dass per Konzept/Default der /fileadmin Ordner unter der WebRoot,
> Directory-Listings zwar unterbunden sind, aber ein Zugriff über die vollständige URL dennoch möglich ist.
>
> Ich möchte jetzt aber auch angemeldeten Benutzern Datei-Downloads als Links anbieten, die ebenso geschützt sind wie
> Seiten und keinesfalls per Kenntnis des Dateinamens abrufbar sein sollen.
>
> Reales Beispiel wäre eine Einsatzplanung für ein Projekt mit ehrenamtlich Tätigen in Form einer PDF/LibreOffice-Datei,
> welche natürlich einige private Daten enthält und daher nur geschützt nach Anmeldung herunterladbar sein darf. Im
> Standard "landet" diese Datei beim Upload egal über welchen Backend-Weg ich es versuche immer in /fileadmin oder
> Unterordnern wie "user_upload", alles "frei" zugänglich.
>
>
> Für Tipps aus der Praxis wäre ich sehr dankbar,
> viele Grüße,
> Michael
> _______________________________________________
> TYPO3-german mailing list
> TYPO3-german at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
>



More information about the TYPO3-german mailing list