Bilder auf der Platte, oder in die Datenbank laden?

[Schröder]

Hallo Leute,

noch eine kleine Fragen, was ist besser die Bilder auf der Platte speichern, oder
in meine Datenbank laden. Was ist den schneller?

Danke!!!!

mfg

Schröder

[André Laugks]

Hallo!

noch eine kleine Fragen, was ist besser die Bilder auf der Platte speichern, oder
in meine Datenbank laden. Was ist den schneller?

Ist ja keine direkte Perl-Frage.
http://www.php-faq.de/q-db-blob.html

MfG, André Laugks

[Thomas Schmieder]

Auch hallo Leute,

noch eine kleine Fragen, was ist besser die Bilder auf der Platte speichern, oder
in meine Datenbank laden. Was ist den schneller?

was schneller ist, geht wohl eindeutig aus den Artikeln hervor. Die Bilder also direkt in ein Verzeichnis packen.

Was aber nun, wenn die Bilder nur nach Authentifizierung getted werden dürfen? Wie kan man das denn anstellen?

Alle Bilder, die über die "normalen" <img src=  Befehle in Websites eingebunden sind, sind doch dann auch direkt ansprechbar - oder?

LG
Tom

[Michael Schröpl]

Hi,

Was aber nun, wenn die Bilder nur nach Authentifizierung

was genau verstehst Du darunter?

getted werden dürfen? Wie kan man das denn anstellen?

Wieso sollte es (im Falle von HTTP-Authentifizierung) einen Unterschied zwischen Bildern und HTML-Seiten geben?

Alle Bilder, die über die "normalen" <img src=
Befehle in Websites eingebunden sind, sind doch
dann auch direkt ansprechbar - oder?

Wie wäre es mit einer Beschreibung Deines Problems?

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Thomas Schmieder]

Hi,

Was aber nun, wenn die Bilder nur nach Authentifizierung

was genau verstehst Du darunter?

getted werden dürfen? Wie kan man das denn anstellen?

Wieso sollte es (im Falle von HTTP-Authentifizierung) einen Unterschied zwischen Bildern und HTML-Seiten geben?

Alle Bilder, die über die "normalen" <img src=
Befehle in Websites eingebunden sind, sind doch
dann auch direkt ansprechbar - oder?

Wie wäre es mit einer Beschreibung Deines Problems?

Guten Morgen Michael,

in der Datenbank sind die Bilder vor unberechtigten Zugriffen sicher. Niemand kommt ohne den dazugehörigen Requester an die Bilder heran. Der Request kann eine in PHP eingebette komplexe Abfrage beinhalten und so dafür sorgen, dass die Bilder z.B. nur in der vorgesehenen Reihenfolge gezeigt werden.

Lege ich die Bilder in ein separates Verzeichnis der Domain, kann jeder, der dieses Verzeichnis kennt, darin nach Bildern suchen. Der einzige Schutz ist, dass er den Namen der Bilder nicht kennt. Aber dafür gibts ja auch "Würfelprogramme". Durch eine index.html oder eine andere Serverdirektive kann man ja zumindest schon mal das Ausgeben eines Directorys verhindern.

Wie kann man jetzt für die einfache Variante (ohne Datenbank) auch etwas mehr Schutz erzeugen? Mir schwebte da vor, dass der Name in der Datenbank steht und die Bilder nur über ein Interface vom Server geholt werden können, dass den Zugriff kontrolliert.

Ich hoffe, ich hae es jrzt etwas klarer ausgedrückt.

LG
Tom

[Michael Schröpl]

Hi Tom,

in der Datenbank sind die Bilder vor unberechtigten Zugriffen
sicher.

In einem Verzeichnis der Festplatte, das einer bestimmten Benutzer-
kennung gehört und bei dem die Zugriffs-Bits korrekt gesetzt sind,
gilt dasselbe.
Es gibt seit Jahrzehnten Betriebssysteme, die das können.

Lege ich die Bilder in ein separates Verzeichnis der Domain, kann
jeder, der dieses Verzeichnis kennt, darin nach Bildern suchen.

Keineswegs (siehe oben).

Der einzige Schutz ist, dass er den Namen der Bilder nicht kennt.

Nope.

Wie kann man jetzt für die einfache Variante (ohne Datenbank) auch
etwas mehr Schutz erzeugen?

