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-requ...@lists.typo3.org:
Date: Tue, 20 Dec 2016 22:25:42 +1100
From: Michael Schams <ty...@2016.schams.net>
Subject: Re: [TYPO3-german] /fileadmin und Zugriffsrechte
To: German TYPO3 Userlist <typo3-german@lists.typo3.org>
Message-ID: <mailman.5061.1482233159.628.typo3-ger...@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 <ty...@conpassione.ch>
Subject: Re: [TYPO3-german] /fileadmin und Zugriffsrechte
To: typo3-german@lists.typo3.org
Message-ID: <mailman.5019.1482216794.628.typo3-ger...@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@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
