2010-11-26 13 views
2

Unser Service läuft über HTTPS und wir experimentieren derzeit mit dem Ausführen einer kompilierten GWT-Anwendung, nur Client-Seite, keine RPC: s.GWT Anwendung generiert IE unsicheres Element Warnung

Es ist in einem IFRAME enthalten, der empfohlen wird (hier zum Beispiel: http://developerlife.com/tutorials/?p=231 unter der Überschrift HTTPS und HTTP).

Bei bestimmten Operationen innerhalb der GWT-App generiert der IE eine unsichere Element-Warnung.

http://bagonca.com/insecure_item.png

Sie können sich fragen, warum ich nicht einige nette Firefox-Plugin verwenden, um zu sehen, welche Anforderung über HTTP sein könnte. Oder warum ich HTTPWatch nicht in Internet Explorer aus dem gleichen Grund verwende. Ich habe. Es gibt keine unsicheren Anfragen, die ich irgendwo finden kann.

Was ich andererseits gelesen habe, ist, dass Internet Explorer diese Warnung für iframes ohne das src Attribut setzt. Und dass ein potenzieller Fix src = "javascript: false" für jeden Iframe verwendet, der dynamisch ausgefüllt wird.

Wie ich schon sagte, die gesamte App ist über ein IFRAME enthalten, und in diesem erzeugt GWT selbst ein verstecktes IFRAME, das wie folgt aussieht.

<iframe tabIndex="-1" id="gwt-app" src="javascript:''" style="border-bottom: medium none; position: absolute; border-left: medium none; width: 0px; height: 0px; border-top: medium none; border-right: medium none;"> 

Ich habe versucht, harte Kodierung das Attribut src oben auf eine leere Seite, die tatsächlich existiert und heißt mit HTTPS auf der gleichen Domäne. Ich habe das Javascript versucht: falsch; Ansatz. Kein Glück. Die App funktioniert wie ein Zauber, aber IE wirft die nutzlose und falsche Warnung.

Die Warnung erscheint, wenn ich bestimmte Aktionen innerhalb der App, nicht wenn es geladen ist. Eigentlich beim Ziehen und Ablegen von Terminen innerhalb der http://code.google.com/p/gwt-calendar/ Komponente.

Hat sich schon mal jemand mit einem ähnlichen Problem herumgeschlagen? Irgendwelche Hinweise?

Antwort

2

Dort andere Schnipsel von Javascript, die auch ein Problem verursachen können. Bitte beachten Sie:

http://blog.httpwatch.com/2009/09/17/even-more-problems-with-the-ie-8-mixed-content-warning/

auch, einen Blick durch den Stapel von Kommentaren auf:

http://blog.httpwatch.com/2009/04/23/fixing-the-ie-8-warning-do-you-want-to-view-only-the-webpage-content-that-was-delivered-securely/

Einige der Kommentatoren haben gefunden und behoben andere Ursachen für die Warnung zu.

+0

Danke sooo viel! Danke an einen Kommentar zum ersten Blog-Artikel, den du gepostet hast, wenn du das gefunden hast: http://www.pelagodesign.com/blog/2007/10/30/ie7-removechild-and-ssl/. Wir sind in eine Situation geraten, in der GWT das CSS-Attribut background-image auf url (null) gesetzt hat; und IE war ein trauriger Panda. –

+0

Auch ein großes Lob an Sie HttpWatch, dass Sie aktiv nach Menschen suchen, denen Sie helfen könnten. –

2

Irgendwelche Hinweise?

Ich bin mir nicht sicher in diesem Fall, aber ich habe einige Experimente mit iframes (zu einem ähnlichen Thema) vor etwa einem Jahr. Ich würde annehmen, dass der gwt-Kalender versucht, über javasciptts parent Referenz mit der Host-Seite zu kommunizieren. AFAIR, das ist nicht erlaubt, wenn die Host-Seite nicht vom selben Ursprung (einschließlich Protokoll) geladen wird.

+0

Vielen Dank für Ihre Antwort. Sie befinden sich in Ihrer Annahme richtig, dass wir einige Dinge tun, die über die Elternreferenz kommunizieren. Ich werde am Montag nachsehen und Sie wissen lassen, ob wir in dieser Ausgabe Klarheit schaffen. –

0

Dies kann passieren, wenn Sie Ihre Anwendung über HTTPS ausgeführt haben und Abrufen von Bildern oder eine andere Ressource über über Ebene HTTP. Überprüfen Sie, ob Bild- oder CSS-Pfade auf http: // fest codiert sind.

Zum Beispiel, wenn Ihre Anwendung, wenn bei https://example.com ausgeführt wird und Sie wünschen foo.jpg ein Bild zu laden, wird die HTML Sie sollten mit ist:

<img src="https://example.com/images/foo.jpg"/> 

oder (im Idealfall)

<img src="images/foo.jpg"/> 

und nicht

<img src="http://example.com/images/foo.jpg"/> 

N Beachten Sie, dass das dritte Beispiel das Bild foo.jpg über http anstelle von https holt. Daher würde es das Problem verursachen, mit dem Sie konfrontiert sind.

Um solche Probleme zu vermeiden, empfiehlt es sich, entweder und relative URLs zu verwenden.

+0

Sie können auch '// 2.example.com/images/foo.jpg' verwenden, wenn Sie auf einen anderen Server verweisen müssen, aber das gleiche Protokoll verwenden möchten. –

+0

Ja, unser Team ist sich dessen bewusst. Wir haben dreifach sichergestellt, dass es solche Vorkommnisse nicht gibt. Dies ist definitiv ein anderer Mechanismus im IE, der die Warnung verursacht. –