Bilder und Suchmaschinen

[Treziman]

Hallo werte Gemeinde der willkürlichen Computermanipulation.😀 Ich grüsse alle, nachdem ich längere Zeit nicht mehr hier war.

Zu meinem Anliegen, wozu mir die Insider-Infos fehlen und ich im Internet nicht wirklich Hilfe fand. Wie unter Betreff genannt, geht es um Bilder (Fotos), die von Suchmaschinen (Crawlern) nicht gefunden werden sollen. Ich habe ein Projekt gebaut, wo User Fotos hochladen können. Diese Fotos werden in einem Ordner (Bsp.:"Bilder") abgelegt. Auf dem heimischen PC unter XAMPP liegt dieser Ordner ausserhalb des Document Root und man kann von den Scripten darauf zugreifen. Beim Hoster geht das nicht! Hier geht nur folgendes: Webroot: www.beispiel.de → Beispiel1(Ordner) → index.html + bilder(Ordner) Lege ich den Ordner "bilder" auf dieselbe Ebene wie "Beispiel1", gehts nicht mehr.

Meine Frage also: Wie kann ich am besten verhindern, dass Crawler auf den Ordner "bilder" zugreifen und die Fotos auslesen? Es wäre dumm, finden User ihre Fotos irgendwann bei Google und Co.

Mit der robots.txt soll es ja nicht zuverlässig klappen und die Fotos in der Datenbank ablegen, soll Performanceverlust bringen. Ausserdem würde die DB vermutlich aus allen Nähten platzen.

Ich danke Euch schonmal im Voraus für Anregungen und Hilfe. Gruss Treziman

[MudGuard]

Hi,

Auf dem heimischen PC unter XAMPP liegt dieser Ordner ausserhalb des Document Root und man kann von den Scripten darauf zugreifen. Beim Hoster geht das nicht!

Dann solltest Du darüber nachdenken, den Hoster zu wechseln.

Verzeichnisse außerhalb Document Root sollten die meisten Hoster anbieten …

cu,
Andreas a/k/a MudGuard

[Treziman]

Hallo Andreas, danke für Deine Antwort. Ich habe über eine halbe Stunde mit dem Support meines Hosters teleniert. Die haben es selbst versucht - es ging nicht. Da habe ich schon dran gedacht zu wechseln. Ist nur blöd, weil ich bin gerade etwas mehr als eine Woche dabei, habe alles eingerichtet und nun das. Aber Sicherheit geht vor! Wenn sich keine andere Lösung, z.B. über "noindex, nofollow" oder so, bietet, was auch sicher sein muss, werde ich wohl wechseln.

Gruss Treziman

[Raketenwilli]

Verzeichnisse außerhalb Document Root sollten die meisten Hoster anbieten …

(I) Dödl-Hoster sparen so 50% der telefonischen Support-Anfragen, die darauf hinauslaufen, dass die Kunden eine index.htm im Heimatverzeichnis angelegt haben und trotzdem eine Webseite des Hosters erscheint, wonach der Online-Auftritt bei eben dem Hoster tollen gebucht - aber noch nicht errichtet worden sei.

(II) Und diese dann durch das Konfigurationsmenü zu führen braucht Fachkräfte Personen mit Hirn - die dann aber wieder nicht dazu bereit sind, sich vom „sozial höchst engagierten Unternehmen“ (hat vor 10 Jahren mal auf fiskalisch besonders lohnende Weise einen „Lichtwasserfall“ für eine werbewirksame blonde „Lisa“ (III) mit(sic!) „finanziert“) nur 50% der Telefonzeit - immerhin mit dem Mindestlohn - bezahlen zu lassen, weil die ja für den Support und nicht für den Austausch von Freundlichkeiten bezahlt werden.

[Felix Riesterer]

Lieber Treziman,

Auf dem heimischen PC unter XAMPP liegt dieser Ordner ausserhalb des Document Root und man kann von den Scripten darauf zugreifen. Beim Hoster geht das nicht!

dann hilft nur noch ein Bilder-Verzeichnis, welches mittels AuthBasic (Passwortschutz via .htaccess) gegen jeden HTTP-Zugriff geschützt ist. Das Anzeigen der Bilder ist dann nur über Deine Scripte möglich, wenn sich ein User angemeldet hat. Sollte der Hoster auch das nicht anbieten können, sehe ich absolut schwarz!

Liebe Grüße

Felix Riesterer

[Treziman]

Hallo Felix, auch Dir ein Dankeschön für die Antwort. Ich habe gerade via Email nochmals eine Anfrage an den Support meines Hosters gestellt mit der Frage, ob sie 1. ein Verzeichnis ausserhalb des Webroot erreichbar machen können oder 2. ob es mir möglich ist, mit einer .htaccess zu arbeiten. Mal sehen...

Nur schonmal des besseren Verständnisses wegen: Eine .htaccess, muss die VOR den Ordner oder IN den Ordner? Ich habe damit noch nicht gearbeitet.

Hier mal meine Struktur mit den Bildern:

bilder(Verzeichnis) → darin: user1(Verz.) user2(Verz.) user10(Verz.) usw. In jedem dieser user-Verzeichnisse befinden sich eben die Fotos der entsprechenden User.

Ich müsste also das Oberverzeichnis, in dem Fall "bilder" mit einer .htaccess sichern?

Gruss Treziman

[Matthias Scharwies]

Servus!

Zu meinem Anliegen, wozu mir die Insider-Infos fehlen und ich im Internet nicht wirklich Hilfe fand.

Habe grad mal im SELF-Wiki geschaut:

• Robots.txt

Bereits in der Einführung wird dieser Artikel erwähnt und verlinkt:

• Webserver/htaccess/Zugriffskontrolle

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo zusammen,

das ist doch alles kein Problem. Oder übersehe ich im Folgenden das offenstehende Scheunentor, während ich den Büroeingang vernagele?

• Man sorge dafür, dass nirgendwo ein Link auf /bilder/xyz.jpg publiziert ist. Und schon schon wird kein Crawler die Datei /bilder/xyz.jpg auch nur mit dem digitalen A.... anschauen.
• Zur Sicherheit kann man den "well known folder" /bilder umbenennen. Man nehme eine Katze und setze sie auf die Tastatur, und erhält beispielsweise /kldjfr894e2309r4309423ur09jig420 als Ordnername. Na gut, es gibt für diesen Zweck auch virtuelle Katzen. Nimmt man Kleinbuchstaben, Großbuchstaben und Ziffern, und macht den Ordnernamen 32 Stellen lang, gibt es $$2\cdot 10^{52}$$ mögliche Ordnernamen. Da dauert das Erraten ein wenig. Solange niemand den Namen verpetzt.
• Zur Abwehr von Petzern kann man Felix Idee mit dem Passwortschutz aufgreifen, oder ganz einfach in der .htaccess einen Alias setzen, der alle Zugriffe auf den erzeugten Katzendreck ins Katzenklo schickt. Das Aliasziel sollte es dann schlicht nicht geben (oder es ist ein leerer Ordner, wenn der Apache das nicht mag). Damit ist der Ordner per Browser komplett unerreichbar und kann auch genauso gut "bilder" heißen.
• Die Bilder sind dann nur noch über das PHP Script zugänglich, das die Zugriffsberechtigung überprüft.

Und fertig.

Security by Obscurity ist zwar im Allgemeinen ein Unfall, der nur darauf wartet, zu passieren, aber auf diesem Weg sollte der Unfall SEHR unwahrscheinlich sein.

Rolf

[Felix Riesterer]

Lieber Rolf,

Security by Obscurity ist zwar im Allgemeinen ein Unfall, der nur darauf wartet, zu passieren, aber auf diesem Weg sollte der Unfall SEHR unwahrscheinlich sein.

warum nicht gleich richtig? Ohne einen Passwortschutz ist das alles reichlich sinnlos, weil wir uns dann im könnte-müsste-sollte-Bereich bewegen. Das wollen Informatiker eigentlich nie, wenn es um Funktionalitäten geht.

Liebe Grüße

Felix Riesterer

[Raketenwilli]

warum nicht gleich richtig? Ohne einen Passwortschutz ist das alles reichlich sinnlos,

Sehen wir mal, was Rolf gezeigt hat:

1. Verteidungslinie: Ordner und Bilder NIRGENDWO verlinken oder auch nur nennen UND klassische, erratbare Ordnernamen vermeiden (statt dessen zufälliger Name)

2. Verteidungslinie: In der .htaccess einen Alias setzen, welche Zugriffe via HTTP auf eben diesen Ordner auf einen nicht existenten Ordner verweist.

Test:

Alias "/foo" "/bar"

Hierzu sagt mein Apache via error.log:

/var/www/test/.htaccess: Alias not allowed here

Einem Angreifer wird verraten, dass das Verzeichnis wahrscheinlich(sic!) existiert. Meiden.

Aber ein Rewrite geht und ist „Alias genug“:

RewriteEngine On
RewriteRule "^guuvzvtUZT345u56JhGjuUr86/.*$" "/fake404.html" [R=404, L]

Freilich muss der Hoster dazu mod_rewrite erlauben...

Alternative:

chmod a-rwx .htaccess

