跨域與版本控制
版本控制
from rest_framework.versioning import QueryParameterVersioning,AcceptHeaderVersioning,NamespaceVersioning,URLPathVersioning #基於url的get傳參方式：QueryParameterVersioning------>如：/users?version=v1 #基於url的正則方式：URLPathVersioning------>/v1/users/ #基於 accept 請求頭方式：AcceptHeaderVersioning------>Accept: application/json; version=1.0 #基於主機名方法：HostNameVersioning------>v1.example.com #基於django路由系統的namespace：NamespaceVersioning------>example.com/v1/users/
-內置的類
QueryParameterVersioning, 基於get傳參的方式
AcceptHeaderVersioning,基於請求頭的
NamespaceVersioning, 基於名稱空間的
URLPathVersioning 基於正則的方式(推薦)
-局部使用
在視圖類中配置
versioning_class=URLPathVersioning
-全局使用
在setting中配置:
‘DEFAULT_VERSIONING_CLASS‘:‘rest_framework.versioning.URLPathVersioning‘,‘DEFAULT_VERSION‘: ‘v1‘, # 默認版本(從request對象裏取不到，顯示的默認值)
‘ALLOWED_VERSIONS‘: [‘v1‘, ‘v2‘], # 允許的版本
‘VERSION_PARAM‘: ‘version‘ # URL中獲取值的key
-例外:
用基於正則的方式,需要修改urls.py
url(r‘^(?P<version>[v1|v2]+)/versiontest/‘, views.VersionTest.as_view()),-在視圖類的方法中可以取出版本號
reques.version
基於正則的方式：
from django.conf.urls import url, include
from web.views import TestView
urlpatterns = [
url(r‘^(?P<version>[v1|v2]+)/test/‘, TestView.as_view(), name=‘test‘),
]
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework.versioning import URLPathVersioning
class TestView(APIView):
versioning_class = URLPathVersioning
def get(self, request, *args, **kwargs):
# 獲取版本
print(request.version)
# 獲取版本管理的類
print(request.versioning_scheme)
# 反向生成URL
reverse_url = request.versioning_scheme.reverse(‘test‘, request=request)
print(reverse_url)
return Response(‘GET請求，響應內容‘)
# 基於django內置,反向生成url
from django.urls import reverse
url2=reverse(viewname=‘ttt‘,kwargs={‘version‘:‘v2‘})
print(url2)
同源策略（Same origin policy）是一種約定，它是瀏覽器最核心也最基本的安全功能，如果缺少了同源策略，則瀏覽器的正常功能可能都會受到影響。可以說Web是構建在同源策略基礎之上的，瀏覽器只是針對同源策略的一種實現
請求的url地址,必須與瀏覽器上的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需要瀏覽器和服務器同時支持。目前，所有瀏覽器都支持該功能，IE瀏覽器不能低於IE10。
整個CORS通信過程，都是瀏覽器自動完成，不需要用戶參與。對於開發者來說，CORS通信與同源的AJAX通信沒有差別，代碼完全一樣。瀏覽器一旦發現AJAX請求跨源，就會自動添加一些附加的頭信息，有時還會多出一次附加的請求，但用戶不會有感覺。
因此，實現CORS通信的關鍵是服務器。只要服務器實現了CORS接口，就可以跨源通信。
回到目錄三 CORS基本流程
瀏覽器將CORS請求分成兩類：簡單請求（simple request）和非簡單請求（not-so-simple request）。
瀏覽器發出CORS簡單請求，只需要在頭信息之中增加一個Origin字段。
瀏覽器發出CORS非簡單請求，會在正式通信之前，增加一次HTTP查詢請求，稱為"預檢"請求（preflight）。瀏覽器先詢問服務器，當前網頁所在的域名是否在服務器的許可名單之中，以及可以使用哪些HTTP動詞和頭信息字段。只有得到肯定答復，瀏覽器才會發出正式的XMLHttpRequest請求，否則就報錯。
只要同時滿足以下兩大條件，就屬於簡單請求。
（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
凡是不同時滿足上面兩個條件，就屬於非簡單請求。
瀏覽器對這兩種請求的處理，是不一樣的。
* 簡單請求和非簡單請求的區別？
簡單請求：一次請求
非簡單請求：兩次請求，在發送數據之前會先發一次請求用於做“預檢”，只有“預檢”通過後才再發送一次請求用於數據傳輸。
* 關於“預檢”
- 請求方式：OPTIONS
- “預檢”其實做檢查，檢查如果通過則允許傳輸數據，檢查不通過則不再發送真正想要發送的消息
- 如何“預檢”
=> 如果復雜請求是PUT等請求，則服務端需要設置允許某請求，否則“預檢”不通過
Access-Control-Request-Method
=> 如果復雜請求設置了請求頭，則服務端需要設置允許某請求頭，否則“預檢”不通過
Access-Control-Request-Headers
支持跨域，簡單請求
服務器設置響應頭：Access-Control-Allow-Origin = ‘域名‘ 或 ‘*‘
支持跨域，復雜請求
由於復雜請求時，首先會發送“預檢”請求，如果“預檢”成功，則發送真實數據。
- “預檢”請求時，允許請求方式則需服務器設置響應頭：Access-Control-Request-Method
- “預檢”請求時，允許請求頭則需服務器設置響應頭：Access-Control-Request-Headers
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
放到中間件處理復雜和簡單請求： 將自定義類的位置放入中間件
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
# 基於django內置,反向生成url
from django.urls import reverse
url2=reverse(viewname=‘ttt‘,kwargs={‘version‘:‘v2‘})
print(url2)
跨域與版本控制