Website ohne öffentlichen Zugriff

Wenn du keine großen Dateien speichern willst, ja. wenn du viele Dateien hosten möchtest, die nicht öffentlich abrufbar sein sollen, dann musst du das Private Dateisystem aktivieren und konfigurieren, bevor du die erste Datei hochlädst. Das gilt natürlich nur dann, wenn die Website uch über das Internet erreichbar sein soll. In einem Intranet gibt'S andere Möglichkeiten.

Per Default kann man bestimmen, welche Rolle welche Inhalte pflegen, anlegen, löschen darf.
Aber um dediziert einzustellen, wer welche Inhalte sehen darf, verwende ich unter Drupal 8 das Modul
https://www.drupal.org/project/node_view_permissions/
Es ist nicht ausdrücklich kompatibe für Drupal 9, aber wirft auch keine Fehlermeldung.
Muss ich mal testen.

Auf einer Frontpage lege ich einen nichtsagenden Allgemeintext an, der von allen gesehen werden kann, undd zeige das Loginformular.
Rgistrierung steht auf Admin only.

Das funktioniert hervorragend.

Wie verhindert das, dass Inhalte nur von bestimmten Usern gesehen werden können?

Danke! Also, ich deaktiviere erstmal alles für Gäste und nehme dann noch entsprechende Erweiterungen um das zu verfeinern. Das Dateisystem stelle ich dann auf privat, wobei ich erstmal schauen muss, ob das so einfach geht. Ich brauche dann nur die Login Seite,. Achso, Registrierungen generell abschalten geht das? Reicht das, oder muss ich da noch etwas machen?

unnd die Selbstregistrierung verbieten

Ich hab einen Block erstellt, der dummerweise auf der Anmeldeseite zu sehen ist . Ich komme doch nicht drauf, wie ich den deaktiviere. Auch die Suchleiste ist da noch zu sehen.

Du kannst Doch Seiten definieren, auf denen ein Block NICHT angezeigt werden soll.
Funktioniert das nicht?

Doch klar, danke. Ich hatte mich nur gewundert, nach Einschränkung der Rechte waren die meisten Blöcke weg. Nur ein Sidebar-Block nicht, nebst anderen wie Top-Header.

Wie style ich denn die Login Seite am besten, die sieht ja doch anders aus als die anderen? Was ich auch brauche, ist dass man immer auf die Logjn-Seite kommt, wenn man nicht angemeldet ist.

Du kannst doch einfach eine Basic Page aufsetzen und die für anonyme User freigeben (Content_access). Diese Seite hat dann eine feste Node-ID, für die Du ein eigenes Twig-Template erstellen kannst. Nur auf dieser Seite zeigst Du den Login-Block. Damit solltest Du alle Randbedingungen passend gesetzt haben.

Hm, blöd gefragt, wo finde ich denn die Login Seite ansich? Der Block ist ja auch nicht in der Block-Verwaltung. Jetzt habe ich das Modul SimpleLogin gefunden, welches mir erstmal hilft.

Der Block heißt "User Login" und ist in der Block-Verwaltung dann zu sehen, wenn Du bei einer Region auf "Place Block" klickst.

Ah, danke! Wieder was gelernt!

Einmal ein Frage: ALLE FIles, also Bilder, PDFs etc werden dann in das private Verzeichnis geladen und sind NUR von authorisierten Usern abrufbar?

Moin,

mich würde mal (ohne es jetzt selber zu testen) mal interessieren ob bei den genannten Einstellungen (Login + Private-File-System) wirklich nicht von außen auf die Daten zugegriffen werden kann?

Anders ausgedrückt, wer den absoluten Pfade kennt, kann auf jede Datei die auf einem Webserver liegt zugreifen/aufrufen. Außer, der Zugriff wird durch die .htaccess oder eine sonstige Einstellungen auf einer der unteren Ebenen abgefangen.
Dies ist ja gleichzeitig eine der größten Sicherheitsrisiken für alle PHP-Basierenden Seiten. Wenn es mir geling ein Script welches als Backdoor fungiert in das System einzuschleusen (bei Drupal z.B. als Teil eines Moduls), dann kann ich dieses Script auch direkt aufrufen. Nur als Beispiel:
https://wreb.de/sites/all/modules/workflow/workflow.api.php

