Beiträge von Junker Jörg

Teste im Safe Mode, und wenn das nicht hilft, mit einem neuen Profil.

Das mit dem irrelevant bezog sich auf den Erfolg des Einloggens. Bei einer Einmal-Challenge ist es irrelevant, ob der Hash nicht verifiziert wird oder ob der Hash verifizierbar ist, aber die Challenge als Double erkannt wird - das Einloggen wird verweigert.

Das eine erfolgreiche Korrelation zwischen Hash und Challenge Grundvoraussetzung für erfolgreiches Einloggen ist, ist unbestritten. Deshalb sollten wir diesem etwas mehr Aufmerksamkeit schenken:

Zitat von boardraider

...(Session-ID)...

Vielleicht werden entsprechende Cookies verhindert - entweder im FF selbst, oder durch Dritt-Software?

Zitat von boardraider

Der Fx wartet keine OnSubmit-Handler ab und speichert den Wert unmittelbar davor.

Danke für die Info. Hast recht, nur so macht es Sinn.

Zitat von boardraider

Allerdings sendet der Fx den Challenge-Wert ebenfalls zurück zum Server. So dieser keine Verfallszeit für Challenge-Werte definiert, wäre das Vorgehen damit auch transparent bei einem falsch implementierten Caching-Proxy.

Ich gehe davon aus, das die Challenge zum einmaligen Gebrauch bestimmt ist. Dann wäre es irrelevant, das der FF die Challenge mitsendet, und Caching würde genau das vom TO beschriebene Verhalten erzeugen - nur die allererste Anmeldung funktioniert, unabhängig davon, ob die Daten von Hand oder vom FF eingetragen werden.

Ich kann mir durchaus vorstellen, das auf dieser Seite keine automatische Anmeldung funktioniert.

Ich weiß zwar nicht genau, wie die Paßwortspeicherung beim FF funktioniert, aber ich vermute, das der Inhalt des Paßwort-Feldes nach dem Drücken des "Anmelden" Knopfes gelesen wird. Das wäre ein Problem. Zum einen würde sich der FF den Hash merken und nicht das Klartext-Paßwort, was allein schon zu einem Fehler führen würde. Zusätzlich fließt in den Hash, der generiert wird, eine sogenannte Challenge mit ein, ein Wert, der bei jedem Aufruf der Anmeldeseite anders ist. Damit ist auch jedesmal der Hash und somit das zum Server übertragene Paßwort anders.

Zitat von Seelenschnitter

... ich meinte damit, dass ein Login generell nicht möglich ist,...

Bedeutet das, du kannst dich nie anmelden, auch wenn du das Paßwort per Hand eingibst? In dem Fall: sitzt du vielleicht hinter einem Proxy, der die Anmeldeseite cached, obwohl er eigentlich nicht sollte?

Danke Wawuschel für das Bereitstellen von Testfällen. Wäre eigentlich Aufgabe des TO (und für ihn auch weniger aufwendig) gewesen, da er ja Links kennt, wo das "In the wild" passiert.

Konnte dadurch ein bischen rumspielen. Die Aussage "der IE macht das nicht" konnte ich zumindest für den IE7 nur zum Teil bestätigen. Die Leerzeichen werden zwar tatsächlich als solche gespeichert, die Umlaute jedoch ebenfalls als %E4, %F6, %FC etc. Umgekehrt konnte ich jedoch den FF dazu bringen, die Datei mit Leerzeichen und Umlauten zu speichern. Der Link mußte nur geringfügig geändert werden:

<a href="http://wawuschel.kilu.de/Katzenvadder/Firefox DE Software Lizenzvertrag %E4 %F6 %FC.zip">Firefox DE Software Lizenzvertrag ä ö ü.zip</a>

Es lieg also z.T. an den Seiten, wie gespeichert wird. Diese Form der Referenzierung habe ich auch im W3C Validator getestet, und sie wurde nicht angemeckert.

In Ermangelung einer älteren Version:

Was meinst du mit Navigationsleiste? Das mit diesen Links:
Privacy Policy | Contact Us | Site Map