Das Verzeichnis wird unbenutzbar, aber der „Angreifer“ bekommt verpetzt, dass das Verzeichnis existiert. Meiden.

3. Verteidungslinie: Deine Idee mit dem Passwortschutz sollte, so Rolf, zusätzlich aufgegriffen werden. (Das ist dann die Dritte Verteidigungslinie)

Klar ist, dass das all dieses die zweitbeste Lösung ist, aber die beste (Ordner außerhalb von Dokument-Root) geht halt nicht.

Ergänzend zur 1. Verteidigungsline: Nichts ist dümmer als das Verzeichnis in einer robots.txt zu nennen oder sonstwie darum zu bitten, dieses nicht zu öffnen. Da kann man auch eine Bank eröffnen, im Kundenbereich einen Taster installieren und daneben ein Schild aufstellen: „Diesen Knopf nicht drücken, sonst geht der Tresor auf und nicht wieder zu.“

[Linuchs]

Hallo Treziman,

Wie kann ich am besten verhindern, dass Crawler auf den Ordner "bilder" zugreifen und die Fotos auslesen?

Der Ordner müsste blockiert sein, wenn kein Leserecht eingeräumt wird.

Du verrätst nicht, was mit den Bildern passieren soll. Fürs Hochladen reicht das Schreibrecht.

[Treziman]

Danke an alle für Eure Antworten.

Man sorge dafür, dass nirgendwo ein Link auf /bilder/xyz.jpg publiziert ist. Und schon schon wird kein Crawler die Datei /bilder/xyz.jpg auch nur mit dem digitalen A.... anschauen.

Ist das sicher? Die Fotos der User sind natürlich nicht dauerhaft verlinkt, werden erst sichtbar wenn ein anderer User das Profil besucht.

Der Ordner "bilder" heisst natürlich anders, hier im Forum nur als Beispiel.

@Rolf B: Die Namen der Unterordner, in denen jeder User seine Fotos speichert, werden per Zufall beim Registrieren erstellt und sind 20stellig. Also:

/bilder/

dhfu4736fhgfug7ZT678 / BHg459jd5TRjhhjj.jpg (Bsp. erstes Foto)

dhfu4736fhgfug7ZT678 / BHgsgvcb78rjhhio.jpg (Bsp. zweites Foto) usw.

Die Reihenfolge wird in der DB festgelegt, in der der Bildpfad und die Bildnamen gespeichert sind.

@Linuchs: Nach Aussage meines Hostersupports haben die Rechte der Verzeichnisse (mittels chmod()) keinen Einfluss auf Crawler.

Meine momentane Idee: robots.txt raus, Meta-Tag: robots-noindex,nofollow (funktioniert beides ja nicht zusammen), und eine .htaccess, die den Zugriff auf den Ordner Bilder verhindert.

Vielleicht sehe ich da auch etwas falsch. Nach meinem Verständnis kommt ein Crawler über die Domain ins Homeverzeichnis, findet da u.a. den Ordner Bilder, geht da hinein, findet die Unterordner, geht da wieder hinein und findet sämtliche Fotos einzelner User, die der Crawler nun als Suchergebnisse weitergibt. Wenn man nun bei Google die Domain eingibt und auf Bilder klickt, würden diese Fotos als Suchergebnisse angezeigt. Wäre schön wenn ich mich hier irre...

Erstmal Grüsse und nochmals danke.

[Der Martin]

n'Abend,

Man sorge dafür, dass nirgendwo ein Link auf /bilder/xyz.jpg publiziert ist. Und schon schon wird kein Crawler die Datei /bilder/xyz.jpg auch nur mit dem digitalen A.... anschauen.

Ist das sicher?

naja, fast. Ein Crawler kann eine Ressource nur abrufen und abfragen, wenn er deren URL kennt.

@Linuchs: Nach Aussage meines Hostersupports haben die Rechte der Verzeichnisse (mittels chmod()) keinen Einfluss auf Crawler.

Das stimmt so nicht. Wenn man dem Verzeichnis für den User, unter dem der Webserver läuft, die Leserechte entzieht, kann der Webserver nicht mehr darauf zugreifen.

Vielleicht sehe ich da auch etwas falsch. Nach meinem Verständnis kommt ein Crawler über die Domain ins Homeverzeichnis, findet da u.a. den Ordner Bilder, geht da hinein, findet die Unterordner, geht da wieder hinein und findet sämtliche Fotos einzelner User

Falsch. Das gibt HTTP nicht her. Der Crawler "sieht" auch nicht mehr als ein gewöhnlicher Besucher mit einem herkömmlichen Browser.

Einen schönen Tag noch
 Martin

[Treziman]

Vielleicht sehe ich da auch etwas falsch. Nach meinem Verständnis kommt ein Crawler über die Domain ins Homeverzeichnis, findet da u.a. den Ordner Bilder, geht da hinein, findet die Unterordner, geht da wieder hinein und findet sämtliche Fotos einzelner User

Falsch. Das gibt HTTP nicht her. Der Crawler "sieht" auch nicht mehr als ein gewöhnlicher Besucher mit einem herkömmlichen Browser.

Aha, demnach müsste man nur verhindern, dass ein Crawler weiter in den Verzeichnisstamm vordringt, damit er keinen Link (img-Tag) findet? Das müsste mit Meta-Tag ... noindex, nofollow zu machen sein?

[Rolf B]

Hallo Treziman,

dass ein Crawler weiter in den Verzeichnisstamm vordringt,

Das tut er von sich aus nicht, weil er es im Normalfall nicht kann. Ein Crawler folgt Links, er kann Verzeichnisse nur lesen, wenn sie auch vom Browser abrufbar sind. Sowas kann man serverseitig aktivieren, das ist aber standardmäßig nicht der Fall.

Wenn der Ordner "bilder" heißt und der Abruf von https://www.example.com/bilder im Browser den Inhalt des Ordners auflistet, dann ist das aktiv und gehört abgeschaltet.

Wie man es richtig(er) macht, steht schon in anderen Antworten geschrieben.

Rolf

[Treziman]

Hallo Rolf, ich habe https://www.example.de/bilder/ (mit den korrekten Namen) gerade mal probiert und erhalte folgende Meldung vom Browser:

Zugriff verweigert! Der Zugriff auf das angeforderte Verzeichnis ist nicht möglich. Entweder ist kein Index-Dokument vorhanden oder das Verzeichnis ist zugriffsgeschützt.

Sofern Sie dies für eine Fehlfunktion des Servers halten, informieren Sie bitte den Webmaster hierüber.

Error 403

???

Desweiteren werden die Fotos nicht absolut addressiert sondern "rückwärts":

<img src='../../example.jpg' />

[Rolf B]

Hallo Treziman,

Zugriff verweigert!

Das ist das, was ich meinte. Diese Fehlermeldung ist die Sperre, die die Crawler der Suchmaschinen daran hindert, deine Bilder-Ordner "einfach so" aufzulisten.

Desweiteren werden die Fotos nicht absolut addressiert sondern "rückwärts":
<img src='../../example.jpg' />

?!??

Ich greife mal dein eigenes Beispiel von heute 19:44 Uhr auf.

Wenn ein Bild auf deinem Server die Adresse

/bilder/dhfu4736fhgfug7ZT678/BHg459jd5TRjhhjj.jpg

hat, dann muss der "aktuelle Ordner" aus Sicher des Browser so etwas wie

/bilder/dhfu4736fhgfug7ZT678/foo/bar

sein, damit eine Adressierung über den relativen Pfad ../../ funktioniert. So langsam wird es richtig verwirrend, was Du da treibst.

Und wie gesagt: Die Bilder direkt vom Browser laden zu lassen verpetzt deren Speicherort, Du musst Die Bilder durch ein PHP Script aus ihrem Speicherort zum Browser schicken. Nur dann kannst Du je User den Zugriff kontrollieren und ihren physischen Speicherort vor der "Außenwelt" verbergen. Wenn der Speicherort hinreichend vor Browserzugriffen geschützt ist (ich schrieb dazu ja schon), ist es egal, ob er innerhalb oder außerhalb des Document Root liegt.

Das heißt: Dein img Element sollte so aussehen:

<img src='get_image.php?user=fridolin&name=wunderschoen.jpg'>

Das get_image Script lädt dann das Bild wunderschoen.jpg des Benutzers Fridolin, und weiß über die Bilderdatenbank, dass es dazu die Datei /bilder/dhfu4736fhgfug7ZT678/BHg459jd5TRjhhjj.jpg mit einem passenden Content-Type für jpg-Bilder zum Browser kopieren muss. Wie das geht: siehe meinen Link zu readfile von vorhin. An Hand der Session kann das get_image Script feststellen, wer zugreift und prüfen, ob dieser Jemand das Recht hat, die Bilder von Fridolin zu sehen.

Anders geht das nicht. Eine URI - relativ oder absolut - ins HTML zu schreiben, mit der der Browser das Bild direkt laden kann, öffnet unbefugten Zugriffen die Türe, und wenn Du tatsächlich im Stande wärest, die Bilder außerhalb des Document Root abzulegen, würde ein solcher Zugriff auch gar nicht funktionieren.

Rolf

[Treziman]

Ja supi, Rolf! Vielen Dank für diesen konkreten Tip! Damit werde ich mich jetzt beschäftigen.

Ich will jetzt nicht weiter "verwirren" aber etwas ähnliches habe ich gemacht. Ich habe eine Datei "imageload.php" geschrieben. Da wird allerdings nur geprüft, ob der User, der das Bild angezeigt bekommen soll, auch eine aktive Session gestartet hat, also eingeloggt ist. Das Bild wird allerdings eben dann doch über ein img-Tag relativ angezeigt.

Ich schaue hier aber trotz allem noch rein. Vielleicht kommt ja noch der ein oder andere Knackpunkt zum Vorschein.

Nochmals danke und Gruss Treziman

[Treziman]

Hey Rolf, das funzt!

Ich habe testhalber Dein Beispiel mit readfile 1 zu 1 kopiert und etwas angepasst:

In Datei get_image.php: $file="../../bilder/".$_GET["bild"];

Auf der aufrufenden Seite:

<img class='testbild' src='scripte/get_img.php?bild=testbild.jpg' />

Im Quelltext erscheint genau dieses img-Tag. Klickt man darauf kommt Kauderwelsch, unleserliches Zeug! Super!

Den Bildnamen werde ich auch noch verschleiern.

Diese Lösung zusammen mit einer .htaccess sollte den Laden dichtmachen, oder?

Vielen vielen Dank und Gruss Treziman (Torsten)

[Der Martin]

Hallo,

In Datei get_image.php: $file="../../bilder/".$_GET["bild"];

da gehören unbedingt noch ein paar Sicherheitsmaßnahmen dazu!! So wie es im Moment dasteht, kann jeder beliebige Nutzer jede Datei herunterladen, auf die der Webserver zugreifen kann. Wie wär's damit:

get_img.php?bild=%2Ehtaccess

So bekomme ich deine .htaccess-Datei und kann mir in Ruhe ansehen, was du da eingestellt hast.

get_img.php?bild=/etc/fstab

Damit bekomme ich eine zentrale Konfigurationsdatei des Betriebssystems, unter dem der Webserver läuft, und kann mir anschauen, was für Dateisysteme da gemountet sind und welche fürs weitere Stochern interessant sein könnten. Ob's mir nützt? Vermutlich nicht, aber ich hoffe, du erkennst die Gefahr.

Im Quelltext erscheint genau dieses img-Tag. Klickt man darauf kommt Kauderwelsch, unleserliches Zeug! Super!

Dieses Kauderwelsch wird zu einem Bild, wenn du dem Browser auch noch mitteilst, dass es eins ist. Sende dazu als erste Anweisung im Script den Content-Type-Header image/jpeg.

Den Bildnamen werde ich auch noch verschleiern.

Wozu?

Diese Lösung zusammen mit einer .htaccess sollte den Laden dichtmachen, oder?

Ja, aber mit den eingangs erwähnten gravierenden Mängeln.

Einen schönen Tag noch
 Martin

[Treziman]

Hallo Martin, danke für die Warnungen! Ich wusste, da kommt noch was...

Dieses Kauderwelsch wird zu einem Bild, wenn du dem Browser auch noch mitteilst, dass es eins ist. Sende dazu als erste Anweisung im Script den Content-Type-Header image/jpeg.

Soll ja eben nicht!

Ansonsten:

Die Bilder werden vom Script korrekt angezeigt. Nur eben nicht im Quelltext. Das ist okay.

Ich arbeite gerade an der get_image.php. Sieht z.Zt. so aus:

session_start();

if(isset($_SESSION["user_xyz"])) { // User ist eingeloggt-darf auf Bilder zugreifen

$name=$_GET["bild"];

if($name=="Suse"){
$datei="../bilder/klaus1.jpg";
}elseif($name=="winter"){
$datei="../bilder/sommer1.jpg;
}elseif(etc.){
usw.
}...{
...
}else{
$file="../forbidden.gif";
}

}else{// User ist nicht eingeloggt

$file="../forbidden.gif";

}
Hier folgt der Code von Rolfs Hinweis

Wenn also php (if...) keinen gültigen Wert findet, wird forbidden.gif angezeigt.

Sobald fertig werde ich das Ganze natürlich noch testen, vor allem sicher auch über Direkteingabe in Adressleiste des Browsers. Falls dann etwas nicht stimmt, kann ich dagegenwirken.

Gruss Treziman

[Felix Riesterer]

Lieber Treziman,

Ich wusste, da kommt noch was...

und was hast Du als Vorbereitung dafür bereits in die Wege geleitet?

Die Bilder werden vom Script korrekt angezeigt. Nur eben nicht im Quelltext. Das ist okay.

Diese Aussage klingt nach absolut konfusem Blödsinn, aber das kann auch an meiner Begriffsstutzigkeit liegen.

Ich arbeite gerade an der get_image.php. Sieht z.Zt. so aus:

Welch ein Graus! Da sind böse Anfängerfehler drin. Da kann ich nur hoffen, dass Du aus Demozwecken den tatsächlichen Code für das Posting verändert hast.

session_start();

if(isset($_SESSION["user_xyz"])) { // User ist eingeloggt-darf auf Bilder zugreifen

Ist das wirklich der Schlüssel im _SESSION-Array? Da hätte ich jetzt eher etwas in dieser Art erwartet:

$_SESSION = [
  'user' => 'user_xyz',
  'token' => 'secret'
];

Und dann kann ein Script anhand des Schlüssels user ermitteln, ob es wirklich einen solchen Eintrag in der DB gibt und ob sich der Benutzer auch korrekt authentifiziert hat. Einfach so den User-Namen als Session-Schlüssel zu verwenden... naja, vielleicht ist das ja sinnvoll - oder Du hast in Wirklichkeit einen anderen Code und hier nur für Demo-Zwecke etwas vereinfacht.

$name=$_GET["bild"];

if($name=="Suse"){
$datei="../bilder/klaus1.jpg";
}elseif($name=="winter"){
$datei="../bilder/sommer1.jpg;
}elseif(etc.){
usw.

Hier ist der Teil, bei dem ich mich echt wundern muss.

1. Warum wird der Wert in $_GET["bild"] in eine Variable umkopiert? Das verschleiert im weiteren Verlauf des Scripts nur, dass er potenziell böse ist! @Der Martin nannte /etc/fstab als Beispiel für solche Fälle.
2. Warum diese Serie an if...elseif? Da verwendet man eine Liste (Array) an Werten (wahrscheinlich aus einer Datenbank), gegen die man in einer Schleife (foreach) prüft.
3. Wenn Du eine Dateinamensänderung vornimmst, dann sicherlich nur deswegen, weil Du gleichlautende Dateinamen von unterschiedlichen Uploads gegen Dateiüberschreibungen härten willst. Diese Zuordnung von Upload-Name und tatsächlichem Dateiname auf dem Server sollte auch wieder programmatisch erfolgen und nicht hartcodiert. Ist das auch wieder eine Vereinfachung für's Forum von Dir?

Wenn also php (if...) keinen gültigen Wert findet, wird forbidden.gif angezeigt.

Wie genau? Den wirklich interessanten Code für die Auslieferung der Datei zeigst Du gerade nicht, dabei war dieser der wesentliche Diskussionsgegenstand. Schade!

Sobald fertig werde ich das Ganze natürlich noch testen, vor allem sicher auch über Direkteingabe in Adressleiste des Browsers. Falls dann etwas nicht stimmt, kann ich dagegenwirken.

Ich habe noch immer den schweren Verdacht, dass Du nach wie vor nicht verstanden hast, worum es uns bei unseren Warnungen wirklich geht... oder ich habe alles nur nicht so richtig verstanden.

Liebe Grüße

Felix Riesterer

[Treziman]

Einfach so den User-Namen als Session-Schlüssel zu verwenden... naja, vielleicht ist das ja sinnvoll - oder Du hast in Wirklichkeit einen anderen Code und hier nur für Demo-Zwecke etwas vereinfacht.

Hallo? Bin ich von gestern?😃

Selbstverständlich ist der Code komplett anders! Selbstverständlich sind sämtliche Namen, Schlüssel und Indexes vollkommen anders! Was ich hier poste dient, wie Felix absolut richtig vermutet, nur zu Demo-Zwecken!

Ich werde, mit Verlaub gesagt, einen Teufel tun und meine Scripte öffentlich machen.

Der php-Schnipsel sieht auch anders aus als hier von mir eingestellt. Es gibt in echt lediglich 4 if - elseif - Abfragen, da ich, was ich brauche, zuvor aus der DB hole.

Okay, ihr kennt jetzt meine Struktur nicht. Weiter oben hab ichs mal geschrieben. Jeder User hat einen eigenen Bilderordner mit individuellem und zufälligem Namen. Desweiteren wird auch jedes Bild mit einem zufälligen Namen versehen. Die Zuordnung ergibt sich aus der DB.

Wie genau? Den wirklich interessanten Code für die Auslieferung der Datei zeigst Du gerade nicht, dabei war dieser der wesentliche Diskussionsgegenstand. Schade!

Dieser Code ist fast gleich zu dem, worauf Rolf unter "readfile" in seinem Posting verwiesen hat. Aber eben nur fast. Solche Sachen muss ich natürlich anpassen.

Ihr glaubt nicht, wie dankbar ich für Tips und Anregungen bin, die ich hier bekomme. Zumal ich weder Informatik studiert habe, noch dass mir jemand mal PHP oder CSS etc. beigebracht hat. Darum fehlt mir auch dieses Backgroundwissen, z.B. wie Crawler Bilder behandeln.

Die Vorgehensweise von Rolf mit <img src='get_image.php...' /> kannte ich nicht, weils mir nie jemand gezeigt hat. Aber mich mit der Nase drauf zu stossen, DAS ist für mich echte Hilfe! Was letztendlich in der Datei stehen soll, das krabbel ich mir schon zusammen. Oder der Tip von meltemi mit der .htaccess. Super!

Gut, statt if...elseif kann ich sicher auch ein Array bauen. Oder switch. ich versuche immer die Scripte möglichst schlank und übersichtlich zu halten. Wenn die Definition eines Arrays 2 Zeilen braucht und die dazugehörige foreach-Schleife nochmal 10, dann schreibe ich lieber 4 Zeilen if...elseif. Getreu dem Motto:

"Jeder programmiert auf seine Weise - der eine laut, der andere leise."

In diesem Sinne nochmals ein dickes Dankeschön an alle! Auch Dir, Felix!

Ich schaue weiterhin ab und an mal rein...

Gruss Treziman (Torsten)

[Der Martin]

Hallo,

danke für die Warnungen! Ich wusste, da kommt noch was...

na klar, wir lassen die Leute ja hier nicht sehenden Auges in den Abgrund rennen. 😉

Dieses Kauderwelsch wird zu einem Bild, wenn du dem Browser auch noch mitteilst, dass es eins ist. Sende dazu als erste Anweisung im Script den Content-Type-Header image/jpeg.

Soll ja eben nicht!

Ähm, doch.

Die Bilder werden vom Script korrekt angezeigt. Nur eben nicht im Quelltext. Das ist okay.

Sie werden korrekt angezeigt, wenn sie aus einem HTML-Dokument heraus über ein img-Element abgerufen werden. Dann hat der Browser einen Kontext und kann entscheiden, dass der von dir gelieferte Content-Type text/html, den PHP als Defaultwert setzt, hier falsch sein muss. Das ist aber nicht garantiert, das ist browserabhängig. Der Browser könnte auch entscheiden: Da passt etwas nicht zusammen, ich biete die Ressource einfach zum Speichern an. Er könnte auch entscheiden, anstelle des fehlerhaften Bildes einfach das Icon für "broken image" anzuzeigen. Deswegen solltest du schon einen korrekten Content-Type senden.

session_start();

if(isset($_SESSION["user_xyz"])) { // User ist eingeloggt-darf auf Bilder zugreifen

$name=$_GET["bild"];

if($name=="Suse"){
$datei="../bilder/klaus1.jpg";
}elseif($name=="winter"){
$datei="../bilder/sommer1.jpg;
}elseif(etc.){
usw.
}...{
...
}else{
$file="../forbidden.gif";
}

}else{// User ist nicht eingeloggt

$file="../forbidden.gif";

}
Hier folgt der Code von Rolfs Hinweis

Wenn also php (if...) keinen gültigen Wert findet, wird forbidden.gif angezeigt.

Das ist gut. So werden alle nicht vorgesehenen Namen einfach abgeschmettert. Okay.
Anstelle der ellenlangen if-Kette würde ich aber ein Array bauen:

$AllowedImages =
 [ "Suse":   "klaus1.jpg",
   "winter": "sommer1.jpg",
   "hase":   "igel.jpg"
 ];

Dann reicht ein Einzeiler als Abfrage:

$file = (isset(AllowedImages[$_GET['bild']]) ? AllowedImages[$_GET['bild']] : "forbidden.gif");

Einen schönen Tag noch
 Martin

[Der Martin]

Hallo nochmal,

ein Nachtrag:

$file = (isset(AllowedImages[$_GET['bild']]) ? AllowedImages[$_GET['bild']] : "forbidden.gif");

Auch wenn isset() funktionieren müsste, wäre array_key_exists() hier IMHO eleganter und passender.

Einen schönen Tag noch
 Martin

Einen schönen Tag noch
 Martin

[Rolf B]

Hallo Martin,

Da hier ein Defaultwert gesetzt wird, wäre der null coalescing Operator ?? noch viel passender.

Ich weiß allerdings nicht wie sich das bei geschachtelten Arrayzugriffen verhält. Es kann 'bild' im _GET Array Fehlern und $_GET['bild'] in den AllowedImages.

Wobei AllowedImages wohl viel lieber eine Datenbank als ein Array sein möchte, oder?

Rolf

[Treziman]

Hi Martin,

nein, im Seitenquelltext muss das Bild nicht erscheinen, klickt man da auf den Link. Im Programm, vom Script her, wird es aber korrekt angezeigt. Das genügt. Ich wüsste nicht zu welchem Zweck das Bild auch noch im Quelltext erscheinen sollte, ausser um es leichter zu kopieren, bzw. abzuspeichern. Ausserdem habe ich, aus Erschwernisgründen, den Rechtsklick mittels Jquery verhindert, geht man mit der Maus über ein Bild. Ist man nicht über einem Bild, funktioniert der Rechtsklick.

Ich weiss, jetzt gibts wieder Kritik, von wegen eingeschränkter Bedienbarkeit seitens der User, aber das bleibt!😎

Verhindern kann man Bilderklau nicht - aber erschweren.

Lieben Gruss Treziman

[Der Martin]

Hallo,

nein, im Seitenquelltext muss das Bild nicht erscheinen, klickt man da auf den Link. Im Programm, vom Script her, wird es aber korrekt angezeigt. Das genügt.

du hast nicht verstanden, was ich eigentlich meinte.

Ich wüsste nicht zu welchem Zweck das Bild auch noch im Quelltext erscheinen sollte

Nochmal: Ich will dich nicht überreden, den Bildpfad im Klartext rauszugeben. Aber wenn du das Bild mit deinem Script ausgibst, dann sollte das doch technisch einigermaßen korrekt sein und nicht nur "zufällig" aufgrund der Gutmütigkeit des einen oder anderen Browsers funktionieren.

Ausserdem habe ich, aus Erschwernisgründen, den Rechtsklick mittels Jquery verhindert, geht man mit der Maus über ein Bild. Ist man nicht über einem Bild, funktioniert der Rechtsklick.

Zwecklos. Tools/Page Info (Shortcut Ctrl-I), Klick auf Media. Dann habe ich eine Liste aller Multimedia-Elemente auf der Seite und kann sie nach Belieben einzeln anschauen oder speichern.

Ich weiss, jetzt gibts wieder Kritik, von wegen eingeschränkter Bedienbarkeit seitens der User, aber das bleibt!😎

Obwohl wirkungslos?

Verhindern kann man Bilderklau nicht - aber erschweren.

Kaum.

Einen schönen Tag noch
 Martin

[Treziman]

Hi Martin,

Zwecklos. Tools/Page Info (Shortcut Ctrl-I), Klick auf Media. Dann habe ich eine Liste aller Multimedia-Elemente auf der Seite und kann sie nach Belieben einzeln anschauen oder speichern.

Absolut richtig. Man muss aber bedenken, dass nicht jeder solche Tastenkombinationen kennt. Deshalb hab ich auch "erschweren" geschrieben, nicht "verhindern".

Es ist ein einfacher Weg, sich den Seitenquelltext anzuschauen, auf den Bilderlink zu klicken - es öffnet sich ein neues Browserfenster mit dem Bild - Rechtsklick → Grafik speichern unter. Man muss es einem Bilderdieb nicht soo einfach machen, oder?

Noch einfacher wärs mit einem Rechtsklick direkt auf dem Bild. Kennen wir doch alle.

Weiterhin eine gute Nacht😁

[MudGuard]

Hi,

Das müsste mit Meta-Tag ... noindex, nofollow zu machen sein?

mit robots.txt bzw. dem Meta-Tag noindex/nofollow machst Du den Crawlern Vorschläge.

Brave Crawler halten sich an diese Vorschläge.

Böse Crawler werden das nicht tun - die könnten im Gegenteil die robots.txt auslesen, um besonders interessante Verzeichnisse zu finden …

cu,
Andreas a/k/a MudGuard

[Der Martin]

Hallo Linuchs,

Der Ordner müsste blockiert sein, wenn kein Leserecht eingeräumt wird.

ja, müsste er. Aber je nachdem, wie das Ökosystem des Hosters eingerichtet ist, ist er dann auch für PHP nicht zugänglich. Nämlich wenn PHP als Apache-Modul läuft und damit unter demselben Benutzer wie der Apache selbst.

Du verrätst nicht, was mit den Bildern passieren soll.

Nicht explizit, stimmt. Aber aus dem Startposting lese ich, dass die Bilder per Script (vermutlich PHP) wieder gelesen und weiter verarbeitet werden sollen.

Fürs Hochladen reicht das Schreibrecht.

Ja. Fürs spätere Lesen nicht. Deshalb ist ein Verzeichnis außerhalb des Web Root oder eine Zugangsbeschränkung mit HTTP-Auth der bessere Weg.

Einen schönen Tag noch
 Martin

[Treziman]

Nicht explizit, stimmt. Aber aus dem Startposting lese ich, dass die Bilder per Script (vermutlich PHP) wieder gelesen und weiter verarbeitet werden sollen.

Stimmt, läuft alles komplett unter php und Jquery.

A la: echo"<img src='/bilder/bildpfad/foto1.jpg' />";

[Der Martin]

Hi,

echo "<img src='/bilder/bildpfad/foto1.jpg' />";

na prima, dann legst du die Direkt-Zugriffslinks ja doch komplett offen und musst den direkten Zugriff auf die Bilder zulassen. Denn sonst würde das ja nicht funktionieren.

Einen schönen Tag noch
 Martin

[Rolf B]

Hallo Martin,

ja, wenn das PHP Script die Ordnernamen "verpetzt", hat das Ganze keinen Sinn. Es sei denn, die Ordnernamen werden nur den angemeldeten und berechtigten Usern gezeigt, dann ist der Crawler ebenfalls ausgesperrt.

Sicher ist das aber nicht; besser ist es, wenn das PHP Script die Zugriffsrechte prüft und den Inhalt der Bilddateien kopiert. Dafür gibt's readfile, im PHP Handbuch ist ein Beispiel gezeigt, wie man das für einen allgemeinen Binärstream macht. Für Bilder müsste man an Hand der Dateiendung einen passenden Content-Type setzen. Rolf

[Raketenwilli]

Für Bilder müsste man an Hand der Dateiendung einen passenden Content-Type setzen.

Nicht wirklich.

mime_content_type(resource|string $filename):

• Was „mime magic“ wie macht findet man mit man 5 magic heraus.
• Allerdings dauert es länger etwas aus einer Datei zu ermitteln, was man schon aus anderen Gründen weiß.

[Raketenwilli]

Um in einem Ordner auf einem unixoiden System (Unix, Linux, BSD, Android, MacOS) eine Datei anlegen zu können braucht der Benutzer neben dem Recht, das Verzeichnis zu betreten und darin zu schreiben auch Leserechte:

~/tmp$ mkdir test
~/tmp$ chmod a-rwx test
~/tmp$ chmod o=wx test
~/tmp$ ls -ld  test
d-------wX 2 seminar seminar 4096 Jul 10 13:05 test
~/tmp$ touch test/file
touch: 'test/file' kann nicht berührt werden: Keine Berechtigung

Grund:

Bevor eine Datei angelegt wird, muss geprüft werden können, ob diese vorhanden ist. Schlägt diese Prüfung fehl, weil kein Leserecht gewährt wurde, wird das Anlegen der Datei abgebrochen.

Lösung:

• Was unter den gegebenen Umständen funktioniert hat Rolf gezeigt.

[TS]

Hello,

Wie kann ich am besten verhindern, dass Crawler auf den Ordner "bilder" zugreifen und die Fotos auslesen?

Der Ordner müsste blockiert sein, wenn kein Leserecht eingeräumt wird.

Du verrätst nicht, was mit den Bildern passieren soll. Fürs Hochladen reicht das Schreibrecht.

... und wenn PHP als Modul läuft, wirkt auch open_basedir Restriction.

Glück Auf
Tom vom Berg

[meltemi]

Hallo,

erstelle im Verzeichnis bilder eine Datei mit dem Namen .htaccess mit diesem Inhalt:

<FilesMatch "\.jpg$">
  Header set X-Robots-Tag "noindex"
</FilesMatch>

Dieses Indexierungsverbot gilt für Bilder mit der Endung jpg. Richte die Regel ggf. auch für andere Endungen ein.

[Treziman]

Hallo meltemi,

auch Dir ein herzliches Dankeschön für diesen klaren Tip! Vor allem der Hinweis "im Verzeichnis" ist mir sehr hilfreich, da mir unklar war, wohin die .htaccess eigentlich gehört. Ich kenne diese Datei zwar, aber die Handhabung ist mir bisweilen fremd, weil ich damit noch nicht gearbeitet habe. Umso mehr freue ich mich wenn mich jemand in die richtige Richtung schubst.

Nochmals vielen Dank und Gruss Treziman

[Felix Riesterer]

Lieber Treziman,

Vor allem der Hinweis "im Verzeichnis" ist mir sehr hilfreich, da mir unklar war, wohin die .htaccess eigentlich gehört.

das finde ich jetzt sehr befremdlich. @Matthias Scharwies hatte Dir bereits den Artikel Webserver/htaccess/Zugriffskontrolle verlinkt. Du solltest in solchen Fällen unbedingt verlinkte Quellen lesen und zu Herzen nehmen. Wenn man sich hier die Zeit nimmt, Dir etwas zu verlinken, dann sicherlich deswegen, weil man die Quelle für Dein Anliegen von hoher Bedeutung hält! Und im verlinkten Artikel steht:

Speichern Sie in dem Verzeichnis, das Sie schützen wollen, eine .htaccess-Datei.

Das hattest Du offensichtlich zwischen 12:30 Uhr und 23:05 Uhr nicht geschafft zu lesen und zu lernen.

Ich kenne diese Datei zwar, aber die Handhabung ist mir bisweilen fremd, weil ich damit noch nicht gearbeitet habe. Umso mehr freue ich mich wenn mich jemand in die richtige Richtung schubst.

Ja, Du freust Dich, wenn man Dir alles in einem Thread direkt postet und mundgerecht serviert. Dann bist Du hier aber im falschen Métier, denn Webschaffende müssen sich zwangsläufig aus Quellen im Internet informieren können, denn einen exklusiven privaten Support können und wollen wir hier nicht leisten! Tu Du auch was und lerne wenigstens Quellen zu nutzen!

Liebe Grüße

Felix Riesterer

[Treziman]

Ja, Du freust Dich, wenn man Dir alles in einem Thread direkt postet und mundgerecht serviert.

Das ist so nicht richtig, lieber Felix! Wer lesen kann ist klar im Vorteil. Rolf hat mir den Tip mit der get_image.php gegeben. Doch WAS in dieser Datei stehen muss, hat Rolf einerseits verlinkt, andererseits habe ich den für meine Bedürfnisse fehlenden Code dort selbst erstellt! Damit das klar ist. Mir soll keiner die Arbeit abnehmen aber Hilfestellung in Form von Denkanstössen kann man erwarten, oder? Wenn hier immer nur geschrieben wird: "lies mal da ... lies mal dort...", dafür brauchen wir dieses Forum nicht. Das kann man auch über Google finden, wovon ich oft genug Gebrauch mache.

Ich hoffe, ich konnte das klären.

Alsdann, Treziman

[Auge]

Hallo

Ja, Du freust Dich, wenn man Dir alles in einem Thread direkt postet und mundgerecht serviert.

Das ist so nicht richtig, lieber Felix! Wer lesen kann ist klar im Vorteil.

Ja, das möchte man unbedingt unterschreiben.

Rolf hat mir den Tip mit der get_image.php gegeben.

Rolf? Welcher Rolf? In Felix' Posting gab es weit und breit keinen Rolf. Er schrieb von Matthias Scharwies. Und jener wies dich explizit auf den nun auch von Felix (und gleich auch von mir) verlinkten Artikel über Zugriffskontrolle mit .htaccess hin, der unter anderem erklärt, wie eine solche Datei funktioniert und eben auch, wo sie hingehört.

Deine Nachfragen sagen nun aber, dass du den verlinkten Artikel bisher ganz offensichtlich tapfer ignoriert hat. Schade und unnötig.

Wenn hier immer nur geschrieben wird: "lies mal da ... lies mal dort...", dafür brauchen wir dieses Forum nicht.

Wir bieten hier auf Nachfrage kostenlose Hilfe zur Selbsthilfe an. Und ja, dazu gehört ganz gewiss auch das Selbststudium von verlinkten Ressourcen durch die Hilfesuchenden.

Tschö, Auge

[Treziman]

Wer lesen kann ist klar im Vorteil.

Ja, das möchte man unbedingt unterschreiben.

Rolf hat mir den Tip mit der get_image.php gegeben.

Rolf? Welcher Rolf? In Felix' Posting gab es weit und breit keinen Rolf.

Eben, Auge!

Dann lies mal den GANZEN Thread, nicht nur einen einzelnen Beitrag!

Tschö, Treziman

[Auge]

Hallo

Wer lesen kann ist klar im Vorteil.

Ja, das möchte man unbedingt unterschreiben.

Rolf hat mir den Tip mit der get_image.php gegeben.

Rolf? Welcher Rolf? In Felix' Posting gab es weit und breit keinen Rolf.

Eben, Auge!

Dann lies mal den GANZEN Thread, nicht nur einen einzelnen Beitrag!

Ich habe ihn gelesen.

Ganz unabhängig davon, wie sehr dir Rolf bei der Lösung deines Problems geholfen hat, bleibt die Tatsache, dass Matthias Scharwies dir recht früh ^[1] auf deine Frage nach dem Speicherort einer .htaccess zielführenden Lesestoff angeboten hat und dass du dieses Angebot leider ausgeschlagen hast. Dabei wird speziell diese Frage in dem von Matthias verlinkten Artikel an mehreren Stellen beantwortet.

Das ist, was Felix – meiner Meinung nach durchaus zu recht – bemängelt.

Tschö, Auge

---

1. 2022-07-09 12:30, nur 14 Minuten nach Fragestellung ↩︎

[Treziman]

Ist alles richtig! Ich habe mir den von Matthias verlinkten Artikel gerade zum 3. Mal angeschaut. Tatsache. Da steht: "Speichern Sie in dem Verzeichnis, das Sie schützen wollen, eine .htaccess-Datei." Das habe ich auch gelesen. Trotzdem war der zusätzliche Hinweis von meltemi hilfreich. Das wird wohl keiner abstreiten, oder?

Desweiteren finde ich in dem gesamten Artikel kein Beispiel in der Art, wie es meltemi gepostet hat. Ihr könnt nicht von jemandem verlangen der offen zugibt, dass er die Handhabung einer solchen Datei nicht kennt, dass er sich irgendeinen Code auf ein Geratewohl zusammenbaut.

Natürlich habe ich gegoogelt. Erfolglos, sonst hätte ich hier nicht gepostet. Wir alle haben mal angefangen. Keiner wurde mit der Kenntnis über PHP, javascript etc. geboren. Doch WIE haben wir angefangen? Wir waren doch froh wenn uns jemand GEZEIGT hat wie es geht, oder? Kein Lehrer oder Trainer wird seinen Schützlingen dadurch etwas lehren, wenn er sagt: "Lest mal das und das." Und falls doch, dann wird hinterher darüber gesprochen, wer hat was nicht verstanden. So finde ich das auch in Ordnung.

Nochmal der Hinweis: Ich kann mit dem Artikel nicht viel anfangen, weil der Inhalt komplett neu für mich ist.

Ihr dürft eins nicht vergessen! Für euch ist das hier alles täglicher Kram. Ihr seid Profis, ihr habts studiert, gelernt. Aber es gibt Leute, die können es eben (noch) nicht. Und diese Leute wenden sich hilfesuchend an dieses Forum, wofür es auch gedacht ist. Es ist absolut richtig, diesen Hilfesuchenden keine fertigen Sachen zu präsentieren, denn dadurch lernen sie nichts! Es ist aber genauso falsch, diese Leute mit Hinweisen zu bombardieren, wo sie vielleicht eine Lösung ihres Problems finden könnten, obwohl sie keine oder wenig Ahnung haben.

LG Treziman

[Treziman]

Kann mal bitte jemand gucken?

Hier meine .htaccess:

<FilesMatch ".(gif|jpe?g|png|bmp)$">

Header set X-Robots-Tag "noindex"

</FilesMatch>

Sperrt die jetzt alle Bilddateien, auch jpg , JPG , jpeg?

Danke!

P.S.

Wenn ich diese Datei im Basisverzeichnis ablege, werden laut Erklärungen via Google, alle Unterverzeichnisse einbezogen. Damit müssten dann ALLE Bilder betroffen sein?

[Auge]

Hallo

Kann mal bitte jemand gucken?

Hier meine .htaccess:

<FilesMatch ".(gif|jpe?g|png|bmp)$">

Header set X-Robots-Tag "noindex"

</FilesMatch>

Sperrt die jetzt alle Bilddateien, auch jpg , JPG , jpeg?

Die Endungen jpg und jpeg werden mit jpe?g erschlagen. Um die Regel groß-und-kleinschreibungsunabhängig (case insensitive) zu machen, muss ihr ?i: vorangestellt werden (<FilesMatch "\.(?i:gif|jpe?g|png|bmp)$">).

Wenn ich diese Datei im Basisverzeichnis ablege, werden laut Erklärungen via Google, alle Unterverzeichnisse einbezogen. Damit müssten dann ALLE Bilder betroffen sein?

Alle Bilder, die innerhalb des Verzeichnisbaums, der am Speicherot der .htaccess beginnt, gespeichert sind, werden von den Regeln in dieser .htaccess erfasst. Heutzutage sollte noch WebP in den Reigen der im Web üblichen Grafikformate aufgenommen werden.

Tschö, Auge

[Der Martin]

Hallo,

Heutzutage sollte noch WebP in den Reigen der im Web üblichen Grafikformate aufgenommen werden.

ja, guter Einwand. Dafür ist das Windows-Bitmap-Format im Web eher unüblich.

Einen schönen Tag noch
 Martin

[Auge]

Hallo

Heutzutage sollte noch WebP in den Reigen der im Web üblichen Grafikformate aufgenommen werden.

ja, guter Einwand. Dafür ist das Windows-Bitmap-Format im Web eher unüblich.

Ich wollte zu BMP auch noch etwas schreiben, habe es dann aber gelassen. Auch wenn BMP von den mir bekannten Browsern nicht nativ angezeigt wird, habe ich doch schon einige Bildersammlungen auf Websites gesehen, die jede Menge BMP-Dateien enthalten haben. Wer in Windows, zumindest bis Windows XP, einen Screenshot im mitgelieferten Programm Paint gespeichert hat und beim vorgegebenen Standardformat geblieben ist, hat halt eine BMP herausbekommen.

Heute (mit Windows 10) ist in Paint glücklicherweise PNG das Standardformat. Die alten BMP-Bilder gehen davon im Web leider nicht weg, aber wenigstens kommt so kaum noch neues BMP-Material nach, wenn es denn nicht bewusst als BMP gespeichert wurde. 😀

Tschö, Auge

[Der Martin]

Moin,

Die alten BMP-Bilder gehen davon im Web leider nicht weg, aber wenigstens kommt so kaum noch neues BMP-Material nach, wenn es denn nicht bewusst als BMP gespeichert wurde. 😀

und dafür sollte es IMO keinen Anlass geben. Das BMP-Format ist proprietär, zwar verlustfrei, komprimiert aber schlecht bis gar nicht^[1] und wird, wie du schon sagst, von vielen Nicht-Windows-Browsern nicht angezeigt.

Also ist die bessere Wahl auf jeden Fall PNG, wenn es verlustfrei sein soll, oder JPEG, wenn ein bisschen Qualitätsverlust durch die Kompression akzeptabel ist. WebP würde ich nur einsetzen wollen, wenn ich mir ganz sicher bin, dass ich die Bilder nicht noch anderweitig verwenden oder weiterverarbeiten will.

Einen schönen Tag noch
 Martin

---

1. Bei 24bit Farbtiefe unterstützt das BMP-Format meines Wissens gar keine Kompression, bei 8bit (oder noch weniger) immerhin RLE. Trotzdem dürfte PNG dann immer noch die bessere Wahl sein - nicht nur ideologisch, auch technisch. ↩︎

[Auge]

Hallo

Hmmm, Selbstgespräch.

Sperrt die jetzt alle Bilddateien, auch jpg , JPG , jpeg?

Die Endungen jpg und jpeg werden mit jpe?g erschlagen. Um die Regel groß-und-kleinschreibungsunabhängig (case insensitive) zu machen, muss ihr ?i: vorangestellt werden (<FilesMatch "\.(?i:gif|jpe?g|png|bmp)$">).

Ich habe eben noch eine andere Syntax gefunden. Beide Synten ^[1] mal untereinander:

<FilesMatch "\.(?i:gif|jpe?g|png|bmp)$">
<FilesMatch "(?i)\.(gif|jpe?g|png|bmp)$">

Da ich selbst überaus selten mit regulären Ausdrücken arbeite, kann ich zum Unterschied zwischen den beiden Versionen nichts substantielles sagen. Ich hoffe mal, dass jemand anderes zu diesem Thema aussagefähiger ist.

Tschö, Auge

---

1. Ich weiß, dass das so nicht heißt. 😉 ↩︎

[Raketenwilli]

Ich habe eben noch eine andere Syntax gefunden. Beide Synten [^1] mal untereinander:

<FilesMatch "\.(?i:gif|jpe?g|png|bmp)$">
<FilesMatch "(?i)\.(gif|jpe?g|png|bmp)$">

Da ich selbst überaus selten mit regulären Ausdrücken arbeite, kann ich zum Unterschied zwischen den beiden Versionen nichts substantielles sagen. Ich hoffe mal, dass jemand anderes zu diesem Thema aussagefähiger ist.

Die zweite Zeile würde (anders als die erste) als erstes Zeichen auch einen „groß geschriebenen Punkt“ als „passend“ betrachten. Nach derzeitiger Definition gibt es den nicht. Da dieses „gibt es nicht“ aber tatsächlich ein „gibt es hoffentlich nicht“ ist(¹), würde ich die engere Schreibweise (erste Zeile) bevorzugen.

---

¹) Ich wette mein Sitzfleisch, dass der Apache für die regulären Ausdrücke eine Libaray benutzt. Und wenn die sich mal in dem Punkt ändern sollte weil deren Autoren ihre Meinung ändern könnte es sein, dass es hier zu „Unfällen“ kommt. Denn was immer als „groß geschriebener Punkt“ definiert werden mag: In Linux sind alle Zeichen außer dem NUL-Byte in Dateinamen erlaubt.

[Treziman]

Vielen Dank Auge, Martin und Raketenwilli, dass ihr da mal drübergeschaut habt!

Ich habe die erste Zeile mal so in meine .htaccess geschrieben. WebP brauche ich wohl nicht, da ich dieses Format in meinem Projekt nicht habe. Das muss, soviel ich weiss, nach dem Runterladen auch immer erst konvertiert werden, will man es weiterverarbeiten (Photoshop).

LG Treziman

[Der Martin]

Hallo,

[WebP] Das muss, soviel ich weiss, nach dem Runterladen auch immer erst konvertiert werden, will man es weiterverarbeiten (Photoshop).

ja, es gibt von Browsern abgesehen nur sehr wenige Programme, die das anzeigen oder verarbeiten können.

Einen schönen Tag noch
 Martin

[Auge]

Hallo

[WebP] Das muss, soviel ich weiss, nach dem Runterladen auch immer erst konvertiert werden, will man es weiterverarbeiten (Photoshop).

ja, es gibt von Browsern abgesehen nur sehr wenige Programme, die das anzeigen oder verarbeiten können.

Noch. Gimp in einer aktuellen Version (2.10.x) kann es und zukünftige Grafibearbeitungsprogramme werden das wohl in zunehmendem Umfang auch können.

In Sachen Fotos (24 Bit Farbtiefe) stellt das Format jedenfalls sowohl PNG als auch JPEG in einen tiefen Schatten. PNG bei der resultierenden Dateigröße und JPEG sowohl bei der Qualität (verlustbehaftete versus verlustlose Komprimierung) als auch bei der Dateigröße.

Tschö, Auge

[Raketenwilli]

Hallo

[WebP] Das muss, soviel ich weiss, nach dem Runterladen auch immer erst konvertiert werden, will man es weiterverarbeiten (Photoshop).

• Nein. Es gibt (mindestens:) ein Plugin für Photoshop. Damit geht Öffnen, Speichern & Co. „ganz normal“
• Heute ist das ein installierbares Plugin und morgen wird es (oder ein Derivat von Adobe) gleich mitgeliefert und ist beim Setup vielleicht nicht einmal abwählbar.

ja, es gibt von Browsern abgesehen nur sehr wenige Programme, die das anzeigen oder verarbeiten können.

Noch. Gimp in einer aktuellen Version (2.10.x) kann es und zukünftige Grafibearbeitungsprogramme werden das wohl in zunehmendem Umfang auch können.

Ja. Die Programmierer können die Libs einfach einbinden.

Mit Blick auf die also schon stattfindende Zukunft würde ich es anno 2022 gleich mit aufnehmen. Sonst muss man in ein paar Monaten nochmal in den Quelltext gehen und die Stelle(n) suchen…

[Gunnar Bittersmann]

@@Auge

In Sachen Fotos (24 Bit Farbtiefe) stellt das Format [WebP] jedenfalls sowohl PNG als auch JPEG in einen tiefen Schatten.

Und wird von AVIF in einen tiefen Schatten gestellt. AVIF has landed.

🖖 Живіть довго і процвітайте

[Raketenwilli]

In Sachen Fotos (24 Bit Farbtiefe) stellt das Format [WebP] jedenfalls sowohl PNG als auch JPEG in einen tiefen Schatten.

Und wird von AVIF in einen tiefen Schatten gestellt. AVIF has landed.

Fürwahr!

Ich habe mal 3 auf ähnliche Dateigrößen komprimierte Versionen herausgesucht...

• JPEG https://jakearchibald.com/c/f1-match-ff75e344.jpg ~ 20kB
• WepP https://jakearchibald.com/c/f1-match-7a06c7c4.webp ~ 22kB
• Avif https://jakearchibald.com/c/f1-good-a14c8cc5.avif ~ 18kB

(Für den Vergleich: brauchbarer Monitor, jeweils in neuem Tab öffnen, zwischen den Tabs umschalten...)

Auf einem Gerät mit einem modernen OS kann man sich einen Umwandler mit etwas wie

sudo apt update && sudo apt upgrade && sudo apt install libavif-bin

installieren. Neu sind dann die Befehle

• avifdec
• avifenc

Für Gimp gibt es ein Plugin.

[Auge]

Hallo

In Sachen Fotos (24 Bit Farbtiefe) stellt das Format [WebP] jedenfalls sowohl PNG als auch JPEG in einen tiefen Schatten.

Und wird von AVIF in einen tiefen Schatten gestellt. AVIF has landed.

Njärch, womit wir um drei Ecken wieder bei der Diskussion über Snap-, Flatpak- oder sonstige Repo-fremde Programmpakete unter Linux wären.

Gimp unterstützt AVIF ab Version 2.10.22 aus dem Oktober 2020. Ubuntu 20.04, die nunmehr seit wenigen Monaten nicht mehr neueste LTS-Version dieser Distro, bietet Gimp über die standardmäßig aktivierten Repositories in der Version 2.10.18 vom Februar 2020 an ^[1]. Für die Arbeit mit AVIF ist diese Version aber nicht zu gebrauchen.

Wenn ich ein auch nur einigermaßen aktuelle Version haben will order gar brauche und das Programm nicht aus den Quellen selbst kompilieren kann oder will, bin ich unter Linux schlicht und einfach darauf angewiesen, Fremdquellen zu benutzen. Auf FlatHub wird Gimp in Version 2.10.32 angeboten ^[2], als Snap gibt es zumindest die Version 2.10.28 ^[3].

Man kann die reine Lehre vertreten, dass solche Fremdpakete auf einem Linux-System nichts zu suchen haben. Mit einigermaßen aktueller Software zu arbeiten, obwohl man nicht in die Tiefen des Systems hinabsteigen will (oder es sich nicht zutraut), muss man sich dann aber abschminken.

Tschö, Auge

---

1. Dass nicht distro-eigene Pakete, die bei einem Distro-Release bereitgestellt werden, in vielen Fällen, wenn überhaupt, bestenfalls Sicherheitsfixes bekommen, ist bekannt. Dass ein doch recht bekanntes Paket wie Gimp nach dem Distro-Release von Canonical überhaupt kein Update bekommt, ist mMn echt mau. ↩︎

2. Das ist übrigens auch die Quelle, die auf gimp.org in der Download-Sektion für Linux-basierte OS angeboten wird. ↩︎

3. In beiden Fällen vor wenigen Minuten ermittelt (2022-07-12 11:34). ↩︎

[Raketenwilli]

Dass nicht distro-eigene Pakete, die bei einem Distro-Release bereitgestellt werden, in vielen Fällen, wenn überhaupt, bestenfalls Sicherheitsfixes bekommen, ist bekannt.

Stell Dir mal vor, was in einer Verwaltung los ist, wenn in $PROGRAMM auch nur ein einziger Menüpunkt anders ist als in der mit dem Rollout ausgelieferten Unterlage. (In diese wird nur geschaut um solche „Mängel“ festzustellen und als BEWEIS dafür vorzutragen, dass das eigene Versagen - gern an ganz anderer Stelle - gar kein eigenes sein kann.) Echte Bürokraten (auch in Unternehmen zahlreich) gehen wegen SOWAS auf die Barrikade wie derzeit die Leute in Sri Lanka… Man erinnere sich an München.

Ubuntu 20.04, die nunmehr seit wenigen Monaten nicht mehr neueste LTS-Version dieser Distro, bietet Gimp über die standardmäßig aktivierten Repositories in der Version 2.10.18 vom Februar 2020 an

Ja. Bloß keine Funktionsupdates!

Es gibt noch einen Grund: Gimp hat ja allerhand Abhängigkeiten. Da kann es sein, dass am „Unterbau“ zu viel geändert werden muss. Also macht man da keine Experimente.

Da wir dabei sind: Das „rollende Update“ von Ubuntu 20.04 auf 22.04 (durch Ändern der URLs in den Repos) hab ich hinbekommen - Unbedarftere werden das „eher nicht völlig unfallfrei“ schaffen. (Ich hab z.B. das „Anmeldedingens“ (a.k.a. „Desktopmanager“) von lightdm auf gdm umgestellt, sonst wollte mein XFCE (wegen Wayland, Mutter und den Grafiktreibern von NVIDIA) nicht starten.

Dass ein doch recht bekanntes Paket wie Gimp nach dem Distro-Release von Canonical überhaupt kein Update bekommt, ist mMn echt mau.

Ob das so stimmt?

• http://changelogs.ubuntu.com/changelogs/pool/universe/g/gimp/gimp_2.10.18-1/changelog

[Auge]

Hallo

Es gibt noch einen Grund: Gimp hat ja allerhand Abhängigkeiten. Da kann es sein, dass am „Unterbau“ zu viel geändert werden muss. Also macht man da keine Experimente.

Ja, das ist wohl der Grund, wie ich mittlerweile feststellen musste. Mehr dazu unten.

Da wir dabei sind: Das „rollende Update“ von Ubuntu 20.04 auf 22.04 (durch Ändern der URLs in den Repos) hab ich hinbekommen

Meinst du ein direktes Upgrade von Ubuntu 20.04.x auf Ubuntu 22.04.x oder eines über die Zwischenschritte 20.10, 21.04 und 21.10?

Dass ein doch recht bekanntes Paket wie Gimp nach dem Distro-Release von Canonical überhaupt kein Update bekommt, ist mMn echt mau.

Ob das so stimmt?

• http://changelogs.ubuntu.com/changelogs/pool/universe/g/gimp/gimp_2.10.18-1/changelog

Wie dein Link zeigt, ja. Die letzte Aktualisierung erfolgte am 29.03.2020 auf die Version 2.10.18.1. Das war vor dem Release von Ubuntu 20.04. Danach passierte da im Repo für Ubuntu 20.04 nichts mehr.

Ich habe jedenfalls versucht, Gimp aus den Quellen zu kompilieren. Wie du oben schon schriebst, gibt es einige Abhängigkeiten. Normalerweise kompiliere ich nur konkret ein Spiel in der jeweils neuesten Entwicklungsversion. Ich weiß also grundsätzlich, wie so etwas funktioniert. Bei dem Spiel dauert der Durchlauf von ./configure beziehungsweise neuerdings cmake .. zur Vorbereitung auf make etwa zwei bis drei Sekunden. Bei Gimp läuft und läuft und läuft ./configure … bei mir weit über 10 Sekunden lang. Da wird erheblich mehr „herumkonfiguriert“.

Ergebnis des Ganzen: diverse nicht aktuelle Bibliotheken (das OS ist frisch aktualisiert), diverse Bibliotheken, die zwar installiert sind, von ./configure aber nicht gefunden werden, optionale Abhängigkeiten, die nicht installiert sind und deren Fehlen als das Kompilieren unmöglich machende Fehler angekreidet werden. Nicht, dass man die nicht auch als nicht automatisch einzukompilieren markieren könnte. Nein, ich müsste da wohl per Aufrufparameter händisch nachhelfen.

Vor dem Start von ./configure bin ich, nachdem ich die Liste der geforderten Bibliotheken mit den auf meinem Rechner installierten Versionen verglichen habe, davon ausgegangen, dass mein System die Anforderungen erfüllt. Aber die Fehlerliste von ./configure zeigt mir, dass die Dokumentation von Gimp nicht auf dem aktuellen Stand ist. Vieles, was auf meinem System laut der Doku noch gereicht hätte, zeigt mir die Ausgabe von ./configure als unzureichend an. Ich brauche also mit dem nächsten Schritt (make) erst gar nicht zu beginnen.

Selbst Canonical könnte mit den für Ubuntu 20.04 zur Verfügung gestellten Quellen kein Paket von Gimp in einer aktuellen Version zur Verfügung stellen. Ob das schon für Gimp 2.10.20 oder 2.10.22 gegolten hat oder ob die verfügbaren Bibliotheken dafür noch ausgereicht hätten, wer weiß. Ist ja auch Wurscht.

Ich gehe jedenfalls davon aus, dass soetwas wohl die meisten Benutzer davon abhalten dürfte, sich eine aktuelle Gimp-Version selbst zu kompilieren. Ich gehöre jedenfalls in diese Gruppe und bediene mich jetzt mit dem Flatpak-Paket bei den oft geschmähten Fremdquellen. 🤷‍♂️

Tschö, Auge

[Raketenwilli]

Da wir dabei sind: Das „rollende Update“ von Ubuntu 20.04 auf 22.04 (durch Ändern der URLs in den Repos) hab ich hinbekommen

Meinst du ein direktes Upgrade von Ubuntu 20.04.x auf Ubuntu 22.04.x oder eines über die Zwischenschritte 20.10, 21.04 und 21.10?

direkt.

[Auge]

Hallo

Da wir dabei sind: Das „rollende Update“ von Ubuntu 20.04 auf 22.04 (durch Ändern der URLs in den Repos) hab ich hinbekommen

Meinst du ein direktes Upgrade von Ubuntu 20.04.x auf Ubuntu 22.04.x oder eines über die Zwischenschritte 20.10, 21.04 und 21.10?

direkt.

Will man das jetzt (knapp drei Monate nach Release) schon?

Tschö, Auge

[Raketenwilli]

Moinsen!

Da wir dabei sind: Das „rollende Update“ von Ubuntu 20.04 auf 22.04 (durch Ändern der URLs in den Repos) hab ich hinbekommen

Meinst du ein direktes Upgrade von Ubuntu 20.04.x auf Ubuntu 22.04.x oder eines über die Zwischenschritte 20.10, 21.04 und 21.10?

direkt.

Will man das jetzt (knapp drei Monate nach Release) schon?

Das muss jeder für sich entscheiden. Von mir wird aber regelmäßig erwartet, dass ich Lappies mit den neuesten LTS-Versionen zum Seminar mitbringe und mich damit (bzw. den jeweiligen Versionen der Server wie bind, dhcpd, samba, apache, mariadb/mysql, exim, postfix, dovecut, ...) schon auskenne. Ältere oder andere Versionen als xUbuntu kann ich bequem als VM anbieten.

Außerdem hab ich dd, gzip, root-Rechte, etliche Ubuntu-Sticks und genug Platz für ein Image der gesamten Linux-(übrigens auch der Windows-) Platte (Datenbackup nochmal extra), weiß auch wie ich es hinbekomme, mir die (seltenen) Fehler- oder Erfolgsmeldungen nach dem Aufwachen am Smartphone anzuschauen und den Rechner nach dem Backup automatisch herunterzufahren.

Wenn bei einem solchen Versionsupgrade also was schief läuft, dann hab ich die Wahl zwischen Reparieren (mein Linux verarscht jedenfalls mich nicht), Zurücksetzen oder einem frischen Setup mit der neuen Version (und „Einspielen“ der Daten.) Der einzig riskierte Verlust ist also Zeit. Aus den oben und zuvor genannten Gründen ist das für mich also ein „notwendiges und vertretbares Risiko“.

Fazit: Ich wollte. Ich hatte sogar den Release-Kandidat. Den aber nur virtuell.

[Gunnar Bittersmann]

@@Gunnar Bittersmann

In Sachen Fotos (24 Bit Farbtiefe) stellt das Format [WebP] jedenfalls sowohl PNG als auch JPEG in einen tiefen Schatten.

Und wird von AVIF in einen tiefen Schatten gestellt. AVIF has landed.

Demnächst auch in Ihrem Safari.

🖖 Живіть довго і процвітайте

[Auge]

Hallo

Ich habe eben noch eine andere Syntax gefunden. Beide Synten [^1] mal untereinander:

<FilesMatch "\.(?i:gif|jpe?g|png|bmp)$">
<FilesMatch "(?i)\.(gif|jpe?g|png|bmp)$">

Da ich selbst überaus selten mit regulären Ausdrücken arbeite, kann ich zum Unterschied zwischen den beiden Versionen nichts substantielles sagen. Ich hoffe mal, dass jemand anderes zu diesem Thema aussagefähiger ist.

Die zweite Zeile würde (anders als die erste) als erstes Zeichen auch einen „groß geschriebenen Punkt“ als „passend“ betrachten. Nach derzeitiger Definition gibt es den nicht. Da dieses „gibt es nicht“ aber ein „gibt es hoffentlich nicht“ ist(¹), würde ich die engere Schreibweise (erste Zeile) bevorzugen.

Danke für die Klarstellung. Wieder etwas gelernt, was ich im Fall der Nichtbenutzung irgendwann wohl wieder vergessen werde. Vielleicht kann ich es ja in der Zwischenzeit anwenden und dann bestenfalls verstetigen. 😀

Tschö, Auge

[Raketenwilli]

Fürs Nachvollziehen: Das mit dem Klammern funktioniert in regulären Ausdrücken wirklich genau so streng und einfach wie in der Schulmathematik. Lediglich die in Klammern voranstellbare Option (?i) ist anders.

Diese Schreibweise ist vorliegend aber auch „speziell“ und wird dann verwendet wenn das Pattern nicht in Begrenzer eingeschlossen wird, entspricht also

/\.(gif|jpe?g|png|bmp)/i

So z.B. auch bei grep (Das nehme ich gern zum Testen/Üben/Zeigen):

~> echo -e "foo.Bmp\nbar.bin"
foo.Bmp
bar.bin
~> echo -e "foo.Bmp\nbar.bin" | grep -P "(?i)\.(gif|jpe?g|png|bmp)$"
foo.Bmp

[TS]

Hello,

mit welcher Scriptsprache wird denn zugegriffen?

Wenn es PHP ist:
Ist PHP als Modul oder als Fast-CGI eingerichtet auf dem Server?

Ich entnehme deinen Ausführungen, dass Du ein Schwesterverzeichnis zu DocumentRoot anlegen konntest?

Wie lautet die Fehlermeldung, wenn Du versuchst auf die Bilder im Schwesterverzeichnis von DocumentRoot zuzugreifen?

PHP hat eine Einstellung: open_basedir restriction, die regelt bei der Modulversion, wer zugreifen darf.

Glück Auf
Tom vom Berg