次のコードは、Chrome、Firefox、および Komodo Dragon で正常に動作します。私はFirefoxのクリーンインストールさえしていません（FBなどに認証されていないことを証明しています）。IE では動作しません。Chrome、FF、およびドラゴンはすべて、有効な access_token でアラートを生成します。IE は「アクセスが拒否されました」という結果になります。GET と POST を試しましたが、どちらも同じ結果になりました。
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 でのみ Access Denied が表示されます。これが次の理由だと思います。
リクエストは、ホスティング ページと同じスキームをターゲットにする必要があります
この制限は、AJAX ページが http://example.comにある場合、ターゲット URL も HTTP で始まる必要があることを意味します。同様に、AJAX ページがhttps://example.comにある場合、ターゲット URL も HTTPS で始まる必要があります。
HTTPS ページが HTTP ベースのリソースに対して XDomainRequests を作成するのを防ぐことは、間違いなく私たちの意図でした。そのシナリオは、多くの開発者とほとんどのユーザーが理解していない混合コンテンツ セキュリティの脅威を提示するためです。
ただし、HTTP ページが HTTPS ページを対象とする XDomainRequests を発行することを防止するため、この制限は広すぎます。HTTP ページ自体が侵害された可能性があることは事実ですが、公開リソースを安全に受信することを禁止する理由はありません。
さらに悪いことに、同じスキームの制限は、file:// スキームを使用してローカルでページをテストする Web 開発者が、file:// が http:// にも https:/ にも一致しないため、すべての XDomainRequests がブロックされていることに気付くことを意味します。 /、これは唯一の有効なターゲット スキームです (ポイント #1)。この問題を回避するには、Web 開発者はローカル Web サーバー (IIS、Visual Studio ホスティング サーバーなど) でページをホストする必要があります。
この制限を回避するには、postMessage-Proxy-for-XDR を構築します。
提供されたホスティング パッケージには SSL オプションが含まれていません。他の誰かが他のアイデアを持っていますか？