Könnte an dieser Warnung des CSS-Validators liegen:

Zitat

.bannernav In (x)HTML+CSS, floated elements need to have a width declared. Only elements with an intrinsic width (html, img, input, textarea, select, or object) are not affected

Wenn du dieses Templates verwenden willst, teste erstmal mit den W3C Validatoren. Das Template ist nicht ganz sauber.

Nur zur Information (hat nichts mit dem Problem zu tun):

Zitat von Katzenvadder

Bei Ansicht / Zeichencodierung / Automatisch habe ich universell eingestellt.

Die Standardeinstellung ist "aus".

Zitat von Katzenvadder

Unverständlich ist mir dieses.
Bin ich auf der Seite, von der ich downloaden will, wird mir bei Zeichencodierung westlich (ISO 8859-1) angezeigt.
Bin ich hier im Forum zeigt mir der FF Unicode (UTF-8) an. :-???

Die eine Seite ist halt so kodiert, die andere so. Das war schon immer so, du hast nur nie darauf geachtet. IE wird dir vermutlich das gleiche verraten.

Da die Downloads, die ich mache, weder Leerzeichen noch Umlaute enthalten: Wie wär's mal mit 'nem Link zum Testen?

Klingt wie das hier:

http://www.firefox-browser.de/wiki/FAQ:%C3%8…%C3%BCbernommen

Zitat von Roger2009

... wenn ich mein MS Win Prof Version 2002 SP3 im abgesicherten Modus starte, zeigt Firefox (3.5.3) den gleichen Fehler wie vorher.

Sollte eine von boardraiders Fragen beantworten. Wirft aber gleichzeitig eine neue auf: Was zur Hölle ist Windows 2002??? Falls du Windows 2000 meinst - da ist seit Jahren schon SP4 aktuell, was bedeuten würde, du hättest nie Updates gemacht.

Sieht bei mir unter WinXP (Windows-Stil: Windows klassisch, Firefox default Theme), ohne jegliche Änderungen, so aus:[attachment=0]DB_Suche.jpg[/attachment]Die Schrift hängt zwar am untersten Rand, ist aber lesbar. Ich habe mal ein bischen gespielt, mit dem Windows-Theme ändert sich auch das Input-Feld entsprechend. Also hält sich der FF an Vorgaben des OS, das bedeutet für die Dresdner Bank, das sie noch einmal ran muß. Auf Einstellungen des OS hat der FF keinen Einfuß. Ob das FF-Theme auch Einfluß hat, kann ich mangels Themes nicht beurteilen.

Abgesehen davon, das dieses Pixel-orientierte Layout überholungsbedürftig ist, ist doch auffällig, das es Darstellungsunterschiede unter Windows (keine Probleme) und den *X Betriebssystemen gibt. Wäre also zu klären, ob das an Vorgaben des OS liegt oder an Unterschieden, mit denen die Versionen des FF für die verschiedenen OS ausgeliefert werden. Im letzteren Fall wäre es doch Aufgabe der Mozilla-Entwickler, für eine möglichst einheitliche Darstellung von Webseiten über die verschiedenen OS zu sorgen.

Also ich vermute eher ein Problem im Zusammenspiel von den von der Seite vorgegebenen Schriften mit dem auf dem Mac installierten Schriften als einen Bug im FF.

Zitat von boardraider

Wozu sich mehr Arbeit als nötig machen?

Weil die Methode fail-safe ist, und der TO schon Entities verwendet hat. Es ist für mich offensichtlich, das der TO nicht allzuviel von Zeichenkodierung versteht. Durch die Maskierung wird der Zeichenvorrat auf die Zeichen beschränkt, die in allen hier in D üblichen Zeichenkodierungen gleich sind. Dann spielt es keine Rolle mehr, in welcher Zeichenkodierung die Seite tatsächlich gespeichert ist, ob und wenn ja welche Angabe in den Meta-Tags steht, ob und wenn ja welche Angabe der HTTP-Header enthält. Natürlich nur auf die in D üblichen Zeichenkodierungen bezogen. Aber wem erzähle ich das, das weißt du selbst doch nur zu genau.

