Django跨域请求原理及CORS实现详解

不晚

发布时间：2026-10-14 | 2人浏览过

原创

本文深入解析浏览器同源策略对跨域请求的限制，详解CORS（跨域资源共享）的工作机制。通过对比简单请求与非简单请求（预检请求）的差异，展示如何在Django项目中通过视图响应头或中间件配置Access-Control-Allow-Origin等字段，实现安全的跨域通信。

同源策略与跨域限制

一、同源策略

同源策略（Same origin policy）是浏览器最核心且基本的安全约定，旨在保护用户数据安全。若缺失该策略，浏览器的正常功能可能受到严重影响。Web架构正是建立在同源策略的基础之上，而浏览器则是这一策略的具体实现者。

跨域请求的URL地址必须与当前浏览器地址处于同一域，即域名、端口和协议三者必须完全一致。

例如，若本地域名设置为127.0.0.1:8000，而试图请求另一个域名127.0.0.1:8001的数据，浏览器将执行同源策略检查。

此时浏览器会报错，这正是同源策略在起作用。如果浏览器不对JavaScript实施同源策略保护，重要机密网站将面临巨大的安全风险。

常见的错误提示为：“已拦截跨源请求：同源策略禁止读取位于 http://127.0.0.1:8001/SendAjax/ 的远程资源。（原因：CORS 头缺少 'Access-Control-Allow-Origin'）”。

需要注意的是，虽然浏览器报错，但项目2中的访问请求实际上已经发生。这表明浏览器是对非同源请求返回的结果进行了拦截，而非阻止请求本身的发送。

CORS跨域资源共享机制

二、CORS（跨域资源共享）简介

CORS需要浏览器和服务端同时支持。目前主流浏览器均支持该功能，IE浏览器版本需不低于IE10。

整个CORS通信过程由浏览器自动完成，无需用户参与。对开发者而言，CORS通信与同源AJAX通信在代码层面没有区别。浏览器一旦发现AJAX请求跨源，会自动添加附加的头信息，有时还会额外发起一次请求，但用户通常无感知。

因此，实现CORS通信的关键在于服务器。只要服务器实现了CORS接口规范，即可支持跨源通信。

CORS请求流程分类

三、CORS基本流程

浏览器将CORS请求分为两类：简单请求（simple request）和非简单请求（not-so-simple request）。
对于CORS简单请求，浏览器仅需在请求头信息中增加一个Origin字段。
对于CORS非简单请求，在正式通信之前，浏览器会先增加一次HTTP查询请求，称为“预检”请求（preflight）。浏览器首先询问服务器，当前网页所在的域名是否在服务器的许可名单中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则将报错。

简单请求与非简单请求详解

四、CORS两种请求详解

若同时满足以下两个条件，则属于简单请求。

（1）请求方法是以下三种方法之一：

HEAD
GET
POST

（2）HTTP的头信息不超出以下几种字段：

Accept
Accept-Language
Content-Language
Last-Event-ID

Content-Type：仅限制为三个值：application/x-www-form-urlencoded、multipart/form-data、text/plain

Django跨域实战示例

接下来创建两个Django项目进行演示：简单请求场景，涉及get方法及application/x-www-form-urlencoded类型。

mysite1项目运行在127.0.0.0:8008（该端口向8006端口发送简单请求）。

views.py文件内容如下：


from django.shortcuts import render
# Create your views here.
def test(request):
  return render(request,'index.html')

template/index.html文件内容如下：


<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <script src="/static/jquery-3.3.1.js"></script>
  <title>Title</title>
</head>
<body>
<button id="mybutton">点我</button>
</body>
<script>

  $("#mybutton").click(function () {
    $.ajax({
      url:'http://127.0.0.1:8006/mytest',  #向该ip端口发送一个get的简单请求
      type:'get',
      success:function (data) {
        console.log(data)
      }
    })
  })
</script>
</html>

mysite2项目运行在127.0.0.0:8006。

views.py文件内容如下：


def mytest(request):
  import json
  print('111')
  obj = HttpResponse(json.dumps({'name': 'lqz'}))
  # if request.method=='OPTIONS':
  #   obj['Access-Control-Allow-Methods']='PUT'
  #   obj['Access-Control-Allow-Headers']='k1'
  #
  #
  # # obj['Access-Control-Allow-Origin']='http://127.0.0.1:8008'
  # obj['Access-Control-Allow-Origin']='*'
  return obj

由于同源策略的限制，浏览器阻止了数据返回（实际上数据已从服务器成功请求回来，只是被浏览器因同源策略阻止了接收）。

凡是不同时满足上述两个条件的请求，均属于非简单请求。

浏览器对这两种请求的处理方式存在差异。

* 简单请求与非简单请求的区别？

简单请求：仅发起一次请求。

非简单请求：发起两次请求。在发送实际数据前，先发送一次请求用于“预检”，只有预检通过后才发送第二次请求用于数据传输。

* 关于“预检”的详细说明

- 请求方式：OPTIONS

- “预检”实质上是进行检查，若通过则允许传输数据，若不通过则不再发送真正的消息。

- 如何进行“预检”？

=> 如果复杂请求使用PUT等动词，服务端需设置允许该请求方式，否则“预检”不通过。

Access-Control-Request-Method

=> 如果复杂请求设置了自定义请求头，服务端需设置允许该请求头，否则“预检”不通过。

Access-Control-Request-Headers

支持跨域，针对简单请求：

服务器设置响应头：Access-Control-Allow-Origin = '域名' 或 '*'。

支持跨域，针对复杂请求：

由于复杂请求首先会发送“预检”请求，若预检成功，则发送真实数据。

“预检”请求时，若需允许特定请求方式，服务器需设置响应头：Access-Control-Request-Method。
“预检”请求时，若需允许特定请求头，服务器需设置响应头：Access-Control-Request-Headers。

Django中实现CORS配置

五、Django项目中支持CORS

在返回结果中加入允许信息（适用于简单请求）。


def test(request):
  import json
  obj=HttpResponse(json.dumps({'name':'lqz'}))
  # obj['Access-Control-Allow-Origin']='*'
  obj['Access-Control-Allow-Origin']='http://127.0.0.1:8004'
  return obj

将CORS处理逻辑放入中间件，以同时处理复杂和简单请求。


from django.utils.deprecation import MiddlewareMixin
class CorsMiddleWare(MiddlewareMixin):
  def process_response(self,request,response):
    if request.method=="OPTIONS":
      #不能加*
      response["Access-Control-Allow-Headers"]="Content-Type"
    response["Access-Control-Allow-Origin"] = "http://localhost:8080"
    return response

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持本站。