Comment surmonter ce problème de sécurité

Question

J'ai mis en place un script de sondage ajax qui appelle une action dans le contrôleur du serveur toutes les 10 secondes. Avec la réponse, je remplace le contenu d'un fichier div :

function getFoo() {
    var link = '/Secure/GetFoo';

    $.post(link, function (response) {
        $('#FooSection').replaceWith(response);
    });

    setTimeout("getFoo();", 10000);
}

Cela se fait par https . Après un certain temps d'inactivité, IE affiche le message suivant :

Cette page accède à des informations qui ne sont pas sous son contrôle. Ce site pose un risque pour la sécurité. Souhaitez-vous continuer ?

Si l'utilisateur clique sur Oui la page est redirigée vers le site div en affichant uniquement la réponse. Si l'utilisateur clique sur Non rien ne se passe, mais le div ne sera pas rafraîchi.

Je sais. Je peux supprimer ce message grâce aux paramètres du navigateur mais cela m'amènera à un défaut. Oui comme dans la boîte de dialogue ci-dessus.

Une question similaire a été demandé avant mais malheureusement il n'y a pas eu de solution. Je veux essentiellement faire fonctionner mon sondage ajax même sur une sécurisé connexion. Vous avez des idées ?

Answer 1

Vous ne devriez jamais voir ce dialogue sur une page de l'Internet-Zone. Par défaut, cette opération est silencieusement et automatiquement bloquée dans la Zone Internet.

Il y a deux causes principales à l'apparition de ce dialogue dans la zone Intranet :

1> Tentative d'effectuer une requête d'origine croisée en utilisant l'objet XMLHTTPRequest (http://blogs.msdn.com/b/ieinternals/archive/2011/04/22/ie-security-prompt-page-accessing-cross-domain-information-not-under-its-control.aspx)

2> Tentative de navigation d'une balise OBJECT hébergeant du HTML vers une page d'origine croisée.

Vous pouvez éviter le cas n°1 en utilisant XDomainRequest au lieu de XMLHTTPRequest. Vous pouvez éviter le cas n° 2 en utilisant un IFRAME au lieu d'une balise OBJECT.

Answer 2

J'ai rencontré un problème similaire l'autre jour, étant incapable de trouver pourquoi IE se plaignait après une requête AJAX.

J'ai utilisé la console réseau de Firebug et j'ai parcouru les requêtes une par une jusqu'à ce que j'en trouve une qui était http:// au lieu de https://, je vous suggère de faire de même. Il nous sera pratiquement impossible de déboguer ce problème sans voir la page, mais il pourrait s'agir de quelque chose d'aussi simple qu'une image d'arrière-plan qui n'est pas chargée via https.

Nota: J'ai remarqué que vous avez dit que c'était IE, mais un problème comme celui-ci n'est probablement pas spécifique à un navigateur, Firefox/Chrome ne fait pas autant d'histoires qu'IE sur la présence d'éléments non https.

Answer 3

Il y a deux choses à propos de votre code :

Pourquoi utilisez-vous une requête POST ajax ? Pourquoi pas GET ? Votre demande ressemble à une demande GET (vous voulez obtenir des données), donc la méthode GET est probablement un meilleur choix.

Ce n'est pas lié à votre problème, mais vous ne devriez pas utiliser setTimeout avec une chaîne à évaluer. Vous devez donner à setTimeout une variable comme premier argument, et cette variable doit être la fonction que vous voulez exécuter.

function getFoo() {
    var link = '/Secure/GetFoo';

    $.get(link, function (response) {
        $('#FooSection').replaceWith(response);
    });

    window.setTimeout(getFoo, 10000);
}

Answer 4

Avez-vous essayé d'utiliser hyperliens relatifs au protocole ( //something.com/image.png ) ? Voir ce lien o celui-ci .

Answer 5

S'il y a ne serait-ce qu'un seul élément dont l'attribut src commence par "http" au lieu de "https" dans votre code, IE affichera ce message.

Êtes-vous sûr que les données que vous récupérez ne contiennent pas d'éléments dont l'attribut src="http:// ...". " dans leur attribut src ?