Zitat von boardraider

Es reicht, wie oben erwähnt, die Seite gemäß dem HTTP-Header in ISO-8859-1 zu speichern.

Richtig. Aber:
a) setzt das einen Editor voraus, der auch die Wahl der Zeichenkodierung zuläßt,
b) kann es immer noch zu Anzeigeproblemen bei einzelnen Usern kommen, wenn kein Meta Tag mit Angabe zur Zeichenkodierung enthalten ist, da der Weiterleitungsserver keine Zeichenkodierung im Http-Header angibt. Der Browser sollte dann zwar eigentlich zu ISO 8859-1 defaulten, aber das ist ja vom Anwender einstellbar. (Und ob sich der IE an die W3C-Vorgaben hält? :-?? )

Auch wenn ich mich wiederhole: Meine Empfehlung war nur auf diesen speziellen Fall bezogen und nicht allgemeiner Natur.

Zitat von .Ulli

Du bräuchtest nur den Tipp von boardraider umsetzen und den Firlefanz mit "Grüss" etc. brauchst du auch nicht.

Generell hat das hochgeschätzte Forumsmitglied .Ulli mit dieser Aussage recht. Doch wie der konkrete Falle hier liegt, schlage ich genau die umgekehrte Vorgehensweise vor. Entferne sämtliche Meta-Angaben des Typs http-equiv="Content-Type" aus den Dateien, ersetze sämtliche Umlaute und ß (und evtl. einige Sonderzeichen, welche siehst du ja dann beim Betrachten) durch die entsprechenden Entities, und gut ist's.

Zitat von boardraider

Das kann er durch das Ausgrauen der Checkbox dann nicht mehr. Ergo ist das Verständnis-Problem für den gemeinen User erst gar nicht existent.

Du kannst es drehen und wenden wie du willst - das Verständnisproblem bleibt, egal ob die Checkbox nicht macht was sie soll, ausgegraut ist oder gar komplett verschwunden. Stell dir doch einfach nur mal folgendes Szenario vor:

Normaluser klickt auf einen Link, hinter dem sich eine WMV-Datei verbirgt. Firefox fragt "Was willst du damit machen?" Der User sagt "Im Media Player öffnen" , und weil der Server content-distribution nicht übertragen hat - was er auch nicht muß - macht er ein ein Häkchen bei "immer diese Aktion ausführen". Nächste Webseite, wieder ein Link mit WMV, diesmal überträgt der Server "content-distribution: attachment". FF fragt also nochmal "Was willst du damit machen?" User kommt in's Grübeln "Hab ich doch schon festgelegt!?". Also nochmal festgelegt, und oh Schock, "immer diese Aktion ausführen" kann nicht gesetzt werden. Normaluser wird nachdenklich. Neue Seite, wieder ein Link mit WMV, content-distribution wird nicht übertragen, also spielt das WMV brav im Mediaplayer. Normaluser freut sich "Ah! War wohl ein einmaliger Ausrutscher." Doch, zu früh gefreut. Schon bei der nächsten Webseite, auf der er ein WMV ansehen will, wird er wieder mit derselben Frage genervt. Was macht er also? Testet die Seiten im IE. Und siehe da: Nach einmaliger Festlegung hält sich der IE an die User-Vorgabe. Damit ist der FF für Normaluser Geschichte.

Auf diese Weise werden FF-User vergrault. Und alles nur, weil die Mozilla Entwickler im FF einen Standard befolgen, den sie gar nicht befolgen müssen, für einen imaginären Sicherheitsgewinn. Wenn eine nicht erforderliche Funktion in Konflikt mit den User-Erwartungen steht, ist für mich die Lösung offenkundig: Die nicht erforderliche Funktion muß raus.

