htpasswd / htaccess Cache leeren

vlad

Hallo, gibt man im Passwort-Popup ein richtiges Passwort für eine htpasswd-geschützte Seite ein, bleibt diese Passwort-Kombination bis zum nächsten Browser-Restart gespeichert/gecached.

Wie kann ich den Browser dazu zwingen, nicht mehr auf den bisherigen Benutzernamen/Passwort zuzugreifen, *ohne* Firefox neu starten zu müssen? Gibt es eine Extension dafür?

Achtung: Ich möchte keine gespeicherten Passwort-Kombinationen löschen. Das ist nicht Gegenstand meiner Anfrage...

.Ulli

Zitat von vlad

[...] bleibt diese Passwort-Kombination bis zum nächsten Browser-Restart gespeichert/gecached.

Prüfe doch einmal auf der Ebene der Session-Cookies. Wenn ein Cookie gesetzt wurde, lösche es mal.

boardraider

Private Daten löschen > Gesicherte Verbindungen

vlad

Leider löst nichts davon das Problem...

Nochmal...

Ich habe die URL http://server.com/members/
Ich gebe im Popup User/Pass ein. Solange ich Firefox nicht neu starte, kann ich mich x-beliebig wieder einloggen, ohne User/pass neu eingeben zu müssen.

"clear private data -> authenticated sessions" habe ich versucht, doch bringt das nichts. Cookies werden auch nicht gesetzt.

Ich möchte einfach nur verhindern, dass ich diese Zwischenspeicherung an beliebiger Stelle unterbrechen kann, so dass ich mich mit anderem User/pass einloggen kann ohne Neustart
Die "saved passwords" möchte ich natürlich nicht löschen. Möchte nur, dass man wie bei einem Neustart erneut nach User/pass gefragt wird...

.Ulli

Löst No-Referrer das Problem ?

vlad

Zitat von .Ulli

Löst No-Referrer das Problem ?

Leider nicht. Wenn ich direkt http://server.com/members/ in der URL-Leiste eingebe, wird sowieso kein Referrer gesandt...
Das Problem ist nicht seitenspezifisch. Tritt bei allen Servern auf, wo Verzeichnisse mit htpasswd / htaccess geschützt sind...

.Ulli

Zitat von vlad

Leider nicht. Wenn ich direkt http://server.com/members/ in der URL-Leiste eingebe, wird sowieso kein Referrer gesandt...

Nicht so ganz, wenn ich das mache:

Zitat

http://server.com/members/
GET /members/ HTTP/1.1 <-- die Anfrage
Host: server.com <-- bei diesem Host
[...]
HTTP/1.x 404 Not Found <-- Fehler und wo geht es weiter
http://www.about-servers.com/eflp/server/pid200342/D609288/C0
[...]
GET /eflp/server/pid200342/D609288/C0 HTTP/1.1 <-- neue Anfrage
Host: http://www.about-servers.com <-- jetzt bei diesem Host
[...]
Referer: http://server.com/members/
Cookie: ServerID=1033; PHPSESSID=a7cf5ff179b4ca8b2552483d46a4162c

Alles anzeigen

Und ich sehe sowohl den Referer als auch ein Cookie, von server.com gesetzt.
Kannst Du Dir selbst mit Live HTTP Headers anschauen.

Zitat von vlad

Das Problem ist nicht seitenspezifisch. Tritt bei allen Servern auf, wo Verzeichnisse mit htpasswd / htaccess geschützt sind...

Klar, Dein Firefox schickt Informationen, damit der Server Dich wieder erkennt.

Falls No-Referrer zu spät zieht, teste mal RefControl

boardraider

vlad
Bitte mal ne Beispielseite.

vlad

Nein, ich denke mit dem Referrer hat das nichts zu tun...

Beispiel:

http://fasala.de/test/
user: vlad
pass: test

Ohne FF neu starten zu müssen, will ich, dass das Popup für User/pass erneut erscheint...

Coce

Zitat von vlad

Ohne FF neu starten zu müssen, will ich, dass das Popup für User/pass erneut erscheint...

Das geht bei mir, wenn ich, wie boardraider schon geschrieben hat

Zitat von boardraider

Private Daten löschen > Gesicherte Verbindungen

wähle.

vlad

Ja, auf meinem Beispiel geht es tatsächlich
So ein Mi...

Auf der Site, um die es mir geht, funktioniert es aber nicht. Nicht einmal referrer-Ausschalten und "clear authenticated sessions" in Kombination.

.Ulli

Der erkennbare Unterschied ist jetzt im Header

Code

Authorization: Basic dmxhZDp0ZXN0

Dass das durch gesicherte Verbindungen löschen entfernt wird, hätte ich nicht erwartet.

Wie schaut denn dann der Header auf der Seite aus, auf der es nicht funktioniert ? Wenn es nicht Cookie, Referrer und Authorization ist.

vlad

Kann es mit etag zu tun haben?

Zitat

HTTP/1.x 401 Authorization Required
Date: Thu, 16 Aug 2007 22:53:29 GMT
Server: Apache/2.0.52 (Red Hat)
WWW-Authenticate: Basic realm="Hello World!"
Last-Modified: Mon, 30 Oct 2006 21:36:05 GMT
Etag: "xxxxxxx-xxxxx-xxxxxxxx"
Accept-Ranges: bytes
Content-Length: 1220
Connection: close
Content-Type: text/html
GET /xyz/members/ HTTP/1.1
Host: http://www.server.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: x-mac-roman,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
If-Modified-Since: Wed, 15 Aug 2007 00:52:38 GMT
If-None-Match: "xxxxx-xxxxx-xxxxxxxx"
Authorization: Basic Ymxxxxxxxxxxxxxxxxxxxxxxx==
HTTP/1.x 304 Not Modified
Date: Thu, 16 Aug 2007 22:53:47 GMT
Server: Apache/2.0.52 (Red Hat)
Connection: close
Etag: "xxxxxxx-xxxxx-xxxxxxxx"

Alles anzeigen

.Ulli

Etag (Entity-Tag): Der Wert von ETag wird bei der Cache-Verwaltung zur Einsparung von Netzwerk-Bandbreite benutzt.

Code

Etag: "xxxxxxx-xxxxx-xxxxxxxx" <-- für den Cache gesetzt
[...]
If-Modified-Since: Wed, 15 Aug 2007 00:52:38 GMT <-- Cache Object
If-None-Match: "xxxxx-xxxxx-xxxxxxxx" <-- Cache Object
Authorization: Basic Ymxxxxxxxxxxxxxxxxxxxxxxx== <-- gesicherte Verbindung
[...]
HTTP/1.x 304 Not Modified
Etag: "xxxxxxx-xxxxx-xxxxxxxx" <-- gültig im Cache

Die Seite wird empfangen und im Cache abgelegt. Bei der Abfrage wird die Information aus dem Cache und die Authorization gesendet. Die Antwort 304 ist eine gültige Seite im Cache, die angezeigt wird.

Somit einmal den Cache und die gesicherte Verbindung löschen.