在Chrome,火狐但不是在IE浏览器的AJAX调用的作品? [英] ajax call works in Chrome, Firefox but not in IE?

查看:144
本文介绍了在Chrome,火狐但不是在IE浏览器的AJAX调用的作品?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

下面code正常工作在Chrome,Firefox和科莫多龙。 I'ts即使是干净的Firefox的安装(证明我没有身份验证的FB或任何东西)。它不会在IE浏览器。铬,FF和龙都会导致一个有效的access_token警报。 IE浏览器导致拒绝访问。我试过GET和POST,都具有相同的结果。

The following code works fine in Chrome, Firefox and Komodo Dragon. I'ts even a clean install of firefox (proving I'm not authenticated to FB or anything). It does not work in IE. Chrome, FF and dragon all result in an alert with a valid access_token. IE results in "Access Denied". I've tried GET and POST, both have same results.

    function getWallPosts() {
        $.ajax({
            url: 'https://graph.facebook.com/oauth/access_token?client_id=<facebookid>&client_secret=<secretcode>&grant_type=client_credentials',
            type: 'POST',
            success: function (data) {
                alert(data)
            },
            error: function (a, b, c) {
                alert(a + ' ' + b + ' ' + c);
            }
        });
    };

编辑:附加信息*

我试图用XDomainRequest所建议的意见,但是我仍然收到访问被拒绝在IE浏览器而已。我相信这是为什么原因:

I tried using XDomainRequest as recommended in the comments, however I still receive Access Denied in IE only. I believe this is the reason why:

<一个href="http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx" rel="nofollow">http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx

要求必须有针对性,以相同的方案托管页

Requests must be targeted to the same scheme as the hosting page

这个限制意味着,如果你的AJAX页面是    http://example.com ,那么你的目标网址也必须以http。   同样,如果你的AJAX页面是 https://example.com ,那么你的   目标URL也必须以HTTPS。

This restriction means that if your AJAX page is at http://example.com, then your target URL must also begin with HTTP. Similarly, if your AJAX page is at https://example.com, then your target URL must also begin with HTTPS.

这肯定是我们的意图,以prevent HTTPS从制作网页   XDomainRequests为基于HTTP的资源,这种情况presents一个   混合内容安全威胁,许多开发者和大多数用户做   不明白。

It was definitely our intent to prevent HTTPS pages from making XDomainRequests for HTTP-based resources, as that scenario presents a Mixed Content Security Threat which many developers and most users do not understand.

不过,这种限制过于宽泛,因为它prevents HTTP   自发出针对HTTPS页面XDomainRequests页面。虽然这是   诚然,本身的HTTP页面可能已被破坏,没有   原因应当自收到公共资源禁止   牢固。

However, this restriction is overly broad, because it prevents HTTP pages from issuing XDomainRequests targeted to HTTPS pages. While it’s true that the HTTP page itself may have been compromised, there’s no reason that it should be forbidden from receiving public resources securely.

最糟糕的是,相同的方案限制意味着Web开发人员   测试自己的网页在本地使用file://方案就会发现,   所有的XDomainRequests被阻止,因为文件://不匹配   无论是http://或https://开头,这是唯一有效的目标计划   (点#1)。要解决此问题,网页开发人员必须承载其   本地Web服务器上的页面(如IIS,在Visual Studio托管   服务器,等等)。

Worst of all, the Same Scheme restriction means that web developers testing their pages locally using the file:// scheme will find that all of the XDomainRequests are blocked because file:// doesn’t match either http:// or https://, which are the only valid target schemes (point #1). To workaround this issue, web developers must host their pages on a local web server (e.g. IIS, the Visual Studio hosting server, etc).

要解决此限制,你可以建立一个   postMessage的-代理换XDR。

To workaround this limitation, you can build a postMessage-Proxy-for-XDR.

我已经提供托管服务包不包括任何SSL选项。没有任何人有任何其他的想法?

The hosting package I have been provided does not include any SSL options. Does anyone else have any other ideas?

推荐答案

答案是使Ajax调用服务器端的服务,然后让该服务使OAuth的电话。就我而言,我用了一个asp.net ASMX服务。它也可能是PHP或任何东西。这是现在的工作。

The answer was making the ajax call to a server-side service, then having that service make the OAuth call. In my case, I used an asp.net ASMX service. It could also be PHP or anything. This is now working.

这篇关于在Chrome,火狐但不是在IE浏览器的AJAX调用的作品?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