Man kann es drehen und wenden, wie man will: RFC 2138 wurde für Emails geschrieben und ist deshalb nicht 1:1 auf Webseiten übertragbar. Die User-Erwartungen an das Verhalten eines Email-Clients sind anders als die an einen Browser. Über das "Wie" die Anforderungen der RFC 2138 mit den User-Erwartungen in Übereinstimmung gebracht werden können wird ja anscheinend schon seit Jahren ohne Erfolg diskutiert. Was für eine Verschwendung.

Erinnern wir uns doch mal an die ursprüngliche Idee für den Firefox: ein schlanker (also ohne unnötige Funktionen!) schneller Browser, der sich mit Erweiterungen an die User-Wünsche anpassen läßt. Und nicht ein Browser mit unnötigen nervigen Funktionen, dem man die Flausen durch eine Erweiterung austreiben muß.

Zitat von boardraider

insbesondere weil das Klicken eines Links vorab den User nicht darüber informiert, welche Folgen dies hat. Die geforderte "bewusste Aktion" des Users ist hier eben nicht erfüllt.

Wenn der Nutzer für einen bestimmten MIME-Type eine Aktion festlegt und ein Häkchen macht bei "immer diese Aktion ausführen", dann macht er es bewußt und erwartet, das diese Funktion ausgeführt wird, wenn er einen entsprechenden Link anclickt. Er nimmt es in Kauf, das die Aktion bei jedem Link ausgeführt werden kann, den er anklickt. Außerdem kann das Link-Ziel in der Statusleiste gesehen werden. Und ich sehe nicht ein, warum es ein höheres Sicherheitsrisiko sein sollte, so eine "One Klick Action" bei einem Server zuzulassen der "Content-Disposition attachment" angibt, gegenüber einem Server, der das nicht angibt, insbesondere da es ja nicht Bestandteil von HTTP 1.1 ist und somit content-disposition überhaupt nicht übermittelt werden muß.

Zitat von boardraider

da ich keine Verletzung von Standards oder einen gravierenden Fehler sehe.

Es ist zwar kein festgeschriebener Standard, aber es herrscht allgemeine Übereinstimmung darüber, wenn ein Programm einem User eine bestimmte Aktion anbietet und der User sie wählt, das Programm die Aktion entweder ausführt oder aber mit einer Fehlermeldung reagiert. Alles andere wird allgemein als Fehler betrachtet. FF macht keins von beiden - hat also eindeutig einen Fehler - und erzeugt damit nur unnötige Verärgerung und Verwirrung bei den Nutzern.

Wobei ich selbst das Entfernen der Checkbox bei entsprechenden Downloads für fragwürdig halte. Zumindest ohne gleichzeitig zu informieren warum. Es ist für den durchschnittlichen Nutzer einfach nicht verständlich, warum er eine Aktion, die er doch schon festgelegt hat, immer wieder neu definieren muß und dann noch nicht einmal festlegen kann, das das immer so gemacht wird. Der weiß nichts von Http-headern, content-disposition etc. Und muß er auch gar nicht. Deshalb bin ich weiterhin der Meinung, Mozilla sollte seine Unterstützung der RFC 2138 durch ihren Browser noch einmal überdenken. Oder sie per wenigstens User-Einstellung abschaltbar machen.

Zitat von boardraider

Von "inline" ist nicht die Rede:

In dem RFC nicht, jedoch in den Kommentaren zum Bug.

Und wenn du schon RFC 2616 zitierst, dann bitteschön den entscheidenten Part
http://www.w3.org/Protocols/rfc2…15.html#sec15.5

Zitat

Content-Disposition is not part of the HTTP standard,but since it is widely implemented, we are documenting its use and risks for implementors.

Es handelt sich also nur um Empfehlungen, die man beachten kann, nicht aber zwingend beachten muß.

