zoukankan      html  css  js  c++  java
  • django-cors-headers

    django-cors-headers介绍

    一个Django应用程序,向响应头中添加跨域资源共享(CORS)头。这允许从其他来源向Django应用程序发出浏览器内请求,当然也可以自定义中间件然后添加响应头信息。

    关于cors问题可点击此处

    安装

    pip install django-cors-headers
    

    注册到settings.py中的应用中

    INSTALLED_APPS  =  [ 
        ... 
        'corsheaders' ,
        ... 
    ]
    

    添加一个中间件类来监听响应

    MIDDLEWARE  =  [   # 或Django <1.10上的MIDDLEWARE_CLASSES 
        ... 
        'corsheaders.middleware.CorsMiddleware' ,
        'django.middleware.common.CommonMiddleware' ,
        ... 
    ]
    

    应将Corsmidlware放置在尽可能高的位置,尤其是要放在能够生成响应的中间件之前,比如Django的CommonMiddleware或Whitenoise middleware。如果不是放在这些响应中间件之前,它可能无法将CORS头添加到这些响应中。

    另外,如果您使用CORS_REPLACE_HTTPS_REFERER,它应该放在Django的CsrfViewMiddleware之前。

    配置

    在Django设置中配置中间件的行为。您必须将允许进行跨站点请求的主机添加到 CORS_ORIGIN_WHITELIST,或将CORS_ORIGIN_ALLOW_ALL设置为True 以允许所有主机。

    CORS_ORIGIN_ALLOW_ALL

    如果为True,将不使用白名单,并且将接受所有来源。默认为False

    CORS_ORIGIN_WHITELIST

    授权进行跨站点HTTP请求的来源列表。默认为[]

    CORS_ORIGIN_WHITELIST  =  [ 
        'https://example.com' ,
        'https://sub.example.com' ,
        'http:// localhost:8080' ,
        'http://127.0.0.1:9000'
    ]
    

    CORS_ORIGIN_REGEX_WHITELIST

    代表正则表达式的字符串列表,这些正则表达式与被授权发出跨站点HTTP请求的Origins相匹配。默认为[]。当 CORS_ORIGIN_WHITELIST不切实际时(例如您拥有大量子域时)很有用。

    CORS_ORIGIN_REGEX_WHITELIST  =  [ 
        r “ ^ https://  w +  .example  .com $” ,
    ]
    

    以下参数是可选的。

    CORS_URLS_REGEX

    一个正则表达式,用于限制将发送CORS标头的URL。默认为r'^。* $',即匹配所有URL。当您仅在网站的一部分上需要CORS时很有用,例如/ api /处的API

    CORS_URLS_REGEX  =  r '^ / api /.*$'
    

    CORS_ALLOW_METHODS

    实际请求所允许的请求方式列表。默认为:

    CORS_ALLOW_METHODS  =  [ 
        'DELETE' ,
        'GET' ,
        'OPTIONS' ,
        'PATCH' ,
        'POST' ,
        'PUT' ,
    ]
    

    可以将默认值导入为corsheaders.defaults.default_methods,因此您可以使用自定义方法对其进行扩展。这使您可以随时了解最新更改。例如:

    from corsheaders.defaults import default_methods
    
    CORS_ALLOW_METHODS = list(default_methods) + [
        'POKE',
    ]
    

    CORS_ALLOW_HEADERS

    发出实际请求时可以使用的非标准HTTP标头的列表。默认为:

    CORS_ALLOW_HEADERS = [
        'accept',
        'accept-encoding',
        'authorization',
        'content-type',
        'dnt',
        'origin',
        'user-agent',
        'x-csrftoken',
        'x-requested-with',
    ]
    

    可以将默认值导入为corsheaders.defaults.default_headers,以便您可以使用自定义标头对其进行扩展。这使您可以随时了解最新更改。例如:

    from corsheaders.defaults import default_headers
    
    CORS_ALLOW_HEADERS = list(default_headers) + [
        'my-custom-header',
    ]
    

    CORS_EXPOSE_HEADERS

    The list of HTTP headers that are to be exposed to the browser. Defaults to [].

    CORS_PREFLIGHT_MAX_AGE

    客户端/浏览器可以缓存预检响应的秒数。 如果该值为0(或任何错误值),则不会发送最大期限标头。 默认为86400(一天)。

    注意:预检请求是在发出“复杂请求”(例如Content-Type不是application / x-www-form-urlencoded)时提出的额外请求,用于确定服务器实际接受的请求。

    CORS_ALLOW_CREDENTIALS

    如果为True,则将允许将cookie包含在跨站点HTTP请求中。默认为False

    注意:在Django 2.1中,添加了SESSION_COOKIE_SAMESITE设置,默认情况下设置为 Lax,这将防止Django的会话Cookie跨域发送。将其更改为‘ None ’可绕过此安全限制。

    CSRF集成

    大多数站点将需要利用Django提供的跨站点请求伪造保护。CORS和CSRF是分开的,并且Django无法使用您的CORS配置免除“ Referer ”中的网站,以检查它是否处理了安全请求。做到这一点的方法是使用其CSRF_TRUSTED_ORIGINS设置。例如:

    CORS_ORIGIN_WHITELIST = [
        'http://read.only.com',
        'http://change.allowed.com',
    ]
    
    CSRF_TRUSTED_ORIGINS = [
        'change.allowed.com',
    ]
    

    CORS_REPLACE_HTTPS_REFERER

    CSRF_TRUSTED_ORIGINS是Django 1.9中引入的,因此早期版本的用户将需要替代解决方案。如果CORS_REPLACE_HTTPS_REFERERTrue,则只要CORS检查通过,CorsMiddleware就会将Referer标头更改为将通过Django的CSRF检查的内容。默认为 False

    请注意,与CSRF_TRUSTED_ORIGINS不同,此设置不允许您区分CORS 信任读取资源的域和避免CSRF保护而信任更改资源的域。

    启用此功能后,您还应该在MIDDLEWARE_CLASSES中的django.middleware.csrf.CsrfViewMiddleware之后添加corsheaders.middleware.CorsPostCsrfMiddleware来撤消Referer

    MIDDLEWARE_CLASSES  =  [ 
        ... 
        'corsheaders.middleware.CorsMiddleware' ,
        ... 
        'django.middleware.csrf.CsrfViewMiddleware' ,
        'corsheaders.middleware.CorsPostCsrfMiddleware' ,
        ... 
    ]
    

    Signals

    如果您的用例需要的不仅仅是上述配置,那么您可以附加代码来检查是否应该允许给定的请求。例如,这可用于读取模型允许的来源列表。将任意数量的处理程序附加到启用check_request_enabled的Django信号上,该信号提供request参数(在处理程序中使用** kwargs防止将来添加任何参数)。如果附加到信号的任何处理程序返回truthy值,则将允许该请求。

    例如,您可以定义如下处理程序:

    # myapp/handlers.py
    from corsheaders.signals import check_request_enabled
    
    from myapp.models import MySite
    
    def cors_allow_mysites(sender, request, **kwargs):
    	return MySite.objects.filter(host=request.host).exists()
    
    check_request_enabled.connect(cors_allow_mysites)
    

    然后在应用就绪时使用Django AppConfig连接它:

    # myapp/__init__.py
    
    default_app_config = 'myapp.apps.MyAppConfig'
    
    # myapp/apps.py
    
    from django.apps import AppConfig
    
    class MyAppConfig(AppConfig):
        name = 'myapp'
    
        def ready(self):
            # Makes sure all signal handlers are connected
            from myapp import handlers  # noqa
    

    信号的常见用例是允许所有来源访问URL的子集,同时允许一组正常的来源访问所有 URL。仅使用常规配置是不可能的,但是可以使用信号处理程序来实现。

    首先将CORS_ORIGIN_WHITELIST设置为允许访问每个URL的受信任来源列表,然后将处理程序添加到 check_request_enabled以允许CORS不受限制URL的来源。例如:

    # myapp/handlers.py
    from corsheaders.signals import check_request_enabled
    
    def cors_allow_api_to_everyone(sender, request, **kwargs):
        return request.path.startswith('/api/')
    
    check_request_enabled.connect(cors_allow_api_to_everyone)
    
  • 相关阅读:
    Design Tutorial: Inverse the Problem
    The Number Off of FFF
    "Money, Money, Money"
    No Pain No Game
    Group
    Vases and Flowers
    Codeforces Round #466 (Div. 2)
    ST表
    Wildcard Matching
    HDOJ 3549 Dinitz
  • 原文地址:https://www.cnblogs.com/liuweida/p/12374002.html
Copyright © 2011-2022 走看看