Indem man seinen Server so konfiguriert, wie es die Ausgabenstellung
erfordert. Dazu gehört sowohl ein Konzept für das Betriebssystem
(Benutzerkennungen, Gruppen etc.) als auch eines für den HTTP-Raum
(z. B. http://aktuell.de.selfhtml.org/artikel/server/htaccess/).

Mir schwebte da vor, dass der Name in der Datenbank steht

Das ist alles überflüssig langsam.
Bilder sind in der Datenbank kaum jemals sinnvoll aufgehoben.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Thomas Schmieder]

Guten Morgen Michael,

wenn es überhaupt noch irgend jemand anders interessiert, könnte dieser Thread doch etwas länger werden. Ich bin mämlich mit Deiner Antwort nicht zufrieden.

in der Datenbank sind die Bilder vor unberechtigten Zugriffen
sicher.

In einem Verzeichnis der Festplatte, das einer bestimmten Benutzer-
kennung gehört und bei dem die Zugriffs-Bits korrekt gesetzt sind,
gilt dasselbe.
Es gibt seit Jahrzehnten Betriebssysteme, die das können.

Der Benutzer identifiziert sich nicht unbedingt als Individuum. In Clienting-Systemen wird aufgrund des bisherigen Referenzweges (was hat sich der besucher bisher angesehen?) für bestimmte Angebote eine spezielle Sicht erzeugt. Auch der technisch versierte Besucher soll nun nicht in der lage sein, sich die Bilder uber HTTP-Gets direkt von der Platte zu holen. Einen andeen Zugang, als übe die http-Schnittstelle hat er (hoffentlich) sowieso nicht.

Lege ich die Bilder in ein separates Verzeichnis der Domain, kann
jeder, der dieses Verzeichnis kennt, darin nach Bildern suchen.

Keineswegs (siehe oben).

Doch! Wenn ich einer HTML-Seite den Tag <img src="...  > einbaue, muss der wwwrun (oder wie der http-deamon auch immer heißt) Zugriff auf das Verzeichnis UND die Datei haben. Sonst gibts einen Broken Link.

Der einzige Schutz ist, dass er den Namen der Bilder nicht kennt.

Nope.

Dann sag mir bitte, wie ich dem wwwrun mitteilen kann, dass der Eine zugreifen darf und der Andere nicht.

Wie kann man jetzt für die einfache Variante (ohne Datenbank) auch
etwas mehr Schutz erzeugen?

Indem man seinen Server so konfiguriert, wie es die Ausgabenstellung
erfordert. Dazu gehört sowohl ein Konzept für das Betriebssystem
(Benutzerkennungen, Gruppen etc.) als auch eines für den HTTP-Raum
(z. B. http://aktuell.de.selfhtml.org/artikel/server/htaccess/).

.htaccess führt zu einem 401^-Verfahren. Der browser wird also sein berühmtes Fenster aufklappen und nach Namen und Passwort fragen. Das ist aber gar nicht bekannt. Es ist bestenfalls ein Cookie vorhanden. Also muss ich den Zugriff auf die Bilder über ein aktives Servermanagement (z.B. PHP) steuern. Es nützt mir nichts, wenn jetzt vielleicht die Einschränkung kommt "Cookies würde ich sowieso nicht machen".

Die Dinger sind für Revisits gemacht und ich sehe heute auch keinerlei technische Bedenken gegen Ihre Verwendung.

Mir schwebte da vor, dass der Name in der Datenbank steht

Das ist alles überflüssig langsam.
Bilder sind in der Datenbank kaum jemals sinnvoll aufgehoben.

Habe ich auch nicht gesagt, dass sie Bilder in die Datenbank sollen. Sondern die Referenz auf das Bild. Alle damit verbundenen Handling- und Integritätsprobleme haben wir ja schon angesprochen. Müßte man also Trigger setzen.

<img src="http://bitworks.de/~images/Absturz2.gif" border=0 alt="">

Liebe Grüße aus Braunschweig

Tom

PS: Das Thema ist mir zu wichtig (auch im Sinne von Schröder, Thread-Opener).

[Michael Schröpl]

Hi Thomas,

Der Benutzer identifiziert sich nicht unbedingt
als Individuum. In Clienting-Systemen wird aufgrund
des bisherigen Referenzweges (was hat sich der
besucher bisher angesehen?) für bestimmte Angebote
eine spezielle Sicht erzeugt.

damit hast Du eine Session definiert und kannst diese
"Identität" für eine Zugriffskontrolle auswerten.

Doch! Wenn ich einer HTML-Seite den Tag <img
src="...  > einbaue, muss der wwwrun (oder wie
der http-deamon auch immer heißt) Zugriff auf das
Verzeichnis UND die Datei haben. Sonst gibts einen
Broken Link.

