Bilder, Header, Caching?

[toby]

Hallo zusammen,

ich speichere Bilder ausserhalb des Webroots, um den Zugriff darauf kontrollieren zu können, der Aufruf erfolgt dann mit Übergabe eines aus Session-ID und Bildname generierten MD5-verschlüsselten Keys:

<?echo "<img src="show.php?dateiname=" . urlencode($bildbesitzer . "/" . $thumb) . "&key=$key" border="0" alt="" width="$breite" hoehe="$hoehe"></a>";?>

Das Skript sieht so aus:

<?
session_start();

if($key == md5(session_id() . $dateiname)):

header("Content-type: image/jpeg");
 readfile/pfad/zu/den/bildern/$dateiname");

else:

echo "Du hast keine Berechtigung, dieses Foto anzusehen.";

endif;
?>

Mein Problem ist, dass die Bilder so nicht gecached werden. Hat jd. vielleicht einen anderen Lösungsansatz, der dieses Problem vermeidet?

Danke schonmal...

toby--
"Trying is the first step toward failure." - H. Simpson

[Sven Rautenberg]

Moin!

ich speichere Bilder ausserhalb des Webroots, um den Zugriff darauf kontrollieren zu können, der Aufruf erfolgt dann mit Übergabe eines aus Session-ID und Bildname generierten MD5-verschlüsselten Keys:

<?echo "<img src="show.php?dateiname=" . urlencode($bildbesitzer . "/" . $thumb) . "&key=$key" border="0" alt="" width="$breite" hoehe="$hoehe"></a>";?>

Mein Problem ist, dass die Bilder so nicht gecached werden. Hat jd. vielleicht einen anderen Lösungsansatz, der dieses Problem vermeidet?

Dein Problem ist, dass dein Ansatz nicht funktioniert. Ich kriege das Bild genau dann, wenn ich die korrekte URL angebe. Und sofern du deine Sessions nicht auf Cookies basieren läßt, wird an die URL eben auch die Session-ID angehängt, so dass sowohl die Session-ID, der Dateiname als auch die zugehörige MD5-Prüfsumme in der URL enthalten sind und stimmen.

Und wenn du die Cookies zwingend vorschreibst, funktioniert dein System bei all denen nicht, die keine Cookies zulassen - auch wenn sie korrekt auf deiner Seite surfen.

- Sven Rautenberg

[toby]

Hallo Sven,

Dein Problem ist, dass dein Ansatz nicht funktioniert.

Ahem. Doch, ich hätte vielleicht dazu sagen sollen, dass das ganze nur für registrierte User funktioniert, die sich sowieso über ein Login-System identifizieren müssen. Das ganze funzt schon einwandfrei, nur werden so die Bilder eben immer völlig neu generiert, was bei langsameren Verbindungen ziemlich ärgerlich sein kann.

Cookies sind sowieso ein Muß auf dieser Seite... das ist also nicht das Problem.

toby

[Andreas Korthaus]

Hallo!

Dein Problem ist, dass dein Ansatz nicht funktioniert.

warum? Sessions haben doch einen Timeout! Also ändern sich die URLs ständig, was zu dem besagten caching-Problemen führt, die man IMHO nicht umgehen kann solange die URLs sich ändern.

Ahem. Doch, ich hätte vielleicht dazu sagen sollen, dass das ganze nur für registrierte User funktioniert, die sich sowieso über ein Login-System identifizieren müssen. Das ganze funzt schon einwandfrei, nur werden so die Bilder eben immer völlig neu generiert, was bei langsameren Verbindungen ziemlich ärgerlich sein kann.

Was heißt generiert? Ist das ein Problem der langsamen Leitung oder des langsamen Servers?
Wie funktioniert der Login? Wenn Du das mit Sessions machst funktioniert der Schutz der Bilder nur wenn Du diese alle von einem Script ausführen läßt welches die SessionID/Zugangsdaten prüft.

Der schlauere Weg wäre eine HTTP-Authentifizierung, damit  könnten die Bilder ihre URLs behalten und Du mußt Dich um nichts kümmern, es kommen so nur authentifizierte User an die Bilder, und da die URLs gleich bleiben werden die Bilder normal gecached.

Cookies sind sowieso ein Muß auf dieser Seite... das ist also nicht das Problem.

Dann lass die URLs gleich und prüfe im Script welches die Bilder ausliefert genau wie in jedem anderen Script ob es ein gültiger User ist.

