跨域问题解决方案：CORS

Access to XMLHttpRequest at '*' from origin '*' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.



从源'本地路径'访问 '目标路径(请求链接)'文本传输请求已被CORS策略阻塞:对预置请求的响应未通过访问控制检查:请求的资源上不存在'Access- control - allow - origin '报头。

错误原因：

本地路径和目标路径不是同一个域名下引起的跨域问题，并且，就算两个域名是同一个一级域名不同二级域名的时候，例如 a.baidu.com  和 b.baidu.com 是属于不同域的，也是会出现这个问题

介绍

出于安全原因，浏览器限制从脚本内发起的跨源HTTP请求。 例如，XMLHttpRequest和Fetch API遵循同源策略。 这意味着使用这些API的Web应用程序只能从加载应用程序的同一个域请求HTTP资源，除非响应报文包含了正确CORS响应头。

（注：这段描述不准确，并不一定是浏览器限制了发起跨站请求，也可能是跨站请求可以正常发起，但是返回结果被浏览器拦截了。）

CORS（跨源资源共享）是一个系统，由传输HTTP标头组成，用于确定浏览器是否阻止前端JavaScript代码访问跨源请求的响应

该同源安全政策禁止以资源跨域访问。但CORS使Web服务器能够表示他们希望选择允许跨资源访问其资源。

跨域资源共享(CORS) 是一种机制，它使用额外的 HTTP 头来告诉浏览器  让运行在一个 origin (domain) 上的Web应用被准许访问来自不同源服务器上的指定的资源。当一个资源从与该资源本身所在的服务器不同的域、协议或端口请求一个资源时，资源会发起一个跨域 HTTP 请求。

比如，站点 http://domain-a.com 的某 HTML 页面通过 <img> 的 src 请求 http://domain-b.com/image.jpg。网络上的许多页面都会加载来自不同域的CSS样式表，图像和脚本等资源。



跨域资源共享（ CORS ）机制允许 Web 应用服务器进行跨域访问控制，从而使跨域数据传输得以安全进行。现代浏览器支持在 API 容器中（例如 XMLHttpRequest 或 Fetch ）使用 CORS，以降低跨域 HTTP 请求所带来的风险。

 

解决方案：

1、如果跨域请求发生在相同一级域名不同二级域名之间

例如：a.baidu.com  和 b.baidu.com

跨域直接在邀请求的接口页面中强制设置域为一级域     document.domain = "baidu.com";

2、设置接口允许ajax跨域访问

在服务器aspx页面头文件里加：

<meta http-equiv="Access-Control-Allow-Origin" content="*" />

在web.config文件中的 system.webServer 节点下 增加如下配置

<system.webServer>  
    <httpProtocol> 
        <customHeaders> 
            <add name="Access-Control-Allow-Methods" value="OPTIONS,POST,GET"/> 
            <add name="Access-Control-Allow-Headers" value="x-requested-with"/> 
            <add name="Access-Control-Allow-Origin" value="*" /> 
        </customHeaders> 
    </httpProtocol> 
</system.webServer>


网上说的解决方案都是Internet Explorer 8 、9使用 XDomainRequest 对象实现CORS。是不是有这么复杂？于是博主各种百度寻找解决方案。最后发现在调用处指定 jQuery.support.cors = true; 这一句就能解决IE8、9的问题了

这句话的意思就是指定浏览器支持跨域。IE9以上版本的浏览器、谷歌、火狐等都默认支持跨域，而IE8、9却默认不支持跨域，需要我们指定一下。

//例如
jQuery.support.cors = true;
var ApiUrl = "http://b.baidu.com";
$(function () {
    $.ajax({
        type: "get",
        url: ApiUrl + "api/Charging/GetAllChargingData",
        data: {},
        success: function (data, status) {
            if (status == "success") {
                alert("ok");
            }
        },
        error: function (e) {
            alert("error");
        },
        complete: function () {

        }
    });
});

注：我这里设置的*是任意的请求都可以访问，如果需要限制替换成自己的访问地址就可以了。

参考资料：

 HTTP访问控制（CORS）   https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS

CORS（跨源资源共享）      https://developer.mozilla.org/en-US/docs/Glossary/CORS

 

 

你有困难我帮忙，我住隔壁我姓王。----------------- 你隔壁的老王宣。

$\operatorname{Blocked\ Billboard}$
题目链接：$\operatorname{nowcoder\ 24090}$ / $\operatorname{luogu\ P4122}$
题目

题目大意
就是有两个广告牌（它们不会重叠），然后又一个卡车，这个卡车可能会挡住一部分的广告牌。

然后问你你还能看到多少面积的广告牌。
给出了两个广告牌的大小与位置。
样例输入
1 2 3 5
6 0 10 4
2 1 8 3

样例输出
17

思路
这道题是一道数学题。
就先算出两个矩形的面积，然后再减去告示牌分别和它们相交的面积，就是答案。
相交的面积这么算：

