【从零开始搭建自己的.NET Core Api框架】(五)由浅入深详解CORS跨域机制并快速实现

系列目录

.  创建项目并集成swagger

  1.1 创建

  1.2 完善

二. 搭建项目整体架构

三. 集成轻量级ORM框架——SqlSugar

  3.1 搭建环境

  3.2 实战篇:利用SqlSugar快速实现CRUD

  3.3 生成实体类

四. 集成JWT授权验证

五. 实现CORS跨域

 


 源码下载:https://github.com/WangRui321/RayPI_V2.0

(新增的跨域部分的代码还没有更新上去,但一共就只有15行代码,需要的完全可以自己编写。等晚上有时间再去git更新下,地址不变~)

  1. 根

先从一个最最根本的问题开始,我们为什么要“跨域”?

答案很简单,用一句话就可以概括:跨域的唯一目的,就是要绕过“同源策略”的限制。

 1.1 同源策略

根据百度百科:
同源策略(Same origin policy)是一种约定,它是浏览器最核心也最基本的安全功能,如果缺少了同源策略,则浏览器的正常功能可能都会受到影响。可以说整个Web都是构建在同源策略基础之上的,浏览器只是针对同源策略的一种实现。
同源策略是由Netscape提出的一个著名的安全策略,所谓同源是指协议、域名、端口相同。现在所有支持JavaScript的浏览器都会使用这个策略。

可以看出,同源策略是一种Web安全策略,它限制了一个域内发起的请求只能访问它所处当前域内的资源,而不能访问其他域内的资源。比如,有两个网站,A和B,在同源策略下,网站A的js就不可以访问网站B的资源(比如接口)。

与其说我们“运用”同源策略,不如说是我们“遵守”同源策略。就像交通规则一样,它虽然限制了每个人的自由,但同时也保证了每个人的相对安全。

 1.1.1 怎么判断两个资源是否同源?

判断是否同源有三个要素,我们暂且称它们为“同源三要素”:

1)协议

比如http(超文本传输协议)或https(安全套接字层超文本传输协议)。如果协议不同,则一定不同源。

2)域名

比如www.cnblogs.com。如果域名不同,则一定不同源。

3)端口

比如www.raywang.com:8080和www.raywang:8081,它们一个为8080端口,一个为8081端口,所以它们不同源。

 

如果两个资源时同源的,那么它们必须同时满足这个条件都相同。举几个例子:

https://www.raywang.com与http://www.raywang.com不同源,因为它们协议不同。

https://www.raywang.com与http://www.baidu.com不同源,因为它们域名不同。

https://www.raywang.com:8080与https://www.raywang.com:8081不同源,因为它们端口不同。

 1.1.2 我们为什么要跨域?

以api设计模式开发的系统,前端页面和后端接口一般都是分离了。在开发初期,后端接口可能被发布到某台服务器上,而前端页面可能被搭建在开发人员本地的iis中,就算是项目上线后,页可能是前端页面和后台服务发布到两台不同的服务器上。当然,这些情况都是不符合同源策略的。

拿我们正在搭建的web api为例,我这里写了一个测试用的小网页,代码如下:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title></title>
    <script src="js/jquery-2.1.4.js"></script>
    <script>
        function GetToken() {
            var tokenModel = {
                id: $("#tid").val(),
                name: $("#tname").val(),
                sub: $("#tsub").val()
            };
            $.ajax({
                url: "http://localhost:3607/api/System/Token",
                type: "get",
                dataType: "json",
                data: tokenModel,
                async: false,
                success: function (d) {
                    alert(JSON.stringify(d));
                    $("#jwt").val(d);
                },
                error: function (d) {
                    alert(JSON.stringify(d));
                    $("#jwt").val(JSON.stringify(d));
                }
            });
        }
        function GetStudent() {
            var s = { name: $("#sname").val() };
            $.ajax({
                url: "http://localhost:3607/api/Client/Student/GetByName",
                type: "get",
                dataType: "json",
                data: s,
                async: false,
                headers: { "Authorization": "Bearer " + $("#jwt").val().trim() },
                success: function (d) {
                    alert(JSON.stringify(d));
                    $("#student").val(JSON.stringify(d));
                },
                error: function (d) {
                    alert(JSON.stringify(d));
                    $("#student").val(JSON.stringify(d));
                }
            });
        }
    </script>