Ja - der Webserver schon.
(Und der kann ja unter "root" laufen, falls Deine Daten
so kostbar sind, aber trotzdem andere Benutzer sich auf
diesem Server einloggen müssen.)

Das heißt noch lange nicht, daß es jeder Benutzer darf.

Dann sag mir bitte, wie ich dem wwwrun mitteilen
kann, dass der Eine zugreifen darf und der Andere
nicht.

Entweder über Server Authentication oder (falls kein
explizites Login gewünscht ist) dadurch, daß der Zu-
griff über ein CGI-Skript läuft und nicht über einen
URL. (Dann müssen die Dateien nicht mal innerhalb des
URL-Raumes liegen.)

Es ist bestenfalls ein Cookie vorhanden. Also muss
ich den Zugriff auf die Bilder über ein aktives
Servermanagement (z.B. PHP) steuern.

Ja, so würde ich das lösen.

Habe ich auch nicht gesagt, dass sie Bilder in die
Datenbank sollen. Sondern die Referenz auf das Bild.

Und wo liegt das Bild selbst, und wie spricht der
Browser es an?
Wenn Du in der Datenbank den URL speicherst, dann
verlierst Du wieder die Zugriffskontrolle.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Thomas Schmieder]

Hi Thomas,

damit hast Du eine Session definiert und kannst diese
"Identität" für eine Zugriffskontrolle auswerten.

Doch! Wenn ich einer HTML-Seite den Tag <img
src="...  > einbaue, muss der wwwrun (oder wie
der http-deamon auch immer heißt) Zugriff auf das
Verzeichnis UND die Datei haben. Sonst gibts einen
Broken Link.

Ja - der Webserver schon.

Genau darum gings ja im ursprünglichen Beitrag. Bilder in die Datenbank oder "lose" auf die Platte. Der Webserver hat vollen Zugriff und stellt dem Benutzer diesen über http: zur Verfügung. Das heißt, alle Bilder sind erreichbar, wenn man nur ihren Namen errät. Dafür gibts ja "Würfelprogramme". Außerdem sind Bilder i.d.R. logisch bezeichnet oder durchgezählt.

(Und der kann ja unter "root" laufen, falls Deine Daten
so kostbar sind, aber trotzdem andere Benutzer sich auf
diesem Server einloggen müssen.)

Um Himmels Willen. Wer läßt denn seinen Webserver unter root laufen. Der hat schön einen eigenen Username und eine eigene Gruppe und deren Rechte sollten auch akriebisch genau eingestellt werden.

Das heißt noch lange nicht, daß es jeder Benutzer darf.

Genau, die Benutzer dürfen da gar nix, außer den Webbetreuern.

Dann sag mir bitte, wie ich dem wwwrun mitteilen
kann, dass der Eine zugreifen darf und der Andere
nicht.

Entweder über Server Authentication oder (falls kein
explizites Login gewünscht ist) dadurch, daß der Zu-
griff über ein CGI-Skript läuft und nicht über einen
URL. (Dann müssen die Dateien nicht mal innerhalb des
URL-Raumes liegen.)

Genau das wollte ich wissen. Wie kann ich einen Bildzugriff z.B. über ein PHP-Script regeln. Im Dokument steht dann also z.B. <img src="Bild32.php" ...

Und was liefert PHP dann zurück?

Es ist bestenfalls ein Cookie vorhanden. Also muss
ich den Zugriff auf die Bilder über ein aktives
Servermanagement (z.B. PHP) steuern.

Ja, so würde ich das lösen.

Aber wie?

So long

Tom

[Thoralf Knuth]

Hallo Thomas,

ich poste Dir einfach mal ein Script, was ich seit einer Weile ohne Probleme verwende. Eigentlicher Zweck ist bei mir eine rudimentäre Referer-Kontrolle zur Traffic-Schonung, aber das sollte sich leicht auf Deine Bedürfnisse umstellen lassen.