设一个矩形的四个坐标分别为 $x_l,x_r,y_l,y_r$。

那相交的矩形就是 $max(x1_l,x2_l),min(x1_r, x2_r),max(y1_l,y2_l),min(y1_r,y2_r)$
代码
#include<cstdio>
#include<algorithm>

using namespace std;

int x1[3], y11[3], x2[3], y2[3];

int getsum(int now) {//算出一个矩形的面积
	return abs(x1[now] - x2[now]) * abs(y11[now] - y2[now]);
}

int meet(int x, int y) {//算出两个矩形相交的面积
	if (x1[x] >= x2[y] || x1[y] >= x2[x] || y11[x] >= y2[y] || y11[y] >= y2[x])
		return 0;//不相交
	
	return (min(x2[x], x2[y]) - max(x1[x], x1[y])) * (min(y2[x], y2[y]) - max(y11[x], y11[y]));
}

int main() {
	scanf("%d %d %d %d", &x1[0], &y11[0], &x2[0], &y2[0]);
	scanf("%d %d %d %d", &x1[1], &y11[1], &x2[1], &y2[1]);
	scanf("%d %d %d %d", &x1[2], &y11[2], &x2[2], &y2[2]);
	
	printf("%d", getsum(0) + getsum(1) - meet(0, 2) - meet(1, 2));
	
	return 0;
}

https://my.oschina.net/goldenshaw/blog/706663

BLOCKED 状态的定义

前面已经说过 BLOCKED(阻塞) 的简单定义为：

一个正在阻塞等待一个监视器锁的线程处于这一状态。(A thread that is blocked waiting for a monitor lock is in this state.)

更加详细的定义可以参考 Thread.State 中的 javadoc：

/**

         * Thread state for a thread blocked waiting for a monitor lock.

         * A thread in the blocked state is waiting for a monitor lock

         * to enter a synchronized block/method or

         * reenter a synchronized block/method after calling

         * {@link Object#wait() Object.wait}.

         */

        BLOCKED,

这句话很长，可以拆成两个简单句来理解。

A thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method。

一个处于 blocked 状态的线程正在等待一个监视器锁以进入一个同步的块或方法。

A thread in the blocked state is waiting for a monitor lock to reenter a synchronized block/method after calling Object.wait。

一个处于 blocked 状态的线程正在等待一个监视器锁，在其调用 Object.wait 方法之后，以再次进入一个同步的块或方法。

进入（enter）同步块时阻塞

先说第一句，这个比较好理解。

监视器锁用于同步访问，以达到多线程间的互斥。所以一旦一个线程获取锁进入同步块，在其出来之前，如果其它线程想进入，就会因为获取不到锁而阻塞在同步块之外，这时的状态就是 BLOCKED。

注：这一状态的进入及解除都不受我们控制，当锁可用时，线程即从阻塞状态中恢复。

我们可以用一些代码来演示这一过程：

@Test

public void testBlocked() throws Exception {

    class Counter {

        int counter;

        public synchronized void increase() {

            counter++;

            try {

                Thread.sleep(30000);

            } catch (InterruptedException e) {

                throw new RuntimeException(e);

            }

        }

    }

    

    Counter c = new Counter();

    

    Thread t1 = new Thread(new Runnable() {

        public void run() {

            c.increase();

        }

    }, "t1线程");

    t1.start();

    

    Thread t2 = new Thread(new Runnable() {

        public void run() {

            c.increase();

        }

    }, "t2线程");

    t2.start();

    

    Thread.sleep(100); // 确保 t2 run已经得到执行

    assertThat(t2.getState()).isEqualTo(Thread.State.BLOCKED);

}

以上定义了一个访问计数器 counter，有一个同步的 increase 方法。t1 线程先进入，然后在同步块里面睡觉，

导致锁迟迟无法释放，t2 尝试执行同步方法时就因无法获取锁而被阻塞了。

VisualVM 监控显示了 t2 线程的状态：



图上的“监视（monitor）”状态即为 BLOCKED 状态。可以看到在t1睡眠期间t2处于 BLOCKED 状态。

BLOCKED 状态可以视作是一种特殊的 WAITING，特指等待锁。

wait 之后重进入（reenter）同步块时阻塞

现在再次来看第二句：

2. A thread in the blocked state is waiting for a monitor lock to reenter a synchronized block/method after calling Object.wait。

一个处于 blocked 状态的线程正在等待一个监视器锁，在其调用 Object.wait 方法之后，以再次进入一个同步的块或方法。

这句话有点绕，也不好翻译成一句简洁的中文。如果没有对 wait 的相关背景有较好的理解，则不容易理解这句话。我们在此把它稍微展开讲一下。既然是 reenter，说明有两次 enter，这个过程是这样的：

调用 wait 方法必须在同步块中，即是要先获取锁并进入同步块，这是第一次 enter。

