nicht angemeldet
Rolf b
Der Martin
Rolf b
Der Martin
Auge
Matthias Apsel
Julius
Rolf b
Julius
Guten Abend zusammen!
Ich habe vorhin versucht mit einer .htaccess Datei mehrere Ordner meiner Website zu sperren. Zwar besitze ich bereits einen "internen Bereich" auf meiner Website, der auch funktioniert aber nur gewisse php Seiten schützt.
Das Problem ist nun, dass die Bilder zwar nur auf den geschützten .php Seiten vorkommen, jedoch auch über den Quelltext, ohne eingeloggt zu sein, angesehen werden können. --> Wer den konkreten Dateipfad zum Bild kennt, kann sich dieses anzeigen lassen, ohne Passwortabfrage
Deshalb wollte ich den Ordner mit internen Bildern im Bilderverzeichnis durch eine weitere .htaccess Datei sperren.
Mein Problem hierbei liegt nun darin, dass sich die Bilder in mehreren Unterordnern befinden, in etwa so:
-bilder
- BilderÖffentlich
- BilderIntern (hab ich nun ebenfalls mit einer .htaccess geschützt)
- internordner 1
- internordner 2
- internordner 3
-öffentlich.php (ist nicht geschützt, enthält nur öffentliche Bilder)
-intern.php (ist durch .htaccess geschützt und beinhaltet bilder aus internen ordner)
Eigentlich funktioniert mein Vorhaben, dass jede Seite, die ein Bild von den gesicherten Bildern beinhaltet, durch eine Passwortabfrage geschützt wird. Jedoch ist das nur bei Google Chrome und Firefox der Fall.
Wenn ich die intern.php Seite mit Internet Explorer aufrufe, werde ich nicht nur einmal nach einem Passwort gefragt, sondern etliche Male (für jeden Unterordner? / jedes Bild, das von .htaccess betroffen ist?).
Nun wollte ich fragen, ob ich mein Problem auf eine andere Art lösen kann und warum Internet Explorer mein Vorhaben ganz anders interpretiert als die anderen Browser, mit denen ich teste. So ganz falsch kann ich das ja nicht gemacht haben, wenn die anderen Browser es exakt so umsetzen, wie ich will.
Ich hoffe ich konnte euch mein Anliegen näherbringen und bedanke mich im Vorraus für eure Hilfe!
Viele Grüße
Maetzzen
Ich würde ja auf ein Konfigurationsthema im IE tippen (Security- oder Privacy-Einstellungen).
Kannst Du dazu mal einen Link schicken? Ggf. mit einem Pseudo-geschützten Bereich, mit dem sich das nachstellen lässt und zu dem Du das Passwort preisgeben kannst?
Rolf
Ich würde ja auf ein Konfigurationsthema im IE tippen (Security- oder Privacy-Einstellungen).
Aber ich kann ja wohl nicht jedem Benutzer vorschreiben, wie er diesen einzustellen hat.
Kannst Du dazu mal einen Link schicken? Ggf. mit einem Pseudo-geschützten Bereich, mit dem sich das nachstellen lässt und zu dem Du das Passwort preisgeben kannst?
Hier der Link direkt zum internen Bereich
Gerne kannst du es mit dem Testuser ausprobieren: name:test - pw:test123
Das sind die nun die Anmeldedaten für sowohl den internen Bereich, als auch für die vom .htaccess geschützten Bilder.
Mein Problem tritt auf, sobald ich auf "Fotos" gehe (hab gerade nur die von "2017" zum testen da).
Gruß Maetzzen
Edit: Es befinden sich nun 5 "geschützte" Bilder auf der Seite, bei Firefox und Chrome werde ich ein mal nach dem Passwort abgefragt - bei Internet Explorer 5 mal..
Moin,
Ich würde ja auf ein Konfigurationsthema im IE tippen (Security- oder Privacy-Einstellungen).
Aber ich kann ja wohl nicht jedem Benutzer vorschreiben, wie er diesen einzustellen hat.
eben, also solltest du die Ursachen finden und beseitigen - es sei denn, das beobachtete Verhalten tritt nur bei dir auf, weil du Einstellungen vorgenommen hast, die weit vom Bereich des Üblichen weg sind.
Hier der Link direkt zum internen Bereich
Gerne kannst du es mit dem Testuser ausprobieren: name:test - pw:test123
Ich habe keinen IE, kann aber zusätzlich zu deinen Erfahrungen mit Firefox und Chrome ergänzen: Auch mit Opera läuft es so, wie es vermutlich sein soll.
Das sind die nun die Anmeldedaten für sowohl den internen Bereich, als auch für die vom .htaccess geschützten Bilder.
So ... du kombinierst hier zwei verschiedene Arten der Zugangskontrolle. Du hast zunächst ein in PHP realisiertes und vermutlich session-basiertes Login-System, das auch so zu funktionieren scheint, wie es soll. Zusätzlich hast du HTTP Authentication für den Zugriff auf die Bilder. Die beiden Verfahren haben nichts miteinander zu tun, deshalb kann ich auch weiterhin auf die Bilder zugreifen, auch wenn ich mich wieder "abgemeldet" habe.
Sauberer wäre es IMO, du würdest auf HTTP-AUTH verzichten, dann die Bilder in ein Verzeichnis legen, das mit HTTP gar nicht erreichbar ist (also außerhalb des Document Root) und sie ebenfalls mit PHP ausliefern. Dieses PHP-Script prüft dann die Berechtigung anhand des Login-Status und kann sogar im Fehlerfall ein Ersatzbild ausliefern.
Edit: Es befinden sich nun 5 "geschützte" Bilder auf der Seite, bei Firefox und Chrome werde ich ein mal nach dem Passwort abgefragt - bei Internet Explorer 5 mal..
Also bei jedem Zugriff auf eine mit HTTP-AUTH geschützte Ressource. Das deutet für mich eben doch auf ein Problem mit deinem IE hin, der die einmal eingegebenen Zugangsdaten anscheinend nicht speichert. Vielleicht doch irgendeine Privacy-Einstellung ...?
Warten wir ab, was andere IE-Nutzer vielleicht noch sagen.
So long,
Martin
Sauberer wäre es IMO, du würdest auf HTTP-AUTH verzichten, dann die Bilder in ein Verzeichnis legen, das mit HTTP gar nicht erreichbar ist (also außerhalb des Document Root) und sie ebenfalls mit PHP ausliefern. Dieses PHP-Script prüft dann die Berechtigung anhand des Login-Status und kann sogar im Fehlerfall ein Ersatzbild ausliefern.
Das kostet aber einiges an Serverleistung, weil dann jedes Bild mit einem PHP-Schaufelchen über die Sicherheitsbarriere geschippt werden muss, statt direkt ausgeliefert zu werden.
Dass die PHP Authentication und die Bilder-Authentication getrennt sind, scheint Maetzzen ja zu akzeptieren. Wollte man das mit EINER Authentication lösen, dann müsste man den Zugang zum ganzen Internbereich über .htaccess Regeln, sich im PHP drauf verlassen und dort keinen Login mehr machen. Man müsste dann nur wissen, wie man aus PHP auf den im Apache authentisierten User zugreift. Geht bestimmt, hab ich nur noch nie gemacht. Und wie man mit .htaccess eine ausgefeilte Userverwaltung macht, weiß ich auch nicht. Ich kenne das nur mit IIS und ASP.NET...
Rolf
Hi,
Sauberer wäre es IMO, du würdest auf HTTP-AUTH verzichten, dann die Bilder in ein Verzeichnis legen, das mit HTTP gar nicht erreichbar ist (also außerhalb des Document Root) und sie ebenfalls mit PHP ausliefern. Dieses PHP-Script prüft dann die Berechtigung anhand des Login-Status und kann sogar im Fehlerfall ein Ersatzbild ausliefern.
Das kostet aber einiges an Serverleistung, weil dann jedes Bild mit einem PHP-Schaufelchen über die Sicherheitsbarriere geschippt werden muss, statt direkt ausgeliefert zu werden.
stimmt wohl, aber ich glaube nicht, dass die Mehrbelastung wirklich nennenswert ist.
Dass die PHP Authentication und die Bilder-Authentication getrennt sind, scheint Maetzzen ja zu akzeptieren. Wollte man das mit EINER Authentication lösen, dann müsste man den Zugang zum ganzen Internbereich über .htaccess Regeln, sich im PHP drauf verlassen und dort keinen Login mehr machen. Man müsste dann nur wissen, wie man aus PHP auf den im Apache authentisierten User zugreift. Geht bestimmt, hab ich nur noch nie gemacht.
Ja, geht über $_SERVER['AUTH-USER'].
Und wie man mit .htaccess eine ausgefeilte Userverwaltung macht, weiß ich auch nicht.
Mir ist noch nicht klar, wie die beiden Verfahren überhaupt zusammenspielen sollen, d.h. welche Ressourcen für wen zugänglich sein sollen, und warum überhaupt so kompliziert.
Ich kenne das nur mit IIS und ASP.NET...
Damit hatte ich (zum Glück?) noch nicht zu tun.
Ciao,
Martin
Mir ist noch nicht klar, wie die beiden Verfahren überhaupt zusammenspielen sollen, d.h. welche Ressourcen für wen zugänglich sein sollen,
Der interne Bereich soll nur für Benutzer mit Kennwort zugänglich sein. Dort befinden sich (vertrauliche) Bilder, die nicht öffentlich zugänglich sein sollen.
Jeder der sich nur ein wenig auskennt, kann dennoch auf die Bilder zugreifen, da ich diese nicht geschützt habe, sondern nur die internen php Seiten.
Deshalb habe ich versucht die Bilder seperat zu schützen
und warum überhaupt so kompliziert.
weil ich nicht wusste, wie ich das sonst lösen kann.
Ich hoffe es ist nun klarer
Gruß Maetzzen
Dass die PHP Authentication und die Bilder-Authentication getrennt sind, scheint Maetzzen ja zu akzeptieren.
Das stimmt. Auch wenn es bisher nur ein Versuch war - mir ist es lieber wenn einmalig bei dem Zugriff auf die Bilder das Passwort erneut eingegeben werden muss, als dass diese auch ohne Abfrage direkt erreichbar sind. Nur leider will der IE ja nicht nur ein mal nachfragen.. :/
Gruß
Maetzzen
Hallo
Wollte man das mit EINER Authentication lösen, dann müsste man den Zugang zum ganzen Internbereich über .htaccess Regeln, sich im PHP drauf verlassen und dort keinen Login mehr machen. Man müsste dann nur wissen, wie man aus PHP auf den im Apache authentisierten User zugreift. Geht bestimmt, hab ich nur noch nie gemacht.
Der Zugriff auf den Benutzernamen sollte mit $_SERVER['AUTH_USER'] funktionieren.
Und wie man mit .htaccess eine ausgefeilte Userverwaltung macht, weiß ich auch nicht. Ich kenne das nur mit IIS und ASP.NET...
Du kannst in .htaccess auch Gruppen hinterlegen und diesen dann an anderer Stelle die Benutzer sowie deren Credentials zuweisen. Siehe dazu auch den Grundlagenartikel von Michael Schröpl im Wiki. Man kann aber auch für die über .htaccess als zugriffsberechtigt erkannten Benutzer z.B. eine Gruppenverwaltung über eine Datenbank mit Auswertung und Steuerung per PHP nachlagern. Ob das sonderlich performant ist, sei mal dahingestellt.
Tschö, Auge
Sauberer wäre es IMO, du würdest auf HTTP-AUTH verzichten, dann die Bilder in ein Verzeichnis legen, das mit HTTP gar nicht erreichbar ist (also außerhalb des Document Root) und sie ebenfalls mit PHP ausliefern. Dieses PHP-Script prüft dann die Berechtigung anhand des Login-Status und kann sogar im Fehlerfall ein Ersatzbild ausliefern.
Das kostet aber einiges an Serverleistung, weil dann jedes Bild mit einem PHP-Schaufelchen über die Sicherheitsbarriere geschippt werden muss, statt direkt ausgeliefert zu werden.
Wenn es daran hängen sollte, dann hat der Server aber wirklich zu geringe Leistungsreserven.
Wie es geht:
(Dort ab Seite 17 "Schutz von Ressourcen, welche keine PHP-Skripte sind")
Wie es geht:
- Ex-Artikel "PHP/Anwendung und Praxis/Loginsystem" (als PDF, ca, 325 kB)
(Dort ab Seite 17 "Schutz von Ressourcen, welche keine PHP-Skripte sind")
Danke!
Die hier beschriebene Methode bringt (bisher) gewisse Einschränkungen und Nachteile mit sich. Beispielsweise können im Gegensatz zur HTTP-Authentifizierung komplette Verzeichnisse nicht ohne weiteres geschützt werden, der Schutz beschränkt sich lediglich auf Dateien, die von PHP geparst werden. Aber genau das lässt sich ändern. Voraussetzung für das hier gezeigte ist ein Apache-Webserver mit dem Modul mod_rewrite und Sie müssen ggf. die Erlaubnis haben, eine Datei .htaccess anzulegen, die der Server dann auch beachtet. Hier ist ein Beispiel:
Das bezieht sicht ja direkt auf mein Problem. Die Bilder sind nur über die PHP Seiten geschützt, aber per direktem Pfad dennoch ungeschützt erreichbar.
Danke für die PDF, ich bin mal gespannt inwieweit diese mich weiterbringt.
Gruß Maetzzen
Hallo,
Das bezieht sicht ja direkt auf mein Problem. Die Bilder sind nur über die PHP Seiten geschützt, aber per direktem Pfad dennoch ungeschützt erreichbar.
das heißt, sie sind eben nicht geschützt. Deswegen hatte ich ja vorgeschlagen, sie irgendwohin zu verlegen, wo sie nicht durch einen HTTP-Request erreichbar sind.
So long,
Martin
Hallo,
Das bezieht sicht ja direkt auf mein Problem. Die Bilder sind nur über die PHP Seiten geschützt, aber per direktem Pfad dennoch ungeschützt erreichbar.
das heißt, sie sind eben nicht geschützt. Deswegen hatte ich ja vorgeschlagen, sie irgendwohin zu verlegen, wo sie nicht durch einen HTTP-Request erreichbar sind.
Das kann man natürlich statt mit realem (wie im PDF gezeigt) auch über "virtuelle Pfade" im HTTP-Request auch machen. In dem Fall kann man die Antwort einem für den 404er konfigurierten Skript überlassen, welches sich die Session und den Request anschaut, also prüft ob es eine zum virtuellem Pfad gehördende Datei gibt und natürlich die Berechtigung hinterfragt und den Krempel (insbesondere Grafiken) heraussucht und mit korrekten Headern (Status, Mime-Typ, Länge, Caching) sendet oder eben den Fehler mit passendem bzw. willkürlichem Statuscode (404, 403) anzeigt.
Stets Status 404 wenn ein sehr interessierter Unberechtigter auch nicht durch Brute-Force herausbekommen soll, welche Dateien überhaupt existieren.
Ich habe keinen IE, kann aber zusätzlich zu deinen Erfahrungen mit Firefox und Chrome ergänzen: Auch mit Opera läuft es so, wie es vermutlich sein soll.
Das habe ich mir schon gedacht
So ... du kombinierst hier zwei verschiedene Arten der Zugangskontrolle. Du hast zunächst ein in PHP realisiertes und vermutlich session-basiertes Login-System, das auch so zu funktionieren scheint, wie es soll. Zusätzlich hast du HTTP Authentication für den Zugriff auf die Bilder. Die beiden Verfahren haben nichts miteinander zu tun, deshalb kann ich auch weiterhin auf die Bilder zugreifen, auch wenn ich mich wieder "abgemeldet" habe.
Das stimmt, in meinem Internen Bereich hält die Session bis 15 min Inaktivität oder bis zur Abmeldung. Mit dem .htaccess im Bildordner habe ich eben versucht das Problem zu lösen, dass die Bilder durch den direkten Pfad erreichbar sind, ohne aktive Session.
Sauberer wäre es IMO, du würdest auf HTTP-AUTH verzichten, dann die Bilder in ein Verzeichnis legen, das mit HTTP gar nicht erreichbar ist (also außerhalb des Document Root) und sie ebenfalls mit PHP ausliefern. Dieses PHP-Script prüft dann die Berechtigung anhand des Login-Status und kann sogar im Fehlerfall ein Ersatzbild ausliefern.
Das hört sich genau nach dem an, was ich gerne haben möchte. Nur leider versteh ich nicht genau wie ich das anstellen soll.
Da muss ich wohl ein wenig herumforschen
Danke und VG
Maetzzen
Also ich hab jetzt einiges herumprobiert, aber es will nicht so wie es soll.
Du hast zunächst ein in PHP realisiertes und vermutlich session-basiertes Login-System, das auch so zu funktionieren scheint, wie es soll.
Sauberer wäre es IMO, du würdest auf HTTP-AUTH verzichten,
Das wäre mir auch lieber
dann die Bilder in ein Verzeichnis legen, das mit HTTP gar nicht erreichbar ist (also außerhalb des Document Root) und sie ebenfalls mit PHP ausliefern. Dieses PHP-Script prüft dann die Berechtigung anhand des Login-Status und kann sogar im Fehlerfall ein Ersatzbild ausliefern.
Wie genau stelle ich das an? Unser Webhoster ist 1&1 und ich weiß nicht ob ich das außerhalb des root Verzeichnis legen kann. Das session-basierte Loginsystem das ich verwende funktioniert so, dass ich vor jeder Seite die ich schützen will eine Zeile anhänge
Gunnar Bittersmann<?php require_once('auth.php'); ?>
Dabei wird in der auth.php geschaut ob eine aktive Session besteht. Diese wurde zuvor in einem Loginfenster (login.php) abgefragt. Falls Name und Kennwort stimmen, wird die Session gespeichert und gilt bis 15min Inaktivität oder bis man auf "Logout" klickt (session_destroy();).
So kann ich eben nur die einzelnen .php Seiten schützen. Also sollte rein theoretisch, so wie ich mir das vorstelle, bei dem Aufruf der Bilder ebenfalls diese auth.php "abgefragt" werden - ob eine gültige Session besteht.
Ich weiß nicht ob das überhaupt so funktionieren kann, wie ich mir das vorstelle aber eine Lösung gibt es bestimmt - wenn auch nicht mit dem HTTP-AUTH via htaccess.
Gruß Maetzzen
Hallo,
dann die Bilder in ein Verzeichnis legen, das mit HTTP gar nicht erreichbar ist (also außerhalb des Document Root) und sie ebenfalls mit PHP ausliefern. Dieses PHP-Script prüft dann die Berechtigung anhand des Login-Status und kann sogar im Fehlerfall ein Ersatzbild ausliefern.
Wie genau stelle ich das an?
genau so, wie ich es beschrieben habe. ;-)
Die Bilder liegen, wie gesagt, irgendwo, wo man sie mit einem HTTP-Request nicht erreicht. Im Dokument referenzierst du sie dann nicht mehr direkt (das geht ja dann nicht mehr), sondern z.B. so:
<img src="image.php?file=DSC_2081" alt="...">
Das Script image.php prüft nun wieder die Berechtigung, wie gehabt, indem auth.php am Anfang eingebunden wird. Dann prüft es, ob das als Parameter angegebene Bild überhaupt existiert, und falls ja, sendet es den HTTP-Header "Content-Type: image/jpeg" und die Bilddaten hinterher. Ungefähr so:
<?php
require_once "auth.php";
$images = array('DSC_2080', 'DSC_2081', 'DSC_2082', 'DSC_2083');
header('Content-Type: image/jpeg');
if (isset($_GET['file'] && in_array($_GET['file'], $images))
{ readfile('../bilder/' . $_GET['file'] . '.jpg');
}
else
{ readfile('../bilder/notfound.jpg');
}
Ich denke, das ist einfach nachvollziehbar. Wichtig wäre nur, die Pfadangaben anzupassen, und das Array $images zu pflegen, das quasi eine Whitelist erlaubter Dateien darstellt. Würde man auf eine solche Prüfung verzichten, könnten unter Umständen auch andere Dateien (z.B. PHP-Scripte selbst oder die .htaccess-Dateien) durch das Script ausgeliefert werden.
Auf das abschließende ?> habe ich bewusst verzichtet, damit nicht versehentlich am Ende der Bilddaten noch überschüssige Textzeichen (Blanks, Leerzeilen) in der Ausgabe landen.
Unser Webhoster ist 1&1 und ich weiß nicht ob ich das außerhalb des root Verzeichnis legen kann.
Es wäre ein Armutszeugnis für 1&1, wenn das nicht ginge. Aber als Notlösung kann man auch einfach ein x-beliebiges Verzeichnis anlegen und mit einer .htaccess jeden HTTP-Zugriff darauf verbieten - sollte doch jemand zufällig(!) den Verzeichnisnamen wissen, bekommt er beim Zugriff darauf nur die Statusmeldung 403 Access denied.
Btw, was macht deine auth.php eigentlich, wenn die Session nicht aktiv ist?
So long,
Martin
@@Der Martin
sondern z.B. so:
<img src="image.php?file=DSC_2081" alt="...">
Nein, so nicht. Wenn das Bild DSC_2081 für einen Nutzer ohne entprechende Berechtigung nicht angezeigt wird, muss auch ein anderer Alternativtext her. Der Wert des alt-Attributs muss also auch von einem Script generiert werden.
Wohl vorzugsweise Bildreferenz und Alternativtext vom selben Script, welches dann das ganze img-Element generiert.
LLAP 🖖
Hallo Gunnar,
Nein, so nicht. Wenn das Bild DSC_2081 für einen Nutzer ohne entprechende Berechtigung nicht angezeigt wird, muss auch ein anderer Alternativtext her. Der Wert des
alt-Attributs muss also auch von einem Script generiert werden.
Generell hast du wohl recht, aber in diesem speziellen Anwendungsfall tritt dieses Problem nicht auf, weil unberechtigte Nutzer das gezeigte HTML-Markup gar nicht erst zu Gesicht bekommen sollten – Was @Maetzzen verhindern will, ist, dass Nutzer das Bild selbst ohne Berechtigung aufrufen können – sofern ich das richtig verstanden habe.
Gruß
Julius
@@Julius
Wenn das Bild DSC_2081 für einen Nutzer ohne entprechende Berechtigung nicht angezeigt wird, muss auch ein anderer Alternativtext her. Der Wert des
alt-Attributs muss also auch von einem Script generiert werden.Generell hast du wohl recht, aber in diesem speziellen Anwendungsfall tritt dieses Problem nicht auf
Bei Des Martins Variante schon. Da ist das img-Element ja immer im HTML und das Script liefert für Berechtigte das richtige Bild, für die anderen ein Zong-Bild.
Außerdem sollte DSC_2081 einen anderen Alternativtext haben als DSC_2082, DSC_2083, …
weil unberechtigte Nutzer das gezeigte HTML-Markup gar nicht erst zu Gesicht bekommen sollten
Dann müsste das anders implementiert werden:
<?php if (…): ?>
<img src="…/DSC_2081" alt="Alternativtext für DSC_2081"/>
<img src="…/DSC_2082" alt="Alternativtext für DSC_2082"/>
<?php endif; ?>
LLAP 🖖
Hallo,
Generell hast du wohl recht, aber in diesem speziellen Anwendungsfall tritt dieses Problem nicht auf
Bei Des Martins Variante schon. Da ist das
img-Element ja immer im HTML und das Script liefert für Berechtigte das richtige Bild, für die anderen ein Zong-Bild.
richtig, aber nicht Berechtigte würden schon das HTML-Dokument gar nicht erst bekommen.
Außerdem sollte DSC_2081 einen anderen Alternativtext haben als DSC_2082, DSC_2083, …
Klar.
weil unberechtigte Nutzer das gezeigte HTML-Markup gar nicht erst zu Gesicht bekommen sollten
Dann müsste das anders implementiert werden:
Wie denn noch? Ein generelles Login vor dem Zugriff auf die Fotogalerien hat Maetzzen ja schon. Das bleibt natürlich so wie es ist.
So long,
Martin
Hallo Der Martin,
Warten wir ab, was andere IE-Nutzer vielleicht noch sagen.
Ich kann das Verhalten in IE und Edge bestätigen.
Bis demnächst
Matthias
Hallo Martin,
Warten wir ab, was andere IE-Nutzer vielleicht noch sagen.
Die wird man hier mit der Lupe suchen müssen, IE-Tester gibt es eventuell...
;-)
Gruß
Julius
Hallo,
Warten wir ab, was andere IE-Nutzer vielleicht noch sagen.
Die wird man hier mit der Lupe suchen müssen, IE-Tester gibt es eventuell...
;-)
mag sein, dass der IE hier im SELF-Raum weniger stark vertreten ist als in der großen weiten Welt da draußen. Aber ich denke doch, dass er auch hier einen gewissen Anteil ausmacht.
So long,
Martin
Seltsam, der Internetfilter des Netzes, in dem ich sitze, hat zugeschlagen. Ein MC als Verteiler von Spam-Mails? Oder bist Du von einem Bot geplagt, der deinen Mailserver missbraucht?
Ich guck's mir von zu Hause aus an.
URL: http://mc-marchtal.de/intern/login.php
URL-Kategorien: Spam URLs
Reputation: Medium Risk
Medientyp: application/x-empty
Rolf
Hallo Maetzzen,
die einfachste Lösung wäre wohl, deine nicht öffentlichen Bilder einfach unter intern abzulegen und das komplette Login über HTTP-Auth abzuwickeln.
Eine andere Variante wäre die bereits erwähnte mit PHP und readfile. Bei einem internen Bereich eines lokalen Motorradclubs hätte ich weniger Performance-Bedenken als bei einer Website mit mehreren Millionen Aufrufen am Tag.
Eine Frickel-Lösung wäre die, die Zugangsdaten in die URL einzubinden, also https://user:password@example.org/img/file.jpg – wobei zu beachten ist, dass auch hier eine Abfrage erfolgen wird (Zugangsdaten müssen aber nicht mehr eingegeben werden!) und die Zugangsdaten mehrmals unverschlüsselt übers Netz wandern (du nutzt ja kein https):
Ob dieses Vorgehen bei Nutzung von https empfehlenswert wäre und ob der IE nicht auch hier dazwischen grätscht, kann ich nicht beurteilen...
Gruß
Julius