Mithilfe einer Log-Funktion möchte ich kurz eine nette Auto-Scroll-Funktion vorstellen.

Nehmen wir eine Funktion die Logging mit Javascript ermöglicht, indem in ein DIV der Inhalt hinzugefügt wird. Die Herausforderung: Jeder Log-Eintrag wird chronologisch unten angereiht. Daher sollte der Scrollbalken immer unten stehen. – Also muss ein Auto-Scroll-Mechanismus her:

function log(msg) {

    $("#log").append(msg).append("<br />")

        .scrollTop(document.getElementById("log").scrollHeight);

}

So einfach gehts

Viel Spass!

Die Herausforderung ist folgende: Man nehme eine Seite, welche per http-Authentication geschützt ist und diese Seite hat ein JQuery oder Javascript, welches mittels eines AJAX-Requests Daten aus einem weiteren Service holt, welcher Ebefalls der gleichen Authentifizierung unterliegt.

Beim Aufruf der Seite wird der Benutzer davon überzeugt, dass seine Zugangsdaten erforderlich sind:

Das ist auch  gut so, ABER sobald das weitere Daten mittels AJAX abgefragt werden, werden die Zugangsdaten erneut abgefragt – und zwar für den Service-Aufruf. Der Grund: der aktuell gültige Authentifizierungstoken im HTTP-Header wird nicht mitgegeben!

Hierzu ist es notwendig, dass beim Aufruf zusätzlich Username und Passwort mitgegeben werden:

Dann funktionierts auch mittels AJAX.

Doch….

• Doch woher Username und Passwort nehmen, wenn diese lediglich der Benutzer besitzt?
• Eine Alternative wäre das direkte Setzen des aktuellen Authentication Tokens:

doch auch hier beißt sich die Katze in den Schwanz, denn woher diesen nehmen?

• Es gibt per JS keine  Möglichkeit aktuelle HTTP-Header auszulesen. und dadurch den Authentication Token zu ermitteln.
• Die wie in http://coderseye.com/2007/how-to-do-http-basic-auth-in-ajax.html, oder in http://stackoverflow.com/questions/1002179/how-can-i-pass-windows-authentication-to-webservice-using-jquery vorgeschlagenen Methoden benötigen auch wieder Benutzername und Passwort und funktionieren daher auch nicht wie gewünscht.
• Das Durchreichen der aktuellen Logon-Informationen scheint auch nicht möglich zu sein.

Aus Security-Sicht ergibt es Sinn, dass dies nicht möglich ist, aus Usersicht jedoch ist diese Situation die sich daraus ergibt jedoch untragbar. Lösung: Keine :( – Das heißt: wir benötigen Cookie Based Authentication

Caching ist eigentlich etwas gutes, da dadurch die Ladezeit verringert werden kann. Doch wenn man per AJAX-Call Befehle absetzt und der Internet Explorer entscheidet dies nicht zu  tun, da er aufgrund seines aktuellen Caches glaubt, er wüsste das Ergebnis ohnehin schon ist dies nicht förderlich.

Warum ist das so?

• Im HTTP-Header sind keine Caching-Attribute gesetzt. Dadurch cached der IE

Was kann ich dagegen tun?

Im IE das Caching deaktivieren: Unter Extras –> Internet Optionen –> Browsing History –> Einstellungen sollte anstatt auf Automatisch lieber “Bei jedem Zugriff auf die Seite” eingestellt werden. Dadurch wird das Problem behoben.
 

Doch dies ist nur eine Lösung für die lokale Maschine! Etwas anderes muss her.

Angenommen wir können auf dem Server die Caching-Header nicht ändern (was durch Konfiguration im IIS, oder durch ASP, ASP.NET, PHP, etc. Befehle möglich, so existiert noch eine Konfiguration im JQuery, die das Caching für den AJAX-Aufruf deaktiviert:

Die Frage die ich mir dabei stelle: warum cached nur der IE und Firefox etc. nicht? Eigentlich wäre caching hier, vor allem da der Default-parameter beim Aufruf true ist, für jeden Browser legitim!

Naja. Cache:false ist auf jeden Fall die Lösung :-)