Obwohl ich also nach wie vor keine zwingende Relevanz für den FF sehe: auch wenn man RFC 2183 beachtet, geht daraus nur hervor, das als Attachment gekennzeichnete Teile einer Nachricht (Übertragen auf den FF:Webseite) nicht automatisch im Body (inline :wink: ) der Nachricht angezeigt werden dürfen, sondern eine weitere Aktion des Nutzers erforderlich ist. Und im Falle eines Links ist genau diese Forderung schon erfüllt. Der RFC erfordert keine Rückfrage nach dem Motto "Sie haben einen Link geklickt. Sind sie sicher, das sie die damit verbunden Aktion ausführen wollen?". Und nicht anderes ist es, wenn die Einstellung "immer diese Aktion ausführen" ignoriert wird. Denn das "immer ausführen" bedeutet ja nicht "automatisch ausführen", sondern nur dann ausführen, wenn der Nutzer auf einen entsprechenden Link klickt. Und auch der Hinweis (in den Kommentaren zum Bug) auf
http://www.w3.org/Protocols/rfc2….html#sec19.5.1

Zitat

If this header is used in a response with the application/octet- stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a `save response as...' dialog.

ist im Fall des TO (und vielen anderen auch) irrelevant, da der content-Type nicht application/octet- stream ist (hier: text/xml). Und im Fall application/octet- stream werden wohl auch die wenigsten darüber diskutieren, ob "Speichern unter..." die gewünschte Aktion ist.

Ich bleibe dabei: Die Beachtung der Standards in allen Ehren, aber das ist weit über das Ziel hinausgeschossen und somit ein Holzweg. Mit dieser Übererfüllung der RFC's, in Verbindung mit ihrer Uneinsichtigkeit, vergraulen die Entwickler unnötigerweise einen Teil der User, wie sich aus den Kommentaren erkennen läßt.

Was ist "Browsing Protection"? Wenn ich so etwas lese:

Zitat

Bei Magix-online.com habe ich ein online-album, wo ich immer bilder hochlade, das wurde aus sicherheitsgründen geperrt....???? hä.

dann wäre eine wie immer geartete "Browsing Protection" Verdachts-Kandidat Nr.1.

So nebenbei - Java solltest du aus Sicherheitsgründen auch aktualisieren. Wie es mit den anderen Plugins steht kann ich mangels Versionsangaben nicht beurteilen, bzw. entzieht sich im Falle des Adobe Reader meiner Kenntnis.

Bei der Diskussion um diesen Bug sind die Mozilla-Entwickler sowas von auf dem Holzweg. Der immer wieder angeführte RFC 2183 bezieht sich auf emails und mail user agents. Damit ist er für den FF irrelevant und betrifft nur TB und den Mail-Clienten von SM. Oder hab ich was verpasst und der FF ist doch ein Mailprogramm? Darf ich jetzt den Kommentar "Der FF ist kein Mailprogramm." nicht mehr anbringen, wenn die Fragen eines Posts offensichtlich auf ein Mailprogramm abzielen?

In einem der Kommentare zu dem Bug wurde auch darauf hingewiesen, das der RFC für den FF irrelevant ist, der Hinweis wurde aber von den Entwicklern ignoriert.

Und selbst wenn der RFC für den FF zutreffen würde - da es sich hier um anzuklickende Links handelt, ist die Hauptforderung des RFC - das der Inhalt nicht automatisch inline angezeigt werden darf, sondern erst eine Aktion der Nutzers erforderlich ist - schon erfüllt. Der Rest wäre kosmetischer Natur und verbietet keinesfalls, nach einem Klick des Nutzers auf das Attachment immer dieselbe Aktion auszuführen. Nur ohne Zutun des Nutzers darf diese Aktion nicht ablaufen. Was auch niemand gefordert hat. Aber wie schon gesagt - der RFC hat keine Relevanz für den FF, und er könnte die Angabe für "Content-Disposition" einfach ignorieren.

Zitat von migosel

Ich habe auf der gesamten Site keine Frames gesehen / gefunden.

Dann schau noch mal genauer hin. Und wie das halt bei Frames so ist - in der Adressleiste steht nur die Adresse des Framesets. Wie boardraider schrieb - untergeordnete Adressen sieht man nur in der Statusleiste.

Alternative ohne Frames(vermutlich hat sich migosel das angesehen): http://www.neukoelln-tv.de