How to overcome this security issue

Question

I have implemented an ajax-polling script that calls an action in the server Controller every 10 seconds. With the response, I replace the content of a div:

Answer 1

You should never see that dialog on an Internet-Zone page. By default, this operation is silently and automatically blocked in the Internet Zone.

There are two root causes for that dialog to appear in the Intranet zone:

1> Attempting to do a cross-origin request using the XMLHTTPRequest object (http://blogs.msdn.com/b/ieinternals/archive/2011/04/22/ie-security-prompt-page-accessing-cross-domain-information-not-under-its-control.aspx)

2> Attempting to navigate an OBJECT Tag hosting HTML to a cross origin page.

You can avoid case #1 by using XDomainRequest instead of XMLHTTPRequest. You can avoid case #2 by using an IFRAME instead of an OBJECT tag.

Answer 2

Have you tried using protocol-relative hyperlinks (//something.com/image.png)? See this link or this one.

Answer 3

There's two things about your code :

Why do you use a POST ajax request ? why not GET ? Your request looks like a GET request (you want to get some data), so the GET method is probably a better choice.

It's not linked to your problem, but you should not use setTimeout with a string to eval. You should give setTimeout a variable as the first argument, and this variable should be the function you want to execute.

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

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

    window.setTimeout(getFoo, 10000);
}

Answer 4

Did you try using absolute url?

var link = 'https://www.yourdomain.com/Secure/GetFoo';

Answer 5

I ran into a similar problem the other day, being unable to find out why IE would complain after an AJAX request.

I used Firebug's net console and just went through the requests one by one till i found one that was http:// instead of https://, i suggest you do the same - It'll be allmost impossible for us to debug this without seeing the page, but it could be something as little as a background image not being loaded via https.

Note: I did notice you saying it was IE, but a problem like this would probably not be browser-specific, Firefox/Chrome just doesn't make the same fuss about there being non https elements as IE does.

Answer 6

I've seen this happen before because the new content being inserted via the ajax call had links to none secure image assets, any chance this is the problem you are seeing?