Verhindert werden kann das nur, wenn automatisch entsprechende .htaccess Dateien generiert werden.

Ist das bei den beschriebenen Setups (Login + Private-File-System) der Fall?

VG
Peter

Das private-Filesystem sollte immer außerhalb des DocumentRoot liegen. Der interne Pfad in Drupal heißt private://..... Drupal benötigt den absoluten Pfad und baut sich aus dem absoluten Pfad zum private-Verzeichnis auf dem Server und der Info aus dem internen Pfad den absoluten Server-Pfad zusammen. Der liegt dann aber nicht im Zugriff des Webserver. Zusätzlich gibt es auf den Private-Verzeichnis noch einen, von Drupal gesetzten, .htaccess, falls der User sich nicht an die Regel gehalten hat, das private-Verzeichnis außerhalb des DocumentRoots anzulegen.

Soweit klar - thx.

Damit z.B. Images aus diesen Verzeichnissen auf der Webseite angezeigt werden, müssen sie aber für den Server erreichbar sein - ergo sie müssen ggf. temporär kopiert werden, oder gehen solche Verränkungen tatsächlich über die .htaccess?

Also, es kann ja nur so sein, dass wirklich alles privat abgespeichert wird, ausserhalb des Roots.

Dummerweise habe ich das nach einer Anleitung einmal gemacht, aber beim Test ging der Upload eines Bildes nicht in das private Verzeichnis.

Jetzt habe ich gesehen, dass ich ein bestehendes Image-Feld (z.B.) garnicht mehr auf private stellen kann, oder?
Bei einem neuen Inhaltstyp, den ich zum Test angelegt habe, war die Auswahl Upload-Ziel verfügbar.
Der Pfad lautet auf "/system/files/2020-11/pngtest.png". Der von mir angelegte Order ausserhalb des Roots ist aber leer und ich finde die Datei nicht.
Wo liegt die?

Also das kann ansich auch nicht sein.

Wiederspricht jeder Logig eines Websservers.

Wenn überhaupt, müssten die Dateien ausserhalb der Verzeichnistruktur die für den Server erreichbar ist gespeichert werden und dann für jeden Zugriff (Anzeigen im Webbrowser) unter einem temporären Namen in ein für den Server sichtbarers Verzeichnis kopiert werden. Das ist aber ziemlich individuell und auch ziemlicher Käse.

Zusammengefasst: Ich kann natürlich mit einfachen Hausmitteln (Drupal Zugriffsrechte) verhindern das der Besucher "normal" auf der Webseite navigiert. Es ist aber nicht zu verhindern das extern direkt auf die z.B. Bilder zugegriffen wird via "./sites/default/files/.....".

Damit man sowas verhindert gibt es unter Apache den Zugriff via Authentication in der .htaccess. Alle anderen Lösungen sind deutlich aufwendiger (echte Logings unter Windows ILLS Servern) und sprengen definitiv den Rahmen hier oder spielen nur Sicherheit vor!

Ach Leute wie lang ist denn dieser Thread bitte.

Antwort:

Ja die Felder kannst du im Nachgang nicht mehr ändern. Normalerweise plant man Webseiten vorher auf dem Reissbrett und überlegt sich die Struktur der Website.

Dazu gehört auch welche Art von Dateien aus welchem Grund, bzw auf Grund welches Abwendungszweckes in das private Dateiverzeichnis gehöreb

Dieses Verzeichnis liegt immer außerhalb des Hauptverzeivhnisses der Website. Dies geschieht um Durekaufrufe von Dateien im Browser zu verhindern und den Aufruf der Datei durch Drupal steuern zu lassen.