而调用 wait 之后则会释放该锁，并进入此锁的等待队列（wait set）中。

当收到其它线程的 notify 或 notifyAll 通知之后，等待线程并不能立即恢复执行，因为停止的地方是在同步块内，而锁已经释放了，所以它要重新获取锁才能再次进入（reenter）同步块，然后从上次 wait 的地方恢复执行。这是第二次 enter，所以叫 reenter。

但锁并不会优先给它，该线程还是要与其它线程去竞争锁，这一过程跟 enter 的过程其实是一样的，因此也可能因为锁已经被其它线程据有而导致 BLOCKED。

这一过程就是所谓的 reenter a synchronized block/method after calling Object.wait。

我们也用一段代码来演示这一过程：

@Test

public void testReenterBlocked() throws Exception {

    class Account {

        int amount = 100; // 账户初始100元

        public synchronized void deposit(int cash) { // 存钱

            amount += cash;

            notify();

            try {

                Thread.sleep(30000); // 通知后却暂时不退出

            } catch (InterruptedException e) {

                throw new RuntimeException(e);

            }

        }

        public synchronized void withdraw(int cash) { // 取钱

            while (cash > amount) {

                try {

                    wait();

                } catch (InterruptedException e) {

                    throw new RuntimeException(e);

                }

            }

            amount -= cash;

        }

    }

    Account account = new Account();

    

    Thread withdrawThread = new Thread(new Runnable() {

        public void run() {

            account.withdraw(200);

        }

    }, "取钱线程");

    withdrawThread.start();

    

    Thread.sleep(100); // 确保取钱线程已经得到执行

    

    assertThat(withdrawThread.getState()).isEqualTo(Thread.State.WAITING);

    

    Thread depositThread = new Thread(new Runnable() {

        public void run() {

            account.deposit(100);

        }

    }, "存钱线程");

    Thread.sleep(10000); // 让取钱线程等待一段时间

    depositThread.start();

    Thread.sleep(300); // 确保取钱线程已经被存钱线程所通知到

    assertThat(withdrawThread.getState()).isEqualTo(Thread.State.BLOCKED);

}

简要介绍一下以上代码场景：

有一个账户对象，有存钱（deposit）和取钱（withdraw）方法，初始金额100元。

取钱线程先启动，并进入（enter）同步块，试图取200元，发现钱不够，调用 wait，锁释放，线程挂起（WAITING 状态）。

10秒后存钱线程启动，存入钱并通知（notify）取钱线程，但之后继续在同步块中睡眠，导致锁没有释放。

取钱线程收到通知后，退出 WAITING 状态，但已经不持有锁，当试图重新进入（reenter）同步块以恢复执行时，因锁尚未被存钱线程释放，于是被阻塞（BLOCKED 状态）。

监控的显示：



如图，取钱线程先是 WAITING，在收到通知因无法获取锁而阻塞（BLOCKED）。

总结

综合来看这两句话，两层意思，其实还是一个意思，简单地讲，就是enter，reenter 也还是 enter，概括地讲：

当因为获取不到锁而无法进入同步块时，线程处于 BLOCKED 状态。如果有线程长时间处于 BLOCKED 状态，要考虑是否发生了死锁（deadlock）的状况。BLOCKED 状态可以视作为一种特殊的 waiting，是传统 waiting 状态的一个细分：

 

由于还没有讲到 WAITING 状态，而这里有涉及到了 wait 方法，所以上面对 wait 也稍微做了些分析，在下一章节，会更加详细的分析 WAITING 和 TIMED_WAITING 这两个状态。

一.问题描述
使用iframe通过iframe子页面调用父页面或父页面调用iframe子页面时，因为违反了浏览器安全策略，无法跨iframe获取到另一页面的数据，在控制台中可以看到如下报错

Blocked a frame with origin “http://localhost:****” from accessing a cross-origin frame.

二.解决方案
以上问题可通过postMessage方法安全地跨iframe进行通信。
1.iframe子页面调用父页面

子页面数据发送

// data为子页面发送的数据（可以是一个js对象，会被自动序列化处理）
window.parent.postMessage(data, '*')


父页面数据监听

addEventListener('message', e => {
    // e.data为子页面发送的数据
    console.log(e.data)
})


2.父页面调用iframe子页面

父页面数据发送

document.getElementById('iframe').contentWindow.postMessage(data,'*')


子页面接收数据

addEventListener('message', e => {
    // e.data为父页面发送的数据
    console.log(e.data)
})

3.安全性优化- 发送数据限制接收源
在上边的代码中postMessage的第二个参数被设置为’*’，意为任意源，这里可以指定接收源，示例代码如下
 window.parent.postMessage('exit','http://example.org');


监听到数据检测发送来源

addEventListener('message', e => {
    if(e.origin === 'http://example.org') {
        // 仅在数据发送来源自受信任的地址才执行对应操作
    }
})

END