Dabei ist /grafiken/versteckt/ per .htaccess gesperrt, kann aber natürlich auch ein Pfad ausserhalb der DOCROOT sein.

Ich hab die für Dich unwesentlichen Teile durch /* ... */ ersetzt. Alle entscheidenden Punkte sind vorhanden.

<?php

Standard-Aufruf: bild.php?bild=/grafiken/versteckt/bild.jpeg

error_reporting( E_ALL );
$DOCUMENT_ROOT = getenv( 'DOCUMENT_ROOT' );

$nicht_gefunden_pfad = $DOCUMENT_ROOT . '/images/404.jpg';
$falscher_referer_pfad = $DOCUMENT_ROOT . '/images/403.jpg';

$header_gif  = 'Content-type: image/gif';
$header_jpeg = 'Content-type: image/jpeg';
$header_png  = 'Content-type: image/png';

$HTTP_REFERER = getenv( 'HTTP_REFERER' );
$referer_ok  = false;

$allowed_referers = array(
  /* ... */
); # $allowed_referers = array(

Wurde ein Bild uebergeben?

if( ! isset( $bild ) OR $bild == '' )
{
  header( $header_jpeg );
  readfile( $nicht_gefunden_pfad );
  return;
} # if( ! isset( $bild ) OR $bild == '' )

Soll der Referer gecheckt werden? Wenn denn einer vorhanden ist ;)

if( ! isset( $bild_php_kein_referer_check ) AND $HTTP_REFERER != '' )
{
 /* Code, um den Referer zu checken */
}
else # if( ! isset( $bild_php_kein_referer_check ) )
{
  $referer_ok = true;
}

Referer ok?

if( ! $referer_ok )
{
  header( $header_jpeg );
  readfile( $falscher_referer_pfad );
  return;
} # if( ! $referer_ok )

$datei_uri  = str_replace( '//', '/', '/vorgegebenes_verzeichnis/'. urldecode( $bild ) );
$datei_pfad = $DOCUMENT_ROOT . $datei_uri;

Gibt es das Bild?

if( ! file_exists( $datei_pfad ) )
{
  header( $header_jpeg );
  readfile( $nicht_gefunden_pfad );
  return;
} # if( ! file_exists( $datei_pfad ) )

Korrekten Header senden

switch( strtolower( $datei_pi['extension'] ) )
{
  case 'gif':
    header( $header_gif );
    break 1;
  case 'png':
    header( $header_png );
    break 1;
  case 'jpg':
  case 'jpeg':
  default:
    header( $header_jpeg );
    break 1;
} # switch

Letzte Aenderung durchreichen

if( ! isset( $last_modified ) OR $last_modified == '' )
{
  $datei_zeit = filemtime( $datei_pfad );
  header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s', $datei_zeit ) . ' GMT' );
}
else
{
  header( $last_modified );
}

Soll der korrekte Name zum Speichern mit angegeben weren? Eigentlich ja, aber zB bei naechster_hthumb.php nicht

if( ! isset( $bild_php_dont_give_name ) )
{
  header("Content-Disposition: attachment; filename="" . basename( $datei_pfad ) . """);
}

readfile( $datei_pfad );
return;
?>

Gruss, Thoralf

[Thomas Schmieder]

Hai Thoralf,

Du solltest wohl mal Dein Bildchen ändern... ;-))

Nun wird's also professionell. Das find ich gut. Ich werde zwar mindestens das Wochenende damit verbringen, das alles auszuprobieren, aber soweit ich das eben überblicken konnte, werde ich es wohl verstehen. Der Tipp könnte mir vier Wochen Experimente ersparen. Da fällt mir dann wieder mein alter Leitspruch ein

Intelligenz ist die Fähigleit aus Fehlern Anderer zu lernen.

Nur man muss sich auch trauen, richtig zu fragen. Das nervt natürlich auch manchmal. Umso mehr freue ich mich über Deine Antwort.

Hier sei schon mal angemerkt, das ich den Disput mit Michael noch fortzusezten gedenke, habe aber leider keine Zeit im Moment, muss erstmal meine Verträge zimmern. Ich sehe noch nicht ein, dass es richtig und notwendig ist, den Apache als root laufen zu lassen. Ich halte das sogar für äußerst bedenklich. Ich bin Mitglied im IT-Ausschuss der örtlichen IHK. Eines unserer Themen ist "Sicherheit der EDV in kleinen Betrieben". Ich bin dankbar für jeden Tipp und auch für jeden Kardinalfehler, den ich (beobachtender Weise) mitbekommen darf.

