跨域與版本控制
版本控制
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)
跨域與版本控制