在Chrome中跨域ajax POST [英] Cross domain ajax POST in chrome
问题描述
var myData = {datum1：datum，datum2：datum}
$ .post（http：// External-Ip：port，myData，函数（返回）{警报（返程）;}）;
当我试过这个（我开始寻找的原因）时，chrome-console告诉我：
XMLHttpRequest无法加载
HTTP：//外部-IP：端口/ page.php文件。 Origin
不允许通过Access-Control-Allow-
http：//myTestdomain.tld
Origin。
现在，据我所知，这是预期的。我不应该能够做到这一点。问题在于POST实际上是低谷。我有一个简单的脚本运行，它将 $ _ POST 保存到一个文件中，并且很明显帖子得到低谷。我返回的任何实际数据都没有传递给我的调用脚本，由于访问控制问题，我们的调用脚本再次出现。但事实上这个帖子真的到达服务器让我感到困惑。
$。post（）？
WebKit bugtracker之前，因为我认为这是奇怪的行为，可能还有安全风险。
来自Justin Schuh这里：
这完全按照规范的要求实现。对于简单的跨国请求http://www.w3.org/TR/cors/#simple-method>，不存在飞行前检查;如果适当的标题不授权请求源，则发出请求并且不能读取响应。在功能上，这与创建表单并使用脚本创建脱机POST（这一直是可能的）没有什么不同。
因此：您可以执行POST，因为您可以通过嵌入表单并使用JavaScript触发提交按钮来完成此操作，但是无法看到结果。因为在表单场景中你无法做到这一点。
解决方案是在目标服务器上运行的脚本中添加一个头文件， p>
<？php
header（Access-Control-Allow-Origin：http：// your_source_domain）;
....
？>
没有经过测试，但根据规范，这应该有效。
Firefox 3.6似乎以不同的方式处理它，首先执行OPTIONS以查看它是否可以执行实际的POST。 Firefox 4的功能与Chrome一样，或者至少在我的快速实验中做到了。更多信息请参见 https://developer.mozilla.org/en/http_access_control
There are several topics about the problem with cross-domain AJAX. I've been looking at these and the conclusion seems to be this:
Apart from using somthing like JSONP, or a proxy sollution, you should not be able to do a basic jquery $.post() to another domain
My test code looks something like this (running on "http://myTestdomain.tld/path/file.html")
var myData = {datum1 : "datum", datum2: "datum"}
$.post("http://External-Ip:port", myData,function(return){alert(return);});
When I tried this (the reason I started looking), chrome-console told me:
XMLHttpRequest cannot load http://External-IP:port/page.php. Origin http://myTestdomain.tld is not allowed by Access-Control-Allow-Origin.
Now this is, as far as I can tell, expected. I should not be able to do this. The problem is that the POST actually DOES come trough. I've got a simple script running that saves the $_POST to a file, and it is clear the post gets trough. Any real data I return is not delivered to my calling script, which again seems expected because of the Access-control issue. But the fact that the post actually arrived at the server got me confused.
- Is it correct that I assume that above code running on "myTestdomain" should not be able to do a simple
$.post()to the other domain (External-IP)? - Is it expected that the request would actually arrive at the external-ip's script, even though output is not received? or is this a bug. (I'm using Chrome 11.0.696.60 )
I posted a ticket about this on the WebKit bugtracker earlier, since I thought it was weird behaviour and possibly a security risk.
Since security-related tickets aren't publicly viewable, I'll quote the reply from Justin Schuh here:
This is implemented exactly as required by the spec. For simple cross-origin requests http://www.w3.org/TR/cors/#simple-method> there is no pre-flight check; the request is made and the response cannot be read if the appropriate headers do not authorize the requesting origin. Functionally, this is no different than creating a form and using script to make an off-origin POST (which has always been possible).
So: you're allowed to do the POST since you could have done that anyway by embedding a form and triggering the submit button with javascript, but you can't see the result. Because you wouldn't be able to do that in the form scenario.
A solution would be to add a header to the script running on the target server, e.g.
<?php
header("Access-Control-Allow-Origin: http://your_source_domain");
....
?>
Haven't tested that, but according to the spec, that should work.
Firefox 3.6 seems to handle it differently, by first doing an OPTIONS to see whether or not it can do the actual POST. Firefox 4 does the same thing Chrome does, or at least it did in my quick experiment. More about that is on https://developer.mozilla.org/en/http_access_control
这篇关于在Chrome中跨域ajax POST的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