Grüße
Andreas

[toby]

hallo,

Hallo!

Was heißt generiert? Ist das ein Problem der langsamen Leitung oder des langsamen Servers?

Ich weiß nicht viel über Browser-Caching. Aber ein Bild, das ich so aufrufe: <img src="show.php"> kann wohl nicht gecached werden...

Wie funktioniert der Login? Wenn Du das mit Sessions machst funktioniert der Schutz der Bilder nur wenn Du diese alle von einem Script ausführen läßt welches die SessionID/Zugangsdaten prüft.

Ja, klar. Ich mache halt das alte Login -> Checken in mySQL-DB -> Setzen einer Session-Variable -> Checken der Variable Spiel ;) Nur hat das alles nix mit meinem Problem zu tun :)

Von HTTP-Authentifizierung halte ich nicht viel, wenn es um komplexere Rechtevergabe geht. Da kommste auch nicht weit.

toby

[Andreas Korthaus]

Hi!

Ja, klar. Ich mache halt das alte Login -> Checken in mySQL-DB -> Setzen einer Session-Variable -> Checken der Variable Spiel ;) Nur hat das alles nix mit meinem Problem zu tun :)

Ich war davon ausgegangen dass das der Browser das dann cachen kann(solange sich die URL nicht ständig ändert).

Von HTTP-Authentifizierung halte ich nicht viel, wenn es um komplexere Rechtevergabe geht. Da kommste auch nicht weit.

Ja? Wieso kommt Du bei Deiner Version weiter? Der einzige Unterschied besteht darin dass Du eine SessionID überträgst und bei http-auth user:pass. Warum eine SessionID mehr Möglichkeiten bietet verstehe ich nicht. Du kommst über $_SERVER['REMOTE_USER'] an den Usernamen von http-auth, damit kannst Du dasselbe machen wie Du mit $_SESSION['username'] oder einem entsprechenden DB-Eintrag machen würdest. Ich finde das recht praktisch und Du kannst immer .jpg verwenden ohne Probleme zu haben.

Grüße
Andreas

[toby]

Hallo Andreas,

ich drück es mal anders aus: da komm ich nicht weit ;) Hab ich noch nie probiert.

Aber ist es nicht so, dass ich dann ein Verzeichnis schütze? Ich kontrolliere halt im Moment durch das Login-System, welche Links ein User überhaupt zu sehen bekommt. Ohne einen gültigen Link kann er sich auch kein Bild anzeigen lassen, und einen gültigen Link zu setzen, setzt voraus, dass er sowohl den Bildnamen als auch den Verschlüsselungsalgorithmus (der natürlich noch eine Variable mit verschlüsselt, die ich jetzt mal nicht gepostet habe ;) ) kennt.

Ist es bei http-auth nicht so, dass er mit einem gültigen Login an alle Bilder in dem Ordner kommt, für den er sich identifiziert? Das würde es halt ungleich komplizierter machen, einzelne Bilder mit verschiedenen Rechten für versch. User zu versehen...

toby

[Sven Rautenberg]

Moin!

Hallo!

Dein Problem ist, dass dein Ansatz nicht funktioniert.
warum? Sessions haben doch einen Timeout! Also ändern sich die URLs ständig, was zu dem besagten caching-Problemen führt, die man IMHO nicht umgehen kann solange die URLs sich ändern.

Anhand der gegebenen Informationen ist das eigentlich relativ klar.

Wir haben:
1. Eine Bild-URL der folgenden Form:
show.php?dateiname=($bildbesitzer)/($thumb)&key=($key)&PHPSESSID=(1234354678)

2. Ein Skript:
<?
session_start();

if($key == md5(session_id() . $dateiname)):

header("Content-type: image/jpeg");
 readfile/pfad/zu/den/bildern/$dateiname");

else:

echo "Du hast keine Berechtigung, dieses Foto anzusehen.";

endif;
?>

Das Skript entnimmt alle Informationen, die es zu verarbeiten hat, der URL. Also reicht es aus, eine gültige URL zu verwenden.

Die "Sicherheit" besteht darin, dass in $key der MD5-Hash aus Session-ID und Dateiname enthalten ist. Alle drei Informationen, Key, Dateiname und Session-ID, sind aber in der URL enthalten. Und um das Bild zu kriegen, müssen diese Informationen passen.

Dass hier eine Session verwendet wird, bringt leider nichts. session_start() bewirkt, dass PHP den Cookie oder die URL oder das Formular auf eine Session-ID hin durchsucht. Wenn kein anderer ID-Name gesetzt wurde, wird nach "PHPSESSID" gesucht. Wenn sowas gefunden wurde, wird die Session mit der angegebenen ID gestartet (d.h. session_id() gibt dann diese ID zurück, die in der URL steht).

Dass eine Session einen Timeout hat, ist hierbei irrelevant. Der Timeout bewirkt nur, dass die auf dem Server gespeicherten Session-Variablen irgendwann weg sind. Hier wird aber auf keinerlei Session-Variablen zugegriffen. Also bringt ein Timeout auch nichts.

Wenn keine weiteren Informationen ausgewertet werden, die _nicht_ dem Client übermittelt werden (also z.B. Authentifizierungsinformationen in Session-Variablen, oder HTTP-Auth), dann ist das System nicht sicher, sondern bringt nur Zusatzaufwand für die Auslieferung der Bilder.

Es bringt auch nichts, noch mehr Informationen an den MD5-Hash anzuhängen - wenn diese Informationen auch per URL übermittelt werden.

Wenn sowas funktionieren soll, dann darf die Information, welches Bild ausgeliefert werden soll, nicht zum Client geliefert werden, sondern muß als Session-Variable durchgereicht werden.

- Sven Rautenberg

[toby]

Hallo Sven,

Wenn sowas funktionieren soll, dann darf die Information, welches Bild ausgeliefert werden soll, nicht zum Client geliefert werden, sondern muß als Session-Variable durchgereicht werden.

Wie irgendwo ;) gesagt, ich verschlüssele ja noch zusätzlich zur Session-Id eine Variable, um zu verhindern, dass irgendjd. die Verschlüsselung nachvollziehen kann. Das sieht eigentlich so aus:

$key = md5(session_id() . $bildbesitzer . $secret . $thumb);

Und show.php prüft diese Variable. Ich wüßte nicht, wieso es da ein Problem geben sollte... Um den gleichen Key zu bekommen müßtest Du alled diese Variablen kennen: die ID, die für das Bild als Besitzer in der DB eingetragen ist, die geheime Variable, den Namen des Bildes und die SessionID, und wissen, dass die Verschlüsselung so erfolgt...

toby

[Sven Rautenberg]

Moin!

Wie irgendwo ;) gesagt, ich verschlüssele ja noch zusätzlich zur Session-Id eine Variable, um zu verhindern, dass irgendjd. die Verschlüsselung nachvollziehen kann. Das sieht eigentlich so aus:

$key = md5(session_id() . $bildbesitzer . $secret . $thumb);

Woher weiß show.php die Variable $secret? Ist die fest definiert? Dann hast du verloren!

Nur wenn sie pro Request bzw. pro Session neu definiert und als Session-Variable _nicht_ an den Browser übergeben wird, sondern auf dem Server verbleibt, bringt sie etwas.

Und show.php prüft diese Variable. Ich wüßte nicht, wieso es da ein Problem geben sollte... Um den gleichen Key zu bekommen müßtest Du alled diese Variablen kennen: die ID, die für das Bild als Besitzer in der DB eingetragen ist, die geheime Variable, den Namen des Bildes und die SessionID, und wissen, dass die Verschlüsselung so erfolgt...

show.php kriegt alle Informationen, die es prüft, per URL vom Client. Und da du die URLs natürlich dynamisch generierst und nur gültige URLs erzeugst, erlaubt allein die URL Zugriff - wenn in der URL ein Bestandteil versteckt wird, der einem beliebigen Client nicht bekannt ist, so wie z.B. ein dynamischer Anteil $secret, der sich pro Request oder zumindest pro Session verändert, und auch nicht von der Session-ID abhängt (die kann man zur Not aus dem Cookie auslesen und in die URL packen), sondern zufällig generiert wird und als Session-Variable den Server niemals verläßt - erst dann funkioniert dein Schutz.

Es geht hierbei nicht darum, wie du deinen MD5-Hash zusammensetzt, sondern wie du ihn auf Gültigkeit prüfst.

Du könntest auch ein Array als Session-Variable erstellen, in das du alle auszuliefernden Bilder einträgst, sobald der User sie abfordert. Wird das erste Bild in eine Seite eingebaut, wird z.B. $_SESSION['bilder'][0]='bildpfad/datei.gif' gesetzt. Und der Link zum show.php enthält nur die ID: "show.php?id=0". show.php weiß aufgrund der Session-ID jetzt, welches Bild zu laden ist. Und da die Session irgendwann einen Timeout hat, geht die Information, welches Bild hinter ID 0 steckt, irgendwann verloren. Man kann also nicht von extern aufs Bild linken.

Wenn du aber ohnehin einen Login-Mechanismus eingebaut hast, der das direkte, unangemeldete Verlinken von Bildern unmöglich macht - warum dann noch das Gehampel mit dem MD5-Hash etc.

Bedenke auch: Wenn du kein Directory-Listing erlaubt hast, kann man an ein Bild nur dann kommen, wenn man dessen URL kennt. Mit deinem Mechanismus kann man höchstwahrscheinlich auch an das Bild kommen, wenn man dessen URL kennt. Und im Zweifel kann man an die Bilder auch rankommen, indem der eine dem anderen das Bild mailt.

- Sven Rautenberg

[toby]

Moin again,

Woher weiß show.php die Variable $secret? Ist die fest definiert? Dann hast du verloren!

Nur wenn sie pro Request bzw. pro Session neu definiert und als Session-Variable _nicht_ an den Browser übergeben wird, sondern auf dem Server verbleibt, bringt sie etwas.

Hmm... wenn $secret fest definiert ist, und ich per MD5 einen String verschlüssele, der aus $secret . $dateiname . $sessionid zusammengesetzt ist, dann hast Du doch keine Möglichkeit, das nachzuvollziehen, oder habe ich da einen Denkfehler? Die Variable Größe ist die SessionID, die könntest Du zur not nachvollziehen, $secret aber nicht. Auch wenn sie immer gleich ist. Du kennst Sie ja nicht und sie ist verschlüsselt zusammen mit der SessionID.

Und show.php prüft diese Variable. Ich wüßte nicht, wieso es da ein Problem geben sollte... Um den gleichen Key zu bekommen müßtest Du alled diese Variablen kennen: die ID, die für das Bild als Besitzer in der DB eingetragen ist, die geheime Variable, den Namen des Bildes und die SessionID, und wissen, dass die Verschlüsselung so erfolgt...

show.php kriegt alle Informationen, die es prüft, per URL vom Client. Und da du die URLs natürlich dynamisch generierst und nur gültige URLs erzeugst, erlaubt allein die URL Zugriff - wenn in der URL ein Bestandteil versteckt wird, der einem beliebigen Client nicht bekannt ist, so wie z.B. ein dynamischer Anteil $secret, der sich pro Request oder zumindest pro Session verändert, und auch nicht von der Session-ID abhängt (die kann man zur Not aus dem Cookie auslesen und in die URL packen), sondern zufällig generiert wird und als Session-Variable den Server niemals verläßt - erst dann funkioniert dein Schutz.

Der verändert sich doch pro Bild und Session, da mein Hash aus $secret, $dateiname und $sessionid zusammengesetzt wird.

Es geht hierbei nicht darum, wie du deinen MD5-Hash zusammensetzt, sondern wie du ihn auf Gültigkeit prüfst.

Ich kann Dir gerade nicht folgen... Wenn Du nicht weißt, wie ich ihn zusammensetze kannst Du ihn doch auch nicht faken? Anderer Browser, andere Session, anderes Bild = anderer Hash = kein Zugriff, weil Du eben $secret nicht weißt. Kannste mir das nochmal verdeutlichen? Ich check es nicht.

Du könntest auch ein Array als Session-Variable erstellen, in das du alle auszuliefernden Bilder einträgst, sobald der User sie abfordert. Wird das erste Bild in eine Seite eingebaut, wird z.B. $_SESSION['bilder'][0]='bildpfad/datei.gif' gesetzt. Und der Link zum show.php enthält nur die ID: "show.php?id=0". show.php weiß aufgrund der Session-ID jetzt, welches Bild zu laden ist. Und da die Session irgendwann einen Timeout hat, geht die Information, welches Bild hinter ID 0 steckt, irgendwann verloren. Man kann also nicht von extern aufs Bild linken.

Nice idea.

Wenn du aber ohnehin einen Login-Mechanismus eingebaut hast, der das direkte, unangemeldete Verlinken von Bildern unmöglich macht - warum dann noch das Gehampel mit dem MD5-Hash etc.

One step beyond ;)

Und im Zweifel kann man an die Bilder auch rankommen, indem der eine dem anderen das Bild mailt.

Das ist mir klar. Ich versuche halt die bestmögliche Lösung zu finden, aber irgendwie bin ich noch nicht zufrieden.

grüße,

toby

[Sven Rautenberg]

Moin!

Moin again,

Woher weiß show.php die Variable $secret? Ist die fest definiert? Dann hast du verloren!

Nur wenn sie pro Request bzw. pro Session neu definiert und als Session-Variable _nicht_ an den Browser übergeben wird, sondern auf dem Server verbleibt, bringt sie etwas.

Hmm... wenn $secret fest definiert ist, und ich per MD5 einen String verschlüssele, der aus $secret . $dateiname . $sessionid zusammengesetzt ist, dann hast Du doch keine Möglichkeit, das nachzuvollziehen, oder habe ich da einen Denkfehler? Die Variable Größe ist die SessionID, die könntest Du zur not nachvollziehen, $secret aber nicht. Auch wenn sie immer gleich ist. Du kennst Sie ja nicht und sie ist verschlüsselt zusammen mit der SessionID.

Der MD5-Hash nützt dir ja nichts, wenn du ihn nicht in show.php mit den dort hineingepflanzten Werten vergleichst.

Das bedeutet: Um die URL zu generieren, benutzt du $secret, $dateiname und $sessionid.

In der URL enthalten sind schon: $sessionid und $dateiname. Fehlt noch $secret. Da dieser Wert aber konstant ist, brauch ich ihn gar nicht kennen. Ich muß nur die zum MD5-Hash passenden Werte für $sessionid und $dateiname wählen, und komme dann an das Bild. Und zufällig kenne ich eine Kombination aus $dateiname, $sessionid und MD5-Hash, die mir ein Bild liefert: Nämlich genau die URL, die du in die Seite geschrieben hast, um das Bild zu liefern.

Mit anderen Worten: Die Session hilft dir absolut gar nicht, der MD5-Hash hilft dir auch nicht. Wenn du prüfen willst, ob der Hash gültig ist, verläßt du dich auf die Konstante $secret, und den übermittelten Dateinamen $dateiname sowie auf die Session-ID, die man ebenfalls festlegen kann, sofern man sie kennt.

Oder als Gleichungen ausgeführt:

$md5 = md5(SECRET + $dateiname + $sessionid)
URL = $md5 + $dateiname + $sessionid

Das generiert die URL.

Und um zu prüfen, ob die URL geht, verwendest du nur URL-Daten.

$md5 == md5(SECRET + URL($dateiname) + URL($sessionid))

Oder auch:

md5(SECRET + $dateiname + $sessionid) == md5(SECRET + URL($dateiname) + URL($sessionid))

Da SECRET == SECRET und $dateiname == URL($dateiname) und $sessionid == URL($sessionid), wird auch jegliche MD5-Prüfsumme von beiden Seiten immer identisch sein.

show.php kriegt alle Informationen, die es prüft, per URL vom Client. Und da du die URLs natürlich dynamisch generierst und nur gültige URLs erzeugst, erlaubt allein die URL Zugriff - wenn in der URL ein Bestandteil versteckt wird, der einem beliebigen Client nicht bekannt ist, so wie z.B. ein dynamischer Anteil $secret, der sich pro Request oder zumindest pro Session verändert, und auch nicht von der Session-ID abhängt (die kann man zur Not aus dem Cookie auslesen und in die URL packen), sondern zufällig generiert wird und als Session-Variable den Server niemals verläßt - erst dann funkioniert dein Schutz.

Der verändert sich doch pro Bild und Session, da mein Hash aus $secret, $dateiname und $sessionid zusammengesetzt wird.

Ja, da ändert sich was. Aber niemand wird gehindert, die Session-ID selbst vorzugeben. Und wenn _ein_ Bild geladen werden soll, dessen Existenz bekannt ist, und dessen eine URL bekannt ist, kann diese URL immer wieder dazu verwendet werden, das Bild zu laden (es sei denn, es ist ein Authentifizierungsmechanismus davor).

$sessionid kann auf den Wert gesetzt werden, den die Session zur Auslieferung der URL mal hatte, $secret ist konstant (und für die Sicherheit irrelevant), und $dateiname ist genau das Bild, was man gerne hätte.

Deine Vorgehensweise verhindert mehr oder weniger, dass man durch Ausprobieren _andere_ Bilder erhält, deren URL man noch nicht kennt. Allerdings kann man solch einen Effekt auch erreichen, indem man einfach nur einen sessionbasierten Authentifizierungsmechanismus vor die Bildauslieferung setzt:

show.php?dateiname=bild.gif&PHPSESSID=sessionid

Solch ein Link reicht vollkommen aus. Da steht eindeutig der Bildname drin, und die Session-ID, unter der der Benutzer angemeldet ist. Die show.php erkennt anhand der ID den angemeldeten Benutzer, kennt daraufhin auch die Zugriffsrechte des Benutzers, und kann den Zugriff auf das gewünschte Bild gestatten oder verweigern. Und damit der rumspielende User nicht Hinweise darauf kriegt, welche Bilder es tatsächlich gibt, die er aber nicht sehen darf, sollte das Skript bei verweigertem Zugriff mit einem Status "404 Not found" antworten, ebenso wie bei wirklich nicht gefundenen Bildern.

Wie gesagt: Diese Methode greift echt auf Session-Informationen zurück, die der Client _nicht_ besitzt. Man kann nicht einfach eine Session-ID erfinden (bzw. eine altbekannte ID benutzen), um jederzeit Zugriff auf das Bild zu erhalten, weil bei erfundenen IDs keine Session-Variablen auf dem Server vorhanden sind, die den Benutzer authentifizieren, und bei alten Session-IDs meldet sich der Benutzer irgendwann ab bzw. erfolgt ein Timeout, so dass die Authentifizierungsdaten irgendwann verfallen und einen Zugriff ebenfalls unmöglich machen.

Und man kann aufgrund der Menge an Session-IDs, die es gibt, auch unmöglich eine aktive Session-ID raten. Das dauert Jahrtausende und würde einen derzeit von einem Server absolut noch nicht zu bewältigenden Datenstrom erfordern.

- Sven Rautenberg

[toby]

hallo,

ich bin verstockt oder zu doof.

Solange keiner weiß, wie der MD5-Hash generiert wird, kann er doch auch keine gültige URL schicken, oder nicht? Und ob $secret dann konstant ist, halte ich für irrelevant, da es ja nicht in der URL übergeben wird, sondern in den beiden Scripten versteckt ist.

Wie dem auch sei, wahrscheinlich hast Du Recht und es ist besser, direkt im anzeigenden Script die Berechtigung zu prüfen...

toby

[Sven Rautenberg]

Moin!

ich bin verstockt oder zu doof.

Solange keiner weiß, wie der MD5-Hash generiert wird, kann er doch auch keine gültige URL schicken, oder nicht?

Du generierst eine gültige URL. Wer diese URL kennt, kann auf das Bild zugreifen. Diese URL ist aber bei deinem jetzigen Schema _immer_ gültig. Das Skript prüft nur, ob gewisse Daten der URL zu gewissen anderen Daten der URL passen. Und das ist immer der Fall.

Dass du noch einen konstanten Faktor $secret in den MD5-Hash einbringst, ist irrelevant, weil dieser ja _konstant_ ist, für jeden Benutzer. Er bringt also keine zusätzliche Prüfbarkeit hinein, er verhindert nur, dass man beliebige URLs selber generieren kann, um auf andere Bilder zuzugreifen.

Du verhinderst also, dass jemand auf andere als die in der Seite enthaltenen Bilder zugreifen kann. Das kann aber sowieso nicht, wenn man den exakten Bildnamen nicht kennt, und kein Directory-Listing hat. Das Ausprobieren wird dabei nur sehr viel schwieriger bei so offensichtlichen Namen wie "bild0001.jpg" - wer würde da nicht "bild0002.jpg" testen? Das geht mit MD5 nicht - es wäre auch ohne $secret sehr schwer, weil man das Bildungsgesetz für den MD5-Hash ja kennen müßte.

Wie dem auch sei, wahrscheinlich hast Du Recht und es ist besser, direkt im anzeigenden Script die Berechtigung zu prüfen...

Das ist besser, wenn deine Sicherheitsprüfungen einen Sinn haben sollen.

- Sven Rautenberg