Grüße aus BS

Tom

[Michael Schröpl]

Hi Tom,

Ich sehe noch nicht ein, dass es richtig und notwendig
ist, den Apache als root laufen zu lassen.

sicher nicht in jedem Fall.

Nur wenn die Aufgabenstellung es technisch erzwingt -
und ein CGI-Wrapper tut das, _damit_ mehr Sicherheit
auf dem Server möglich ist (weil _dann_ jeder Benutzer
seine CGI-Skripte unter _seiner_ Kennung laufen lassen
kann - _dann_ kann jeder seinen Verzeichnisbaum per
chmod von anderen abschotten, statt überall "chmod 777"
drauf nageln zu müssen, damit CGI-Skripte unter "wwwrun"
dort Schreibrecht haben).

Viele Grüße
      Michael

[Thoralf Knuth]

Moinsen,

Du solltest wohl mal Dein Bildchen ändern... ;-))

Nö, nö. Das bleibt. Das hat nen Hintergrund und ist ausserdem mein Disclaimer ^^

Nur man muss sich auch trauen, richtig zu fragen. Das nervt natürlich auch manchmal. Umso mehr freue ich mich über Deine Antwort.

Klar, wenn Fragen dazu sind, meld Dich halt ;)
BTW.: hab da eine Zeile zuviel gelöscht, das datei_pi[] hab ich gelöscht, brauchst aber doch an einer Stelle. Solltest Du aber selber finden. :)

Gruss, Thoralf

[Michael Schröpl]

Hi Thomas,

Genau darum gings ja im ursprünglichen Beitrag.
Bilder in die Datenbank oder "lose" auf die Platte.
Der Webserver hat vollen Zugriff

ja.

und stellt dem Benutzer diesen über http: zur
Verfügung.

Nein.

Das heißt, alle Bilder sind erreichbar, wenn man
nur ihren Namen errät.

Nein. (Genauso wenig, als wären sie via Server Authen-
tication geschützt.)

(Und der kann ja unter "root" laufen, falls Deine
Daten so kostbar sind, aber trotzdem andere
Benutzer sich auf diesem Server einloggen
müssen.)
Um Himmels Willen. Wer läßt denn seinen Webserver
unter root laufen.

Jeder, der es braucht, weil der Webserver etwas dürfen
soll, was normale Benutzer nicht dürfen.
Wie willst Du beispielsweise einen CGI-Wrapper verwen-
den, außer in einem unter "root" laufenden Webserver?
Wer außer "root" darf ohne Angabe eines Kennworts die
aktuelle Benutzerkennung seines Prozesses ändern?

Du hast vorausgesetzt, daß fremde Benutzer ein shell-
Login auf der Maschine haben sollen. Wenn dann der
Apache auf Dokumente zugreifen können soll, was andere
Benutzer nicht dürfen, gibt es genau zwei Möglichkeiten:
a) der Apache läuft unter root
b) der Admin definiert für jede Benutzerkennung, die
   einen Webspace besitzt, eine Gruppe, welche genau
   zwei Mitglieder enthält, nämlich diesen Benutzer
   und die Benutzerkennung des Apache-daemons.
Letzteres ist eine schreckliche Arbeit.

Der hat schön einen eigenen Username und eine eigene
Gruppe und deren Rechte sollten auch akriebisch
genau eingestellt werden.

Das finde ich auch ästhetisch. Es gibt aber Fälle, wo
genau das die Aufgabenstellung nicht mehr erfüllt.

Genau, die Benutzer dürfen da gar nix, außer den
Webbetreuern.

Auch die Webbetreuer sind "Benutzer".

Genau das wollte ich wissen. Wie kann ich einen
Bildzugriff z.B. über ein PHP-Script regeln.
Im Dokument steht dann also z.B. <img
src="Bild32.php" ...

Indem Dein PHP-Skript irgendwas erkennt, was Du als
Kriterium für einen befugten Zugriff definierst. Was
das sein könnte, hängt von Deinem Session-Konzept ab.

Und was liefert PHP dann zurück?

Das Bild mit entsprechendem MIME-Typ. (Kein HTML.)

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael