Umschalten auf "privat modus" - Dateisystem - trotzdem Zugriff auf die gespeicherten Dateien (unter "normaler URL")
Eingetragen von paulap (72)
am 21.01.2011 - 20:22 Uhr in
am 21.01.2011 - 20:22 Uhr in
Hi!
Ich verwende 6.20 und habe bisher das "Dateisystem" im public modus betrieben.
Nun habe ich auf "private modus" umgeschalten.
Passt auch grundsätzlich so. Die Dateien sind nun unter einer /system/file/... URL nur über Drupal zu erreichen.
ABER!!!!!
Weiss man die reale URL (/sites/default/files/) und fügt nur den Dateinamen dazu, kommt man doch zu Dateien.
Und die Dateien werden auch noch von Google indiziert!!!
Sollte da nicht irgendwie automatisch ein geändertes .htaccess im /file Verzeichnis (und alle darunter) stehen?
Bitte um Feedback.
paulap
- Anmelden oder Registrieren um Kommentare zu schreiben
Du solltest das Verzeichnis
am 21.01.2011 - 21:32 Uhr
Du solltest das Verzeichnis für die privaten Dateien auch außerhalb vom DocumentRoot des Apache liegen haben. Dann kann Dupal unter Kenntnis des Pfades die Dateien ausliefern, aber direkt kann niemand da ran. Habe ich so getested und im Einsatz mit Drupal 6.20.
Beste Grüße
Werner
.
Werner
drupal-training.de
Moderator und Drupal Trainer
* - - - - - - - - - - - - - - - - - - - - - - - - - - - *
Thx. Aber wie?
am 21.01.2011 - 21:52 Uhr
Danke mal für die rasche Antwort.
Habe es gerade versucht. Funktioniert!
Kannst Du mir einen Tipp geben, wie man die alten Inhalte des files Verzeichnis so migriert, dass die bestehenden Attachments wieder funktionieren. Nur die Verzeichnisse/Dateien kopieren hat da nicht funktioniert. Die URLs der bestehenden Dateien sind nicht korrekt, ich bekomme immer ein "Seite nicht gefunden".
lg
paulap/Gerald
Du kannst auch mal probieren,
am 21.01.2011 - 23:13 Uhr
Du kannst auch mal probieren, das files-Verzeichnis an Ort und Stelle zu lassen und auch dieses Standard-Verzeichnis zu verwenden und dafür eine .htaccess mit einem
Deny from all
reinzupacken. Damit kann Drupal immer noch an die Daten, die Pfade stimmen immer noch und es kommt trotzdem niemand über direkten Aufruf an die Dateien.Habe ich mal kurz getestet, dürfte eigentlich auch funktionieren.
Habe den Datei Pfad nun komplett "umgebogen"
am 23.01.2011 - 12:20 Uhr
Danke für Deine Antwort.
Ich habe den Pfad jetzt komplett umgebogen und ausser der Reichweite des Webservers gebracht. Dies erscheint mir irgendwie sicherer.
Die bestehenden Dateien habe ich einfach in das neue Verzeichnis kopiert.
Bei allen hat dies zwar nicht funktioniert, aber der Weg passt.
Gibt es denn keinen Script, der alle Dokument zu dem veränderten Pfad hin verschiebt (und gleichzeitig auch die DB-Einträge, sofern es welche gibt, anpasst)?
lg
paulap/Gerald
Die "Quick and Dirty" Methode
am 23.01.2011 - 12:54 Uhr
Die "Quick and Dirty" Methode dafür ist:
Jetzt sind die neuen Pfade drin.
Beste Grüße
Werner
.
Werner
drupal-training.de
Moderator und Drupal Trainer
* - - - - - - - - - - - - - - - - - - - - - - - - - - - *
Das kann man mit einer
am 23.01.2011 - 13:18 Uhr
Das kann man mit einer SQL-Funktion machen, siehe http://www.coderecipes.net/sql-replace-function.aspx
Gelöste Forenbeiträge mit [gelöst] im Titel ergänzen
Das Verhältnis anderen zu helfen muss höher sein, als von anderen Hilfe zu erfragen/erwarten.
Und wenn du die Mysql replace
am 23.01.2011 - 13:21 Uhr
Und wenn du die Mysql replace funktion anwendest solltest du auch über den Body in der Revisions Tabel Updaten, da dort evtl auch Dateien eingebunden sind, die auf den alten Pfad verweisen. Das sollte aber super klappen, habe ich auch mehrfach so gemacht.
______________________________________
Drupalentwicklung und Beratung, Drupal Business Application Framework
Kleine Anschlussfrage: Wie schütze ich Benutzerbilder?
am 01.02.2011 - 20:59 Uhr
Welchen Weg gibt es Benutzerbilder ausschließlich registrierten Mitgliedern zugänglich zu machen und die Benutzerbilder vor jeder Art von Fremdzugriff zu schützen?
Ich frage das an dieser Stelle, weil ich es auch über "private files" versucht habe. Hier sind die Bilder aber bei Angabe des entsprechenden Pfads (.../system/files/...) trotzdem für nicht registrierte Benutzer zugänglich und auch für Suchmaschinen indexierbar! Wie also kann ich die Benutzerbilder bei Drupal schützen?
Haben Gäste beide dir die
am 01.02.2011 - 22:34 Uhr
Haben Gäste beide dir die Berechtigung "View uploaded files"? Wenn ja, dann schalte die mal aus.
Danke für die schnelle Antwort, aber ...
am 01.02.2011 - 23:01 Uhr
die Berechtigung "View uploaded files" kann ich bei mir in Drupal 7! (hatte ich vergessen zu sagen) nicht finden. Weder bei "permissions" noch bei "file system". Eine solche Zeichenkette gibt es in Drupal 7 nicht; habe extra gerade noch mal nachgeschaut. Habe ich da etwas übersehen oder gibt es einen anderen Weg?
Sind Benutzerbilder wirklich unschützbar?
am 04.02.2011 - 11:38 Uhr
Ist es wirklich so, dass es in Drupal 7 aktuell keinen klaren Weg gibt, Bilder von Benutzern vor Zugriffen durch nicht-registrierte Personen und Suchmaschinen zu schützen?
Tineye macht Schutz von Benutzerbildern notwendig
am 06.02.2011 - 01:49 Uhr
Entschuldigt, wenn ich das Thema so hoch halte. Aber Dienste wie z.B. http://www.tineye.com machen in meinen Augen einen Schutz von Benutzerbildern zwingend erforderlich.
Ein Beispiel: Nimmt man z.B. den Pfad zu dem Bild auf der Seite http://www.weltgesundheitstag.de/2008index.htm und gibt diese URL bei Tineye ein, kommt man zu zahlreichen Seiten, die dieses Bild so oder in anderer Form verwenden. Das geht natürlich auch mit Benutzerbildern!
Aus diesem Grund finde ich eine Schutzmöglichket für Benutzerbilder sehr wichtig. Ich habe schon mehrere Stunden Forenbeiträge und Anleitungen durchsucht, aber leider keine Möglichkeit gefunden, für Benutzerbilder bei Drupal 7 Zugriffsrechte zu definieren. Gibt es vielleicht ein Modul, welches ich übersehen habe?
Das Benutzerbild hat doch ein
am 06.02.2011 - 10:15 Uhr
Das Benutzerbild hat doch ein Template user-picture.tpl.php , mit ein bisschen Theming läßt sich das auch lösen.
http://api.drupal.org/api/drupal/developer--theme.php/function/theme_use...
Gelöste Forenbeiträge mit [gelöst] im Titel ergänzen
Das Verhältnis anderen zu helfen muss höher sein, als von anderen Hilfe zu erfragen/erwarten.
mhhhh ...
am 07.02.2011 - 21:54 Uhr
Es erscheint mir als eine wenig glückliche Fügung, wenn jedes noch so unbedeutende Feld in einem Profil schützbar ist aber ausgerechnet das Benutzerbild nicht. :-( Leider findet sich für diese Tatsache auch kein Hinweis in der Dokumentation. Zugleich suggeriert die Verwendung von "private files" einen Schutz der dann ausgerechnet bei Benutzerbildern scheinbar nicht existiert.
Leider kenne ich mich zu wenig aus, um hier ein Modul für die Verwaltung der Zugriffsrechte für Benutzerbilder zu erstellen. Ich bin erst mit Drupal 7 wieder zu Drupal gekommen und nun erstmal ratlos...
Also ich verstehe dein
am 07.02.2011 - 22:04 Uhr
Also ich verstehe dein Problem nicht... Über die user-picture.tpl.php kannst du doch einschränken, wer die Bilder betrachten darf und wer nicht. Und wenn über das Template geregelt ist, dass Gäste das Bild nicht sehen können, ist doch alles in Ordnung, oder?
Ich bin mir sicher...
am 07.02.2011 - 22:16 Uhr
Ich bin mir sicher, dass es für viele Spezialisten hier - und sicher auch für Dich - kein Problem ist. Für mich ist es aber ein Problem, weil ich (noch) kein wirklicher Drupal-Kenner bin.
Ergänzung: Wäre über user-picture.tpl.php dann auch der direkte Aufruf über den Pfad .../system/files/... nicht mehr möglich, wenn die Bilder unter "private files" liegen?
Ich habe es bisher selbst
am 08.02.2011 - 11:57 Uhr
Ich habe es bisher selbst noch nicht genutzt, jedoch wenn es nur ein globalen Schalter gibt ala private Dateien sehen/nicht sehen, dann wird es schwierig.
Und du musst für die User-Bilder ein eigenen Pfad via Menü-Api registrieren, sowie es bei den privaten Dateien ist und diesem Pfad, vergibst du eine eigene Berechtigung ala "User-Bilder sehen" und lieferst die Bilder im entsprechenden Page-Callback aus. Zudem musst du das template preprocessen, damit dein Pfad für das User-Bild verwendet wird.
Also für jeden der sich mit PHP/Drupal-Api auskennt ein No-Brainer. Wichtig auch, die Dateien müssen außerhalb des Drupalroots liegen oder via .htaccess geschützt sein, sonst macht auch sowas kein Sinn.
Gelöste Forenbeiträge mit [gelöst] im Titel ergänzen
Das Verhältnis anderen zu helfen muss höher sein, als von anderen Hilfe zu erfragen/erwarten.
Bitte um Dokumentation
am 10.02.2011 - 11:13 Uhr
Für jemanden wie mich, der kein Drupal-Kenner ist, erscheint der Hinweis, dass ein Spezialist die Aufgabe lösen kann wenig hilfreich. Das gilt ja für fast jedes Problem. :-)
Ich halte jetzt mal als Ergebnis hier fest, dass es für den Schutz von Benutzerbildern bei Drupal 7 BISHER:
a) keinen eingebauten und aktivierbaren Schutz gibt
b) kein Modul gibt, um das Problem zu lösen
c) kein anderer sicherer und geprüfter Weg übernehmbar ist
und folglich erst noch eine Lösung zum Schutz von Benutzerbildern entwickelt werden muss!
Schlussfolgerung:
Für Drupal-Anfänger muss daher der Hinweis erlaubt sein, dass sie bisher keine Möglichkeit haben, die Bilder von Benutzern vor Zugriffen Dritter zu schützen!
Solange das noch so ist, sollte das nach meiner Meinung an prominenter Stelle (Handbuch, FAQ) offen kommuniziert werden, um Enttäuschungen vorzubeugen.
Zitat: Solange das noch so
am 10.02.2011 - 19:44 Uhr
Solange das noch so ist, sollte das nach meiner Meinung an prominenter Stelle (Handbuch, FAQ) offen kommuniziert werden, um Enttäuschungen vorzubeugen.
Wie auch schon an anderer Stelle geschrieben: Die User können auch gern selbst noch ein wenig was machen.
Wenn man mit Drupal arbeitet, dann findet man schon heraus, was es kann und was nicht. Man kann doch keine Liste erstellen, in der genau steht, was Drupal kann und was nicht. Obwohl, könnte man, die hätte eigentlich zwei Punkte:
Was Drupal kann:
alles (wenn man sich die nötigen Kenntnisse aneignet)
Was Drupal nicht kann:
-
Dafür ist kein Spezialist notwendig, aber wenn du mit Drupal arbeiten willst, musst du eben mal ein paar Stunden / Tage investieren und ein ordentliches Tutorial durcharbeiten (http://cocoate.com/de/drupal-6-deutsch). Dann kannst du dich hier im DC noch etwas im Handbuch umsehen und dann kannst du solche Probleme ganz allein lösen.
Was bringt es, wenn wir dir jetzt vorbeten, was du machen müsstest und du keine Ahnung hast, was du da eigentlich anstellst? Gar nichts, das ist im Gegenteil eher gefährlich. Wenn du aber in Drupal selbst durchsteigst, kannst du auch die Tipps von Tobias umsetzen.
Drupal ist nichts, wo man sich mal eben hinsetzt und etwas zusammenklickt. Da gibt's nicht für jeden SchnickSchnack einen Schalter und dann nimmt dieser einem alle Arbeit ab. Man muss sich eben in Drupal einarbeiten und das System verstehen und dann kann man ordentlich damit arbeiten.
Unterschiedliche Ebenen
am 10.02.2011 - 21:21 Uhr
Ich denke es gibt unterschiedliche Arten von Drupal-Nutzern, die mehr oder weniger tief in die Materie einsteigen (können). Der Hinweis, dass ein Problem selbst lösbar ist, wenn man sich einarbeitet, kommt einem Truismus nahe. Drupal, PHP, MySQL etc. sind aufwandsreduzierende Systeme. Würden wir sie nicht nutzen, müssten wir ja immer bei Maxwell u.A. beginnen. Wer will das schon. :-)
Der Hinweis, dass man nur tiefer einsteigen muss, ist daher natürlich inhaltlich korrekt. Er führt aber auf eine andere Ebene in der Kaskade der Aufwandsreduzierung. Eine Ebene die ein neuer Nutzer, der seine erste Drupal-Seite aufsetzt, i.d.R. noch nicht betritt. Dieser Nutzer ist nach meiner Auffassung insbesondere bei Fragen, die den Schutz persönlicher Daten betreffen - wie in diesem Fall das Benutzerbild - informationsbedürftig. Es geht also hierbei nicht um irgendeine Feature-Liste. Daher halte ich die oben geäußerte Schlussfolgerung für wichtig, SOFERN sie denn zutreffend ist! Nichts wäre mir in diesem Fall aber lieber, als mich geirrt zu haben ...
Zitat: Daher halte ich die
am 10.02.2011 - 21:40 Uhr
Daher halte ich die oben geäußerte Schlussfolgerung für wichtig
Sie ist aber im Grunde falsch. Soll jetzt irgendwo stehen "Benutzerbilder können nicht geschützt werden"? Die einen interessiert das nicht, weil sie es nicht benötigen, für die anderen ist es wichtig. So verhält es sich mit allen Dingen. Deswegen ist so eine Schlussfolgerung unsinnig, denn daraus ergibt sich die Frage, welche Infos denn an "prominenter Stelle kommuniziert" werden sollen und welche nicht. Wer entscheidet das? Da landest du dann eben schnell bei "ganz oder gar nicht".
Außerdem ist es wie gesagt nicht unmöglich. Es gibt Mittel und Wege, aber die muss man sich eben erarbeiten. Drupal ist kein Baukasten-Klick-System.
Eine Ebene die ein neuer Nutzer, der seine erste Drupal-Seite aufsetzt, i.d.R. noch nicht betritt
Und das ist - meiner Meinung nach - noch viel falscher seitens der Nutzer. Ich glaube, wer ein System wie Drupal verwenden will, sollte vorher unbedingt ein wenig Zeit investieren und sich zumindest grundlegend mit dem System und seinen Möglichkeiten befassen. Immerhin will man eine Website aufsetzen, da sollte man wissen, was man macht.
Zu sagen "Das ist meine erste Seite, da steige ich nicht so tief ein" ist in meinen Augen das falscheste, was man machen kann. Wenn man keine Ahnung von PHP, CSS und Javascript hat und sagt "ich arbeite erstmal soweit es geht mit Drupal und die tieferen Kenntnisse eigne ich mir nach und nach an" ist völlig in Ordnung. Und wenn man völlig ohne PHP, CSS und Co. auskommt und einem die Drupal-Mittel reichen - auch gut, glückwunsch. Aber wenn man Drupal als Basis verwendet, sollte man diese Basis auch verstehen. Du kannst kein Haus auf einem dir unbekannten Fundament bauen.
Entschuldigung
am 10.02.2011 - 22:18 Uhr
aber wenn in einer Dokumentation - und damit gibt es folglich Bereiche, wo Informationen für Benutzer an prominenter Stelle untergebracht sind - mit Begriffen wie "privat modus" und der Darstellung bestimmter Verfahren zum Schutz von Dateien gearbeitet wird, dann muss es an diesen Stellen auch erlaubt sein zu sagen, wo dieser Schutz aktuell nicht greift, weil sonst der Eindruck entsteht, alle persönlichen Informationen wären bei Anwendung bestimmter Verfahren geschützt. Das ist aber vermutlich nicht gegeben! Ich sehe daher darin keine Schande darüber zu informieren, solange das der Fall ist. Wofür ist sonst eine Dokumentation dar? Umgekehrt finde ich eher das Auslassen dieser Information - obwohl bekannt - gerade bei persönlichen Daten wie dem Benutzerbild äußerst probematisch. Wenn das Problem gelöst ist, kann so ein Handbuch ja wieder geändert werden. Und gut ist es.
Zum zweiten Punkt: Das hier angesprochene Problem der Benutzerbilder ist kein Problem, welches mit einem Grundwissen in PHP, CSS und Co. und einem Grundwissen in Drupal lösbar ist. Um es zu lösen - es wirklich zu lösen - braucht es schon deutlich fundiertere Kenntnisse von Drupal. Und das ist, wie oben gesagt, für viele Nutzer eine andere Ebene.
Zitat: Zum zweiten Punkt: Das
am 10.02.2011 - 22:35 Uhr
Zum zweiten Punkt: Das hier angesprochene Problem der Benutzerbilder ist kein Problem, welches mit einem Grundwissen in PHP, CSS und Co. und einem Grundwissen in Drupal lösbar ist. Um es zu lösen - es wirklich zu lösen - braucht es schon deutlich fundiertere Kenntnisse von Drupal. Und das ist, wie oben gesagt, für viele Nutzer eine andere Ebene.
Ein wenig Theming, ein wenig in hooks einlesen, der Rest ist nachdenken. Da gehen wohl unsere Meinungen außeinander, aber "deutlich fundiertere Kenntnisse" sind meines Erachtens nach nötig, um recht komplexe Dinge zu bewerkstelligen - ein eigenes CCK-Widget und ähnliches. Aber das hier ist eigentlich noch kein Thema.
Ergebnis
am 10.02.2011 - 23:05 Uhr
Es ist vermutlich wenig fruchtbar darüber zu diskutieren, ab wo nun Expertentum beginnt. Der Ursprung meiner Frage beim Einstieg in diese Diskussion war, ob es eine Möglichkeit gibt Benutzerbilder zu schützen.
Die Antwort ist: Es gibt nach bisherigem Kenntnisstand keine vorhandene, erprobte und direkt einsetzbare Lösung. Benutzerbilder sind z.Z. weder durch den Drupal-Kern noch durch ein Drupal-Modul schützbar. Sie sind aktuell immer zugänglich. Auch ein Umschalten auf "private modus" ändert daran nichts.
Obsolet ist der Hinweis selber zu programmieren. Die Antwort ist auf nahezu jede Frage möglich und liegt bei einem offenen System wie Drupal auf der Hand.
Ich muss jetzt mal ganz doof
am 10.02.2011 - 23:12 Uhr
Ich muss jetzt mal ganz doof fragen:
Ich habe Drupal 7 im übrigen noch nicht selbst verwendet, aber der privat-Modus wird dem in D6 ähneln.
Wo werden die Benutzerbilder denn bei dir gespeichert? auch in sites/default/files? Und hast du nur auf den Privat-Modus umgeschaltet oder hast du auch die damit verbundenen Änderungen am Dateisystem vorgenommen?
Einstellungen
am 11.02.2011 - 00:04 Uhr
Die Dateien liegen außerhalb vom Web-Verzeichnis.
Der passende Pfad ist in Drupal angegeben.
Es ist umgeschaltet auf "private files".
Die Benutzerbilder werden ausgeliefert über: .../system/files/... sowohl an registrierte als auch nicht-registrierte Benutzer.
Widerspruch erwünscht :-)
am 14.02.2011 - 14:53 Uhr
Es gibt wohl leider keinen Widerspruch, dass die Benutzerbilder bei Drupal 7 aktuell weder via Core noch über Modules schützbar sind, oder?
Schade, ich würde mich sehr gerne irren.
Weiteres Sicherheitsproblem möglich!
am 16.02.2011 - 21:18 Uhr
Bei weiteren Tests zeigt sich, dass aktuell auch andere Dateien bei der Einstellung "private files" an nicht-registrierte Benutzer von Drupal 7 via .../system/files/... ausgeliefert werden können. Ob es eine Konfigurationsfrage oder ein generelles Problem ist, ist noch offen. In jedem Fall ist z.Z. der Schutz von Dateien in Drupal 7 noch nicht sicher gegeben! Daher: Vorsicht beim Einstellen nicht öffentlicher Dateien in Drupal 7!
Bilder schuetzen
am 19.02.2011 - 21:28 Uhr
habe mir vor laengerer Zeit mal unten stehendes in die .htaccess gesetzt, weil Leute aus irgend einem Forum zu Bildern hier auf meinem Server verlinkt hatten. (War ein gefundener Tip aus dem Inet)
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?domain.com/.*$ [NC]
RewriteCond %{REQUEST_FILENAME} !dieb.gif$
RewriteRule .*\.(gif|jpe?g|png|bmp|pdf|rar|mp3|js)$ http://www.domain.com/images/dieb.gif [R]
Vielleicht hilft es ein wenig weiter?
Tschau