情況是這樣的,項目用的restful規范,后端用的django+djangorestframework,前端用的vue-cli框架+webpack,前端與后端交互用的axios,然后再用戶登錄之后,axios添加token作為axios的header並請求后端,后端部分用的djangorestframework的認證組件。
以上的相關知識,不是本篇文章的重點,請移步:
前后端分離djangorestframework——認證組件
postman測試
在最開始寫好后端
認證組件:
視圖部分裝飾認證組件:
vue部分,做了個判斷,如果用戶是登錄狀態,自動設置默認的headers:
添加了請求攔截器之后,前端會自動對每個請求之前請求一次,請求方式為OPTIONS,之后再發出真實的請求
關於這個為什么會做兩次請求是因為:
瀏覽器會對復雜請求進行處理,在發送真正的請求前, 會先發送一個方法為OPTIONS的預請求(preflight request), 用於試探服務端是否能接受真正的請求,如果options獲得的回應是拒絕性質的,比如404\403\500等http狀態,就會停止post、put等請求的發出
有三種方式會導致這種現象:
- 請求方法不是GET/HEAD/POST。即復雜請求
- POST請求的Content-Type並非application/x-www-form-urlencoded, multipart/form-data, 或text/plain。最常見的json就不是
- 請求設置了自定義的header字段。我這里就設置了token作為自定義的headers
用的postman做的測試:
返回結果:
項目真實測試
然后在項目真實測試的時候:
前端用的vue-cli +webpack,啟動項目,並抓包查看時,請求狀態500
並且請求的參數並沒有給上header
后端就是報錯:
就是這個:
TypeError: cannot unpack non-iterable AuthenticationFailed object
並且前端的console部分還報同源策略的錯:
我跟你說,你要是跑去后端設置中間件的response的話,你就距離正確答案越來越遠了,我的中間件部分是這樣的:
然后根據前面用postman測試都沒問題,所以我判定,一定不是中間件的問題
思來想去,根本的原因就是拿不到token,所以我開始在這方面思考,然后我注釋了那段是否帶有token的判斷,再測試:
打印request.META
注釋掉驗證部分,只是打印看看request.META里的數據
前端再次請求:
OPTIONS請求方式因為已經取消了驗證所以不報錯了:
第二次真實請求也出現了,並且返回狀態碼200
header部分也帶上了token:
也就是說,前端裝飾上了token的,但是后端沒有拿到,所以報錯了
最后看看,后端print(request.META)
因為有兩次請求,看看兩次到底有什么不同(我已經刪除掉了一些無關精要的數據)
第一次請求時:
{'ALLUSERSPROFILE':'RUN_MAIN': 'true', 'SERVER_NAME': 'www.xmind.net', 'GATEWAY_INTERFACE': 'CGI/1.1', 'SERVER_PORT': '8000', 'REMOTE_HOST': '', 'CONTENT_LENGTH': '', 'SCRIPT_NAME': '', 'SERVER_PROTOCOL': 'HTTP/1.1', 'SERVER_SOFTWARE': 'WSGIServer/0.2', 'REQUEST_METHOD': 'OPTIONS', 'PATH_INFO': '/api/v1/', 'QUERY_STRING': '', 'REMOTE_ADDR': '127.0.0.1', 'CONTENT_TYPE': 'text/plain', 'HTTP_HOST': '127.0.0.1:8000', 'HTTP_CONNECTION': 'keep-alive', 'HTTP_ACCESS_CONTROL_REQUEST_METHOD': 'GET', 'HTTP_ORIGIN': 'http://localhost:8080', 'HTTP_USER_AGENT': 'Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3738.0 Safari/537.36 Edg/75.0.107.0', 'HTTP_ACCESS_CONTROL_REQUEST_HEADERS': 'authorization', 'HTTP_ACCEPT': '*/*', 'HTTP_REFERER': 'http://localhost:8080/Course', 'HTTP_ACCEPT_ENCODING': 'gzip, deflate, br', 'HTTP_ACCEPT_LANGUAGE': 'zh-CN,zh;q=0.9,en;q=0.8,en-US;q=0.7', 'wsgi.input': <_io.BufferedReader name=628>, 'wsgi.errors': <_io.TextIOWrapper name='<stderr>' mode='w' encoding='UTF-8'>, 'wsgi.version': (1, 0), 'wsgi.run_once': False, 'wsgi.url_scheme': 'http', 'wsgi.multithread': True, 'wsgi.multiprocess': False, 'wsgi.file_wrapper': <class 'wsgiref.util.FileWrapper'>}
第二次請求時:
{'ALLUSERSPROFILE': 'RUN_MAIN': 'true', 'SERVER_NAME': 'www.xmind.net', 'GATEWAY_INTERFACE': 'CGI/1.1', 'SERVER_PORT': '8000', 'REMOTE_HOST': '', 'CONTENT_LENGTH': '', 'SCRIPT_NAME': '', 'SERVER_PROTOCOL': 'HTTP/1.1', 'SERVER_SOFTWARE': 'WSGIServer/0.2', 'REQUEST_METHOD': 'GET', 'PATH_INFO': '/api/v1/', 'QUERY_STRING': '', 'REMOTE_ADDR': '127.0.0.1', 'CONTENT_TYPE': 'text/plain', 'HTTP_HOST': '127.0.0.1:8000', 'HTTP_CONNECTION': 'keep-alive', 'HTTP_ACCEPT': 'application/json, text/plain, */*', 'HTTP_ORIGIN': 'http://localhost:8080', 'HTTP_AUTHORIZATION': '626d34f7-2302-4bb0-a012-5daf0f588d8c', 'HTTP_USER_AGENT': 'Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3738.0 Safari/537.36 Edg/75.0.107.0', 'HTTP_REFERER': 'http://localhost:8080/Course', 'HTTP_ACCEPT_ENCODING': 'gzip, deflate, br', 'HTTP_ACCEPT_LANGUAGE': 'zh-CN,zh;q=0.9,en;q=0.8,en-US;q=0.7', 'wsgi.input': <_io.BufferedReader name=632>, 'wsgi.errors': <_io.TextIOWrapper name='<stderr>' mode='w' encoding='UTF-8'>, 'wsgi.version': (1, 0), 'wsgi.run_once': False, 'wsgi.url_scheme': 'http', 'wsgi.multithread': True, 'wsgi.multiprocess': False, 'wsgi.file_wrapper': <class 'wsgiref.util.FileWrapper'>}
發現前面一大段都相同,就從請求方式開始有不同的,所以我重新設置了認證組件。
因為一個請求方式是OPTIONS,一個是GET,並且看前端部分,當請求方式是OPTIONS的時候因為是瀏覽器自動發的預請求,所以沒有按我們設定的帶上自定義的header,也就沒有Authorization-token這個參數了
終於發現了問題所在,最后在后端做了個判斷,當請求方式是OPTIONS的時候,跳過驗證,然后完美解決:
前端請求:沒問題,都是200
並且后端確實可以打印出對應的用戶名和token:
好的,踩坑完畢,感謝查看