nicht angemeldet Felix Riesterer
Der Martin
molily
Felix Riesterer
molily
Felix Riesterer
molily
Liebe Spezialisten,
ich möchte mittels JavaScript prüfen, ob der Webserver einer anderen Domain eine gewisse Resource (HTML-Dokument) hat, oder nicht. Mir kommt es im Wesentlichen nur auf den HTTP-Statuscode an.
Beispiel: Mein JavaScript in einem Dokument auf example.org will prüfen, ob http://www.felix-riesterer.de/datei.html einen 404er ergibt, oder nicht, um im Bedarfsfalle eine andere Resource anzufordern.
Ich scheitere nach wie vor an der same-origin-policy, die ich im Grunde für ganz in Ordnung halte, jedoch in meinem Fall nicht so ganz einsehen will, warum eine solche Prüfmöglichkeit ein XSS-Sicherheitsloch wäre.
Mein erster Lösungsansatz war zuerst ein XHR, der prompt am Domainunterschied scheiterte. Daraufhin versuchte ich, über window.name diverse Informationen zwischen den Domains auszutauschen - auch hier blockiert der FF den Zugriff, wenn das Dokument von einer anderen Domain kommt. Zuletzt wollte ich mit new Image() die Resource anfordern, aber dabei feuert "onerror" jedes Mal, da mein HTML-Dokument natürlich nicht mit dem MIME-Typ für Bilder, sondern völlig zurecht mit "text/html" ausgeliefert wird.
Welche Möglichkeiten habe ich mit JavaScript alleine noch?
Liebe Grüße,
Felix Riesterer.
Hi Felix,
über dieses Problem haben schon viele gebrütet und ich habe auch noch nirgendwo eine Lösung gesehen, wenn es denn clientseitig sein muss.
Hier will es auch einer unbedingt lösen.
Gruss
Mike
Hello,
was ist denn, wenn Du ein Popup öffnest und darin die Ressource anforderst?
Das Ergebnis müsstest Du doch auswerten können. Das scheitert dann nur am vermutlich vorhandenen Popup-Blocker.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Lieber Tom,
was ist denn, wenn Du ein Popup öffnest und darin die Ressource anforderst?
was ist der Unterschied, ob ich ein XHR-Objekt, ein new Image(), ein Popup oder ein <iframe> benutze? Es kommt immer auf dasselbe hinaus. In dem Moment, wo ich von einer fremden Domain etwas mittels JavaScript wissen will, habe ich unüberwindliche Hürden, da mich der Browser das Dokument von der anderen Domain nicht anschauen lässt.
Ich glaube, das war der Ansatz der "XSS security issues", denn wenn dem nicht so wäre, dann könnte ein beliebiges Popup ausspähen, welche Session-ID ich bei meinem online-Banking habe, diese per simplem GET-Request an einen beliebigen Webserver weitergeben, wo dann ein Angreifer nur darauf wartet, mit meiner Session mein Konto abzuräumen.
Dabei will ich das Dokument doch überhaupt nicht "anschauen", ich will nur wissen, ob es existiert... oder kommt das auf dasselbe hinaus?
Wer kennt sich damit genauer aus?
Liebe Grüße,
Felix Riesterer.
Hello Felix,
Du hast Recht. Du kannst das Popup zwar aufrufen lassen mit der fremden URL aber dann nicht reingreifen. Das bildet dann quasi eine getrennte Instanzfamilie.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
dann kannst Du die Existenz nur z.B. per XMLHttpRequest durch Deinen Server im Hintergrund durchführen lassen. Das gibt dann weigstens Auskunft darüber, ob dein Server die Ressource erreichen kann, nicht ob Dein Client sie auch direkt erreichen könnte. Damit wärst Du also nur einen halben Schritt weiter.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Du hast Recht. Du kannst das Popup zwar aufrufen lassen mit der fremden URL aber dann nicht reingreifen. Das bildet dann quasi eine getrennte Instanzfamilie.
Nichts Instanzfamimilie. Das ist die 1996 eingeführte same origin policy. Du kannst mit JS nicht über Domaingrenzen hinweg zugreifen.
Struppi.
was ist der Unterschied, ob ich ein XHR-Objekt, ein new Image(), ein Popup oder ein <iframe> benutze? Es kommt immer auf dasselbe hinaus.
Von einem erfolgreich geladenen Image-Objekt kann man Höhe und Breite auslesen.
Mathias
Hallo Felix,
ich möchte mittels JavaScript prüfen, ob der Webserver einer anderen Domain eine gewisse Resource (HTML-Dokument) hat, oder nicht. Mir kommt es im Wesentlichen nur auf den HTTP-Statuscode an.
und warum muss es unbedingt Javascript sein? Die Theorie sagt, es geht wegen der SOP nicht; in der Praxis hast du das schon an einigen Beispielen bestätigt gefunden. Auch wenn es irgendwo ein Hintertürchen geben mag, glaube ich nicht, dass es ein offiziell dokumentiertes ist - und dann ist nur eine Frage der Zeit, bis deine Abfragemethode wieder auf die Klappe fällt.
Beispiel: Mein JavaScript in einem Dokument auf example.org will prüfen, ob http://www.felix-riesterer.de/datei.html einen 404er ergibt, oder nicht, um im Bedarfsfalle eine andere Resource anzufordern.
Ich würde diese Prüfung einem Script "in Auftrag geben", das auf example.org rumsitzt. Der clientseitige AJAX-Mechanismus kann ja im Prinzip derselbe bleiben, nur dass dein JS nicht direkt die gesuchte Ressource anfragt, sondern ein Script auf *seinem eigenen* Server beauftragt: "Sag mir, was du siehst ..."
Ich scheitere nach wie vor an der same-origin-policy, die ich im Grunde für ganz in Ordnung halte, jedoch in meinem Fall nicht so ganz einsehen will, warum eine solche Prüfmöglichkeit ein XSS-Sicherheitsloch wäre.
Ich gebe zu, die reine Prüfung auf Existenz bzw. Erreichbarkeit halte ich auch nicht für problematisch. Aber vielleicht übersehen wir einen Fall, in dem auch das schon ein Sicherheitsproblem sein könnte.
Zuletzt wollte ich mit new Image() die Resource anfordern, aber dabei feuert "onerror" jedes Mal, da mein HTML-Dokument natürlich nicht mit dem MIME-Typ für Bilder, sondern völlig zurecht mit "text/html" ausgeliefert wird.
Oops. An die Möglichkeit dachte ich auch noch, als ich deinen Beitrag las. An den falschen MIME-Typ habe ich dabei natürlich nicht gedacht. :-(
Welche Möglichkeiten habe ich mit JavaScript alleine noch?
Keine, fürchte ich.
So long,
Martin
Hello,
Ich gebe zu, die reine Prüfung auf Existenz bzw. Erreichbarkeit halte ich auch nicht für problematisch. Aber vielleicht übersehen wir einen Fall, in dem auch das schon ein Sicherheitsproblem sein könnte.
Ja, das ist das Albrecht-Tochter-Problem.
Wenn dieser Request möglich wäre, könnte man Dir Requests auf die hässlichsten Seiten im Web unterschieben, von denen Du gar nichts merkst.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Tach,
Wenn dieser Request möglich wäre, könnte man Dir Requests auf die hässlichsten Seiten im Web unterschieben, von denen Du gar nichts merkst.
wieso? Requests kann man doch problemlos unterschieben, man bekommt bloß keine Rückmeldung.
mfg
Woodfighter
Mein JavaScript in einem Dokument auf example.org will prüfen, ob http://www.felix-riesterer.de/datei.html einen 404er ergibt, oder nicht, um im Bedarfsfalle eine andere Resource anzufordern.
Wenn du Kontrolle über felix-riesterer.de hast, ist es doch kein Problem, dort ein Script bereitzustellen, dass diese Logik übernimmt. exists.php?file=datei.html&callback=bla gibt z.B. ein JavaScript mit bla(true) aus. Oder war das Beispiel gar nicht beispielhaft?
Was hast du genau vor?™
Mathias
Lieber Mathias,
Wenn du Kontrolle über felix-riesterer.de hast, ist es doch kein Problem, dort ein Script bereitzustellen, dass diese Logik übernimmt. exists.php?file=datei.html&callback=bla gibt z.B. ein JavaScript mit bla(true) aus. Oder war das Beispiel gar nicht beispielhaft?
ich wollte eine rein JavaScript-basierte Lösung - aber anscheinend ist das so nicht möglich. :-/
Was hast du genau vor?™
Ich möchte eine Dokumentation erstellen (Sammlung von HTML-Dokumenten), die einem Benutzer erklärt, wie er den TinyMCE innerhalb meines PG-CMS benutzen kann. Dabei wäre es sehr praktisch, wenn ich das "Hilfe-System" so einrichten könnte, dass alle Seiten der "offiziellen Doku" (existiert noch nicht) mitverwendet werden könnten, und dass nur die davon abweichenden, von mir auf mein CMS angepassten Seiten von meinem Webspace geladen werden. Der Enduser soll den Übergang von externen Seiten und "lokalen" Seiten natürlich nicht merken.
Mein Grundgedanke war:
1.) Alle Hyperlinks im aktuellen Dokument (per JavaScript) auf den eigenen Webspace umbiegen
2.) Nach Klick auf einen Link: Resource auf dem eigenen Webspace nicht verfügbar? -> auf entsprechende offizielle Doku-Seite weiterleiten
3.) Neue Seite: gehe zu 1.)
Offensichtlich ist mein Vorhaben nicht ohne serverseitige Unterstützung machbar. Für mich kommt da (nur) PHP in Frage. Aber ob man daraus dann einen offiziellen Plugin machen kann, wenn als server-seitige Technik (momentan) nur PHP unterstützt würde? Man kann die Prüfung auf Vorhandensein wohl kaum auf den Moxiecode-Server abschieben...
Liebe Grüße,
Felix Riesterer.
Hallo!
Entweder ich habe dich missverstanden oder du mich. ;)
Ich habs so verstanden:
Es gibt eine allgemeine TinyMCE-Doku und darin soll eine spezifische Doku für dein CMS drinstehen. Diese Dateien sind nicht mitgeliefert, sondern liegen auf deiner Domain. Deshalb ist die allgemeine Doku irgendwie lückenhaft, sodass du manche Links quasi on-the-fly auf deinen Webspace umbiegen willst. Richtig verstanden soweit?
Das kannst du natürlich auf Seite des Anwenders mit reinem JavaScript lösen - wenn du denn diese Dokumentation entsprechen anpassen kannst. Ich wüsste gar nicht, wo da jetzt Cross-Domain-Requests sind? Abfragen, ob auf der selben Domain eine bestimmte URI liegt. Wenn nicht, dann weiterleiten auf felix-riesterer.de/irgendwas. Oder willst du zusätzlich prüfen, ob die Datei auf felix-riesterer.de vorhanden ist?
1.) Alle Hyperlinks im aktuellen Dokument (per JavaScript) auf den eigenen Webspace umbiegen
Was ist mit eigenem Webspace gemeint? Deiner oder der des TinyMCE-Anwenders?
2.) Nach Klick auf einen Link: Resource auf dem eigenen Webspace nicht verfügbar? -> auf entsprechende offizielle Doku-Seite weiterleiten
Die offizielle Doku-Seite liegt auf welcher Domain?
Das hat mich nur mehr verwirrt...
Mathias
Lieber Mathias,
ich gebe zu, momentan gibt es ein paar verwirrende Fakten. Daher kläre ich das weiter auf.
Es gibt eine allgemeine TinyMCE-Doku und darin soll eine spezifische Doku für dein CMS drinstehen.
Nein, leider. Es gibt eben keine offizielle In-Editor-Hilfe-Doku. Das ist ein Manko von TinyMCE. In der 2er-Version gab es eine rudimentäre Hilfe, bei der im Wesentlichen die Buttons rudimentär erklärt wurden. In der 3er-Version ist das völlig entfallen.
Für mein CMS habe ich nun längst auf die 3er-Version umgestellt, habe aber über mein eigenes Plugin die Funktionalität der In-Editor-Hilfe-Doku beibehalten, da ich sie modifiziert und sehr stark erweitert hatte. Dadurch habe ich sie aber auch auf mein CMS maßgeschneidert.
Bei einer technischen Problemstellung habe ich einen der Entwickler mein CMS ausprobieren lassen. Er fand diese (z.T. sogar kontextsensitive) Hilfe im Editor gut und überlegte, inwiefern man soetwas wohl als offizielle Doku anbieten könnte - vielleicht sogar auf Wiki-Basis...
Hier nun setze ich an. Zu Testzwecken habe ich meinen privaten Webspace (felix-riesterer.de) mit einer "offiziellen" Doku angereichert, denn bei Moxiecode gibt es (noch) keine solche. Es gibt dort ein Wiki mit Seiten zur Konfiguration, einigen how-to Artikeln und einer recht anständigen Dokumentation zur API des TinyMCE.
Deshalb ist die allgemeine Doku irgendwie lückenhaft, sodass du manche Links quasi on-the-fly auf deinen Webspace umbiegen willst. Richtig verstanden soweit?
Das hast Du richtig verstanden. Meine Idee ist, dass die offizielle Doku eine Grundlage bildet. Sollte ein Entwickler für seine Editor-Implementation Seiten daraus für seine Zwecke modifiziert haben, so legt er diese (und nur diese!) in seinem Webspace innerhalb seiner TinyMCE-Installation ab, sodass diese anstelle der offiziellen Seiten angezeigt werden. Deshalb die Prüfung auf Vorhandensein.
Das kannst du natürlich auf Seite des Anwenders mit reinem JavaScript lösen - wenn du denn diese Dokumentation entsprechen anpassen kannst.
Soweit war ich schon. Der Transfer von der eigenen zur offiziellen Dokuseite ist kein Problem. Hier kann ich mit AJAX das Vorhandensein erfolgreich prüfen, um bei Nichtvorhandensein auf die entsprechende Seite der "offiziellen" Doku weiterzuleiten.
Ich wüsste gar nicht, wo da jetzt Cross-Domain-Requests sind? Abfragen, ob auf der selben Domain eine bestimmte URI liegt. Wenn nicht, dann weiterleiten auf felix-riesterer.de/irgendwas. Oder willst du zusätzlich prüfen, ob die Datei auf felix-riesterer.de vorhanden ist?
Nein, umgekehrt. Sagen wir, der User hat gerade eine von mir angepasste Dokuseite im Hilfefenster (<iframe>). Daraufhin klickt er einen Link zu einer weiteren Seite an, die ich nicht modifiziert habe, da die offizielle Hilfeseite an dieser Stelle mit meiner Editor-Implementierung zusammenpasst. Also existiert die Seite bei mir nicht, und der User müsste die entsprechende Seite aus der "offiziellen" Doku laden. Soweit auch kein Problem, da ja jede Seite, die nicht auf dem eigenen Webspace liegt, automatisch auf dem Server der offiziellen Doku liegen muss (oder der Entwickler hat einen "toten Link" in der Doku eingebaut).
Das echte XSS-Problem besteht nun darin, dass die Links auf der Seite der offiziellen Doku wieder zurück auf meinen Webspace führen müssen, damit weitere von mir eventuell modifizierten Seiten anstelle der offiziellen Version geladen werden können. Da aber das jeweilige Vorhandensein der Hilfeseiten auf dem eigenen Webspace aus einem offiziellen Dokument heraus wegen XSS nicht per XHR überprüft werden kann, landet der User im Zweifelsfalle auf einer 404er Fehlerseite (bei mir). Verbiegt man die Links dagegen nicht zurück zu mir, kommt der User aus der offiziellen Doku nicht mehr zu meinen angepassten Hilfeseiten zurück.
Es gäbe noch die Möglichkeit, ein Array mit URLs zu definieren, das per window.name oder so ähnlich an die offizielle Seite mitgegeben wird, sodass ein dortiges JavaScript das jeweilige Vorhandensein anhand dieser "Liste" ermitteln kann. Das wäre die einzige und zugleich unpraktischste Lösung, die mir als reine JavaScript-Lösung dazu einfällt.
Ist mein Vorhaben nun klarer geworden?
Liebe Grüße,
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
Hi Felix,
Ist mein Vorhaben nun klarer geworden?
ja und nein. Wenn ich dich richtig verstehe:
User klickt Doku
-> Soll erst mal bei dir landen
-> wenn unvollständig dann -> offizelle Doku
<- und zurück zu dir sobald du wieder etwas für Ihn hast was er auf
der offiziellen Doku anklickt
Richtig soweit?
kann ich mir eigentlich nicht vorstellen, weil dann wäre die Lösung ja zu einfach.
Mike
Lieber Mike,
User klickt Doku
-> Soll erst mal bei dir landen
-> wenn unvollständig dann -> offizelle Doku
<- und zurück zu dir sobald du wieder etwas für Ihn hast was er auf
der offiziellen Doku anklicktRichtig soweit?
genau.
kann ich mir eigentlich nicht vorstellen, weil dann wäre die Lösung ja zu einfach.
Wie meinen? "zu einfach"? Kläre mich auf! Wie würdest Du das rein mit JavaScript angehen?
Liebe Grüße,
Felix Riesterer.
Hi Felix,
»» kann ich mir eigentlich nicht vorstellen, weil dann wäre die Lösung ja zu einfach.
Wie meinen? "zu einfach"? Kläre mich auf! Wie würdest Du das rein mit JavaScript angehen?
rein mit JS nur von Clientseite. Deine Doku wird aufgerufen, kommt der entsprechende Punkt, den deine Doku nicht bereit hält, "NICHT" zur offiziellen(obwohl es die ja gar nicht gibt?) Doku verweisen, stattdessen auf deinem Server nachladen und Linktechnisch parsen, so bleibt der User auf deiner Seite.
Genau so löse ich das mit einer Wikipedia. Eine Anfrage kommt, wenn ich den Wikiartikel noch nicht habe, lade ich das per PHP nach und somit ist es dann auch meiner Seite verfügbar.
Aber wie gesagt, kann mir eigentlich nicht vorstellen, dass du das so gemeint hast, denn da wärst du selbst drauf gekommen, etwas verwirrend.
Mike
Lieber Mike,
Eine Anfrage kommt, wenn ich den Wikiartikel noch nicht habe, lade ich das per PHP nach und somit ist es dann auch meiner Seite verfügbar.
ich wollte doch eine reine JavaScript-Lösung...
Liebe Grüße,
Felix Riesterer.
Das echte XSS-Problem besteht nun darin, dass die Links auf der Seite der offiziellen Doku wieder zurück auf meinen Webspace führen müssen
Ich sehe da ein ganz anderes Problem: Wie soll das gehen?
Ich dachte, auf die offizielle Doku hast du gar keinen Zugriff und die liegt auf anderen Domains, nämlich dort, wo der jemand TinyMCE benutzt?
Wie soll die zurück zu dir verweisen - sie weiß doch gar nicht, dass der Benutzer von dir auf sie kam. Oder woher kann sie es wissen?
Da aber das jeweilige Vorhandensein der Hilfeseiten auf dem eigenen Webspace aus einem offiziellen Dokument heraus wegen XSS nicht per XHR überprüft werden kann
Wie sollte das auch gehen? Indem sich die offizielle Doku den ursprünglichen Referrer merkt?
Es gäbe noch die Möglichkeit, ein Array mit URLs zu definieren, das per window.name oder so ähnlich an die offizielle Seite mitgegeben wird, sodass ein dortiges JavaScript das jeweilige Vorhandensein anhand dieser "Liste" ermitteln kann. Das wäre die einzige und zugleich unpraktischste Lösung, die mir als reine JavaScript-Lösung dazu einfällt.
Ich finde die überhaupt nicht unpraktisch - viel praktischer und geradliniger als ständig irgendwie Cross-Domain-Requests zu machen.
Ist mein Vorhaben nun klarer geworden?
Ehrlich gesagt nein.
Vielleicht abstrahierst du dein Problem noch einmal, die ganzen Details führen uns vom Kernproblem eher weg.
Mathias
Lieber Mathias,
Vielleicht abstrahierst du dein Problem noch einmal, die ganzen Details führen uns vom Kernproblem eher weg.
OK. Ich abstrahiere das noch einmal:
Ich möchte per JavaScript testen, ob unter einer URL, die auf eine andere Domain verweist, eine Resource verfügbar ist, oder nicht. Als Ergebnis würde mir bereits ein entsprechender HTTP-Statuscode genügen, da ich den Inhalt der Ressource selbst nicht verwerten möchte. Ich will ja nur wissen, ob sie vorhanden ist. Wenn ich in JavaScript z.B. einen HTTP HEAD request senden könnte, um dann auszuwerten, ob eine 200 zurück kommt, würde das meinen Anforderungen völlig genügen.
Beispiel: http://example.com/test.html will per JavaScript wissen, ob http://example.org/test2.html existiert.
Liebe Grüße,
Felix Riesterer.
Hallo,
Beispiel: Mein JavaScript in einem Dokument auf example.org will prüfen, ob http://www.felix-riesterer.de/datei.html einen 404er ergibt, oder nicht, um im Bedarfsfalle eine andere Resource anzufordern.
Ich scheitere nach wie vor an der same-origin-policy, die ich im Grunde für ganz in Ordnung halte, jedoch in meinem Fall nicht so ganz einsehen will, warum eine solche Prüfmöglichkeit ein XSS-Sicherheitsloch wäre.
Die gilt manchmal auch nicht, z.B. beim Einbinden von Scripts (script tag hack).
aber dabei feuert "onerror" jedes Mal, da mein HTML-Dokument natürlich nicht mit dem MIME-Typ für Bilder, sondern völlig zurecht mit "text/html" ausgeliefert wird.
onerror ist doch ganz ok. Du musst nur die Art des Fehlers abfragen. "Error loading script" bedeuetet, dass die Ressource nicht vohanden ist (404 oder so), jeder andere Fehler (z.B. "Script Error") bedeuet, dass sie vorhanden ist.
Gruß, Don P
Hallo,
"Error loading script" bedeuetet, dass die Ressource nicht vohanden ist (404 oder so), jeder andere Fehler (z.B. "Script Error") bedeuet, dass sie vorhanden ist.
Funktioniert leider nur im FF. Opera und IE feuern anscheinend keinen onerror, trotz Fehler :-(
Gruß, Don P
Hallo,
Struppi
var RessourceTester = function(timeout)
{
this.timeout = timeout;
this.url = function(url, cb)
{
var timeout;
var im = document.createElement('object');
im.style.height = im.style.width = '1px';
im.onload = function(e)
{
try
{
im.parentNode.removeChild(im);
} catch(e) { ; };
window.clearTimeout(timeout);
cb(url, true);
};
im.data = url;
if (this.timeout)
{
timeout = window.setTimeout(function()
{
try
{
im.parentNode.removeChild(im);
} catch(e) { ; };
cb(url, false);
}, this.timeout * 1000);
};
document.body.appendChild(im);
};
};
var cb = function(url, available)
{
(window.console.warn || alert)(url + ' is ' + available);
};
var testor = new RessourceTester(10);
testor.url('http://www.google.de/', cb);
testor.url('http://example.com', cb);
testor.url('http://www.google.de/asdf', cb);
testor.url('http://www.example.lol', cb);
firefox, opera und der battarie machens alle brav.
Tschö
Liebe(r) asdf,
[...code...]
das schaue ich mir auf jeden Fall einmal an. Vielen Dank!
firefox, opera und der battarie machens alle brav.
Aha... und der IE? Hast Du den nur nicht getestet, oder verweigert der?
Liebe Grüße,
Felix Riesterer.
Hi,
firefox, opera und der battarie machens alle brav.
Aha... und der IE? Hast Du den nur nicht getestet, oder verweigert der?
Kennst du einen Browser, der "battarie" heisst?
MfG ChrisB
Vielleicht solltest du erklären, was dieser Code macht und was seine Anwendungsfälle sind. Er fügt ein object ins Dokument ein und wartet 10 Sekunden auf das load-Event. Wenn das load-Event in der Zeit feuert, wird ein Callback aufgerufen. Wenn nach Ablauf der Wartezeit kein load-Event gefeuert hat, wird der Callback aufgerufen, nur mit einer anderen.
Das ganze arbeitet also stark asynchron. Ich fürchte, das ist für Felix' Zwecke nicht geeignet. Links on-the-fly umleiten lassen sich damit nicht, schließlich muss man von einer entsprechend großen Verzögerung bis zum load-Event ausgehen. 10 Sekunden sind bei einer langsamen Seite mit Bildern und Scripten eher untertrieben. Wenn ich auf einen Link klicke, will ich aber nicht die Ziel-Seite erst mit JavaScript asynchron vorladen und ggf. 10 Sekunden warten, bis irgendetwas passiert.
Übrigens kann man im IE und kommenden HTML-5-konformen Browsern das error-Ereignis verwenden, was aus dem Timeout-Problem ein wenig die Schärfe nimmt. Zuletzt kann man über Cross-Site-XMLHttpRequest nachdenken, was bereits von einigen Browsern unterstützt wird. Dazu muss es die beteiligte Domain natürlich erlauben.
Mathias