Felder, deren Feldspeichetdaten bereits festgelegt worden sind und die bereits Werte wie Dateipfadabgaben enthalten, lassen eine Änderung der Feldspeichetdaten nicht mehr zu.

Ergo müssen diese Felder gelöscht und mit der richtigen Konfiguration neu angelegt werden, um das gewünschte
Ergebnis zu erzielen.

So so einfach wäre es gewesen eine vollständig korrekte Antwort auf die Frage zu geben.

Das was nicht sein kann, weil man es selbst noch nie erlebt hat dagegen ist immer eine gefährliche Annahme.

Wenn ich mir Deine Profile auf Linked und X so ansehe - Du hast sicher viel Projekterfahrung in großen Teams und so (:-

*EOT

Aha und das ist im Kontext der Lösung dieser Frage hier relevant weil? Nimm dir dein lieblingsheisgtränk und hab einen schönen Tag. :-)

Danke, das dachte ich mir schon. Das ganze läuft noch unter WP. Wird aber neu aufgesetzt mit Drupal. Bei WP ist mir aufgefallen, dass Dokumente bei Kenntnis der URL abrufbar sind.
Es stimmt schon, am besten man macht vorher ein Konzept. Bisweilen läuft es aber halt doch anders.

Bittesehr. Um das mal ganz klar auszudrücken. Die Art und Weise, wie Drupal Feldkonfigurationen ablegt und dafür sorgt, daß diese größtenteils nicht mehr geändert werden können, sobald Daten angehängt werden zwingt Anwender und auch groẞe Teams dazu dich an diesen Workflow zu gewöhnen. Der Software ist es schlicht egal, wie ihr in einem Team bisher arbeitet und wiedad normalerweise läuft. Die ist so programmiert, wie sie programmiert ist. :-)

In Drupal ist grundsätzlich aber nichts in Stein gemeißelt. Wenn es einen Anderen Ansatz gibt, der sich besser zur Ablage von Konfigurationsdatei eignet, in diesem Fall sprechen wir vom Pfad zum Verzeichnis, in dem die über ein Feld hochgeladen Daten abgespeichert werden, dann auf damit in die Issue queue auf Drupal. Org als Proposal für zukünftige Drupal-Versionen.

Wenn ihr Glück und Zeit habt, könnt ihr das gerne heute bis 18 Uhr auch direkt den Core Maintainer erklären Es ist Contribution Day auf der DrupalCon Europe.

Bis 18 Uhr sind wir also alle online in den Meeting Räumen erreichbar. Live und in Farbe. Kommt also gern mit eurem Vorschlag vorbei. Heute kostet die Con schließlich nix. Die Chance, das, was da anders läuft mal mit jemand zu besprechen, der es im System selbst ändern kann ist also durchaus gegeben.

Jetzt sehe ich, dass man Media Felder garnicht auf privaten Upload stellen kann.

Also gut. So sehr mich ein dermaßen unqualifizierter Kommentar wie der etwas weiter oben wohl aufgeregt hat. Man sieht es am Text. Will ich dir mal helfen. Der Kommentar kam ja schließlich nicht vom Autor dieses Beitrags.

Ok, Ein Media Field ist ein Referenzfeld zu einem Medientyp, der Felder für Dateien und Metainformationen über das jeweilige Medium enthält.
Wenn du also die über das Media-Feld hochgeladen Daten im privaten Dateiverzeichnis von Drupal abspeichern möchtest. musst du das Datei, bzw. Bild-Feld im jeweiligen Medientyp entsprechend einstellen.

Medientypen findest du unter /admin/structure/media

und hier

/admin/structure/media/manage/test/fields/media.test.field_media_image_1/storage

Kann man das dann durchaus.

Drupal kocht erstens nur mit Wasser und funktioniert zweitens tadellos, aber nicht immer so , wie es einige wenige erwarten.

Das bedeutet, also, dass der Upload über das Media-Feld eigentlich über das File- und Imagefeld läuft und die EInstellungen (private upload) dort ziehen? Macht insofern Sinn als unter Mediatypen ja keinen Typ media gibt.