</head>
<body>
    <div style="width:350px; margin:100px auto 0;">
        I  D:<input type="text" id="tid" value="1" /><br />
        Name:<input type="text" id="tname" value="张三" /><br />
        Sub :<input type="text" id="tsub" value="Client" /><br />
        <input type="button" value="获取Token" onclick="GetToken()" /><br />
        <br />
        <p>token:</p>
        <textarea id="jwt" style="width:300px; height:200px; "></textarea>
        <br />
        学生姓名:<input type="text" id="sname" value="张三" /> <input type="button" value="点击查询" onclick="GetStudent()" />
        <br />
        <textarea id="student" style="width:300px;height:200px;"></textarea>
    </div>
</body>
</html>
View Code

 

我把它放到RayPI下的wwwroot下,

 

运行之后,浏览器访问是这样的:

 

其中“获取Token”按钮会调用接口http://localhost:3607/api/System/Token,“点击查询”按钮会调用接口http://localhost:3607/api/Client/Student/GetByName,结果如下:

 

此时,页面http://localhost:3607/index.html和接口http://localhost:3607/api/System/Token,http://localhost:3607/api/Client/Student/GetByName是同源的(因为同在一个项目中),所以它们之间可以互相访问传递资源(json),没有任何问题。

下面我们将这个网页单独拿出来发布到我本地的iis中,域名取为http://localhost:8083/index.html

 

点击按钮,结果如下

显然,此时这个前端页面与后端接口是非同源的,所以它不能访问接口资源。

 1.2 跨域的解决方案

解决跨域的方法很多,比如运用代理跨域,window.name+iframe跨域。

但是最常用的跨域方式应该是两种:JSONPCORS跨域。

RayPI选择的跨域方式是后者。

 1.3 CORS跨域

CORS,即Cross-Origin Resource Sharing,跨源资源共享。

 3.3.1 跨域请求的类型

CORS将跨域请求分成以下两种:

  • 简单请求
  • 复杂请求

一个简单的请求大致满足如下条件:

  • HTTP方法是下列之一
    • HEAD
    • GET
    • POST
  • HTTP头包含
    • Accept
    • Accept-Language
    • Content-Language
    • Last-Event-ID
    • Content-Type,但仅能是下列之一
      • application/x-www-form-urlencoded
      • multipart/form-data
      • text/plain

任何一个不满足上述要求的请求,即被认为是复杂请求。

 

 3.3.2 一次CORS跨域的完整流程

一个完整的CORS跨域请求的流程是这样的:

 

先别慌,图片看着多,其实是三块内容,我们把它分为左、中、右三部分,从最左边开始看起。

 

1)左:基础

一个http请求被发起之后,浏览器会根据是否是跨域请求(判断标准就是上面说的同源策略三要素),决定是否在http请求的头部添加“Origin”字段,并将发起请求的域名附加在该字段后面。

服务器接收到客服端的http请求后,会先尝试读取“Origin”字段,如果不存在,说明该请求不是跨域请求,直接将该请求放行,把结果返回给客户端;

如果头部存在“Origin”字段,说明该请求来自和当前服务器不同源的一个客户端,是一个跨域请求。这时先判断该“Origin”字段后的域名和请求方式(request method)是否合法,如果不合法,就直接返回403错误码。如果是合法的,再根据上面说的原则判断该请求是简单请求还是复杂请求。如果是简单请求,就进入图片中间简单请求流程,如果是复杂请求,就进入图片最右边复杂请求流程。

 2)中:简单请求

服务器端根据自己设置的CORS跨域规则,配置相应的Access-Control-Allow-Origin和Access-Control-Allow-Methods等响应头信息。

当收到客户端的请求后,服务端将验证客户端请求头中的信息是否符合设置的CORS规则,如果符合,则将请求的资源连同跨域响应头(Access-Control-Allow-Origin等)返回给客户端。
客服端(浏览器)收到Response Headers后,会验证这些响应头信息,判断是否通过了跨域请求,如果通过,则返回状态码200,并成功获取到跨域资源:

 

如果服务端收到客户端的请求后,发现客户端请求头中的信息不符合设置的CORS规则,这时则不会讲配置的跨域响应头(Access-Control-Allow-Origin等)返回给客户端。

客户端收到Response Headers后,验证跨域响应头信息,没有发现相应的跨域响应头,说明跨域请求不通过,将不会返回资源。(这里理论上应该返回错误码403的,但是Chrome显示的是200状态码,我也不知道是为啥。。。)

 

可以通过浏览器的Console查看具体的验证失败原因:

 

3)右:复杂请求

一个复杂请求不仅有包含通信内容的请求,同时也包含预请求(preflight request)。

浏览器发现是复杂请求的时候,并不会直接发起原请求,而是先发送Preflight requests(预先验证请求),Preflight requests是一个OPTION请求,用于询问服务器是否允许当前域名下的页面发起跨域请求。

如下例,点击“点击查询”后,需要向接口传递token验证(接口的授权验证是前一章讲的内容),所该请求是一个复杂跨域请求。如下图:

 

OPTIONS请求头部中一般会包含以下头部:Origin、Access-Control-Request-Method、Access-Control-Request-Headers。
服务器收到OPTIONS请求后,设置Access-Control-Allow-Origin、Access-Control-Allow-Method、Access-Control-Allow-Headers头部与浏览器沟通来判断是否允许这个请求。
如果Preflight requests验证通过,浏览器才会发送真正的跨域请求。

 

如果Preflight requests验证失败,浏览器则不会发送真正的跨域请求。(理论上应该返回403错误码,但是这里还是返了200。。。)

 

 

可以通过浏览器的Console查看具体的验证失败原因:

 

  2. 道

原理了然,下面就开始实现了。

方法有两个,程序实现和服务器实现。

 2.1 程序实现

打开主项目下的Startup.cs文件,编辑ConfigureServices函数

代码如下:

            #region CORS
            services.AddCors(c =>
            {
                c.AddPolicy("AllowAnyOrigin", policy =>
                 {
                     policy.AllowAnyOrigin()//允许任何源
                     .AllowAnyMethod()//允许任何方式
                     .AllowAnyHeader()//允许任何头
                     .AllowCredentials();//允许cookie
                 });
                c.AddPolicy("AllowSpecificOrigin", policy =>
                 {
                     policy.WithOrigins("http://localhost:8083")
                     .WithMethods("GET", "POST", "PUT", "DELETE")
                     .WithHeaders("authorization");
                 });
            });
            #endregion

这里添加了两个策略,AllowAnyOrigin策略几乎直接完全无视了“同源策略”的限制,所以个人建议尽量不要这么写。AllowSpecificOrigin策略我暂时只放了一个测试用的源,如有需要可根据情况更改。

 下面只需要在控制器头上(或某个函数头上)添加标识:

[EnableCors("AllowSpecificOrigin")]

 

 2.2 服务器实现

这里我用的IIS作为例子,方法如下:

在iis新建网站,添加RayPI,点击IIS下的“HTTP响应标头”

 

右侧店家添加,依次添加如下表头信息:

Access-Control-Allow-Origin : * 

Access-Control-Allow-Methods : GET,POST,PUT,DELETE,HEAD,OPTIONS

Access-Control-Allow-Headers : authorization

 

  3. 果

F5运行程序,从http://localhost:8083/进行测试,结果如下

 

跨域访问成功~

 

参考内容:

https://blog.csdn.net/u014344668/article/details/54948546

https://blog.csdn.net/badboyer/article/details/51261083

posted @ 2018-07-11 13:33 在7楼 阅读(...) 评论(...) 编辑 收藏