为啥在xmlHttpRequest的open方法中使用参数true，却还是否异步啊？

Posted 2023-04-19

在我在xmlHttpRequest的open方法中使用参数true，却还不是异步啊？

//javascript

var logid= <?php echo $NoLog ?>;
var url="a.php?logid="+logid;

xmlHttp.open("GET",url,true);
xmlHttp.send(null);

location.href='b.php';

//a.php

去数据库取相关数据，然后发email

mail($mailTo,$subject,$text,$header);

--------------
可是执行的过程完全不是异步，异步不是应该页面立刻转到b.php，同时send mail吗？但是我这里却是send 完mail后，在转到b.php,像同步那样。我的代码不对吗？第一次写ajax，请指点。
很奇怪，我这段代码单独运行是好的，完全可以达到我想要的异步效果，但是我要是把那段javascript放在一个php文件里，就不行，就是同步了，为什么啊？

继续调试，加上
xmlHttp.onreadystatechange=funciotn()

if(xmlHttp.readyState==2)

location.href="b.php";



第一次在ie下运行，好的，是异步处理，紧接着在FF下测试，不行了，变同步了，之后再在ie下测试，也不行了。。。。。。

晕阿。。

参考技术A xmlHttp.onreadystatechange=function(data)

if(xmlHttp.readyState==4)

mail($mailTo,$subject,$text,$header); location.href='b.php';


xmlHttp.open("GET",url,true);
xmlHttp.send(null); 参考技术B xmlHttp.onreadystatechange=function(data)

if(xmlHttp.readyState==4)

mail($mailTo,$subject,$text,$header); location.href='b.php';


xmlHttp.open("GET",url,true);
xmlHttp.send(null);

为啥 XMLHttpRequest 的同源策略

【中文标题】为啥 XMLHttpRequest 的同源策略

【英文标题】：Why same origin policy for XMLHttpRequest为什么 XMLHttpRequest 的同源策略

【发布时间】：2010-12-22 06:01:03

【问题描述】：

为什么浏览器对 XMLHttpRequest 应用同源策略？这对开发人员来说真的很不方便，但它似乎在真正阻止黑客方面几乎没有什么作用。 有一些变通方法，它们仍然可以包含来自外部来源的 javascript（JSONP 背后的力量）。

在很大程度上相互关联的网络中，这似乎是一个过时的“功能”。

【问题讨论】：

这是一个有趣的话题。您的主张/主张有任何来源吗？我有兴趣了解更多详情。

只是个人经验。我提出这个问题是为了确认他们（或知道我错了）

查看 ***.com/a/26819187/895245 了解 SOP 的简单示例

【参考方案1】：

因为 XMLHttpRequest 传递了用户的身份验证令牌。如果用户使用基本身份验证或某些 cookie 登录到 example.com，然后访问了攻击者.com，则后一个站点可以创建一个 XMLHttpRequest 到 example.com 并对该用户具有完全授权并读取用户可以读取的任何私有页面（然后转发给攻击者）。

因为在 webapp 页面中放置秘密令牌是阻止简单的跨站点请求伪造攻击的方法，这意味着攻击者.com 可以在未经任何同意或交互的情况下在 example.com 上执行用户可以在 example.com 上执行的任何页面操作他们。全局 XMLHttpRequest 是全局跨站点脚本。

（即使您有一个未通过身份验证的 XMLHttpRequest 版本，仍然存在问题。例如，攻击者可以向您的 Intranet 上的其他非公共机器发出请求并读取它可以从中下载的任何文件这可能不适合公众消费。<script> 标签已经遭受这种漏洞的有限形式，但是 XMLHttpRequest 的完全可读响应会泄漏各种文件，而不是一些可以解析的不幸制作的文件作为 JavaScript。）

【讨论】：

第一个很容易修复，只是不要将基本的身份验证和cookie信息与请求一起发送到其他域。内网问题不能通过服务器端检查referer header来解决，还是XHR不发送？

Referrer 检查不是一种安全机制，除了防止水蛭外，绝不能用于其他任何事情。在任何情况下，某些实现允许Referer 标头由脚本设置为任何内容（以及许多其他任意标头）。

但它就在这里。如果浏览器总是会发送referer 头并且服务器会检查它，那么XSS 攻击是不可能的。我在这里谈论的是一个理想的未来，因此不会有可以删除引用标头的实现。

Referer 标头经常被阻止或根本没有被代理转发。您还需要Vary: Referer，这会使缓存不满意。今天不应该依赖它，当然也不应该用它来构建新的安全系统。

它被称为“起源”。它以及允许安全跨站点请求的相关标准正在准备中，但要完全标准化并准备好使用还需要很长时间。有关该领域的工作，请参阅 w3.org/TR/XMLHttpRequest2。