去掉django rest framework强制的csrf检查
2015-07-25 17:34
579 查看
近期的项目,前端的js是在localhost上跑的,然后向我们后端的开发服务器进行请求。但是突然前端说所有的post请求都报csrf校验错误了,甚是奇怪,之前为了开发方便已经把django的csrf middleware注释掉了啊,为什么还会错误,由于返回值格式还是django rest的通用格式,肯定问题是出在这里面,于是翻了一下它的源代码看了看。
from django.middleware.csrf import CsrfViewMiddleware
class CSRFCheck(CsrfViewMiddleware):
def _reject(self, request, reason):
# Return the failure reason instead of an HttpResponse
return reason
class SessionAuthentication(BaseAuthentication):
“””
Use Django’s session framework for authentication.
“”“
原来是这样,最近给系统增加了用户登陆功能,使用的就是SessionAuthorization和TokenAuthorization,然后在SessionAuthorization中调用了self.enforce_csrf(request)而这个调用的又是上面的CSRFCheck,这个类是重载了django里面的csrf middleware,而且没发现有地方可以关掉这个功能,即使在django里面去掉这个middleware,但是这个还是会调用的。
那怎么去掉这个功能呢,我们现在就是要进行跨域请求。
最简单了,直接注释掉上面的self.enforce_csrf(request)这一行代码就行了或者在设置中添加一项,比如改成
GLOBAL_CSRF_CHECK = True
if GLOBAL_CSRF_CHECK:
self.enforce_csrf(request)
我们继续看源代码,到middleware的代码里面去。
class CsrfViewMiddleware(object):
“””
Middleware that requires a present and correct csrfmiddlewaretoken
for POST requests that have a CSRF cookie, and sets an outgoing
CSRF cookie.
里面主要有两个函数,一个是process view,另一个是process response。这里就不得不说django middleware的工作原理了。
https://docs.djangoproject.com/en/1.6/topics/http/middleware/
process_request() is called on each request, before Django decides which view to execute.
process_view() is called just before Django calls the view.
process_response() is called on all responses before they’re returned to the browser.
所以这个middleware的process view会在请求到达view函数之前被调用,可以理解为一个过滤器吧。
if request.method not in (‘GET’, ‘HEAD’, ‘OPTIONS’, ‘TRACE’):
if getattr(request, ‘_dont_enforce_csrf_checks’, False):
return self._accept(request)
这里request里面有_dont_enforce_csrf_checks就直接进入view了,没有下面的检查了。所以我们只要自己给request添加一个这样的属性就好了。最直接的方法还是去写一个middleware啊,哈哈。
代码很简单
class DisableCSRFCheck(object):
def process_request(self, request):
setattr(request, ‘_dont_enforce_csrf_checks’, True)
from django.middleware.csrf import CsrfViewMiddleware
class CSRFCheck(CsrfViewMiddleware):
def _reject(self, request, reason):
# Return the failure reason instead of an HttpResponse
return reason
class SessionAuthentication(BaseAuthentication):
“””
Use Django’s session framework for authentication.
“”“
def authenticate(self, request): """ Returns a `User` if the request session currently has a logged in user. Otherwise returns `None`. """ # Get the underlying HttpRequest object request = request._request user = getattr(request, 'user', None) # Unauthenticated, CSRF validation not required if not user or not user.is_active: return None self.enforce_csrf(request) # CSRF passed with authenticated user return (user, None) def enforce_csrf(self, request): """ Enforce CSRF validation for session based authentication. """ reason = CSRFCheck().process_view(request, None, (), {}) if reason: # CSRF failed, bail with explicit error message raise exceptions.PermissionDenied('CSRF Failed: %s' % reason)
原来是这样,最近给系统增加了用户登陆功能,使用的就是SessionAuthorization和TokenAuthorization,然后在SessionAuthorization中调用了self.enforce_csrf(request)而这个调用的又是上面的CSRFCheck,这个类是重载了django里面的csrf middleware,而且没发现有地方可以关掉这个功能,即使在django里面去掉这个middleware,但是这个还是会调用的。
那怎么去掉这个功能呢,我们现在就是要进行跨域请求。
最简单了,直接注释掉上面的self.enforce_csrf(request)这一行代码就行了或者在设置中添加一项,比如改成
GLOBAL_CSRF_CHECK = True
if GLOBAL_CSRF_CHECK:
self.enforce_csrf(request)
我们继续看源代码,到middleware的代码里面去。
class CsrfViewMiddleware(object):
“””
Middleware that requires a present and correct csrfmiddlewaretoken
for POST requests that have a CSRF cookie, and sets an outgoing
CSRF cookie.
This middleware should be used in conjunction with the csrf_token template tag. """ # The _accept and _reject methods currently only exist for the sake of the # requires_csrf_token decorator. def _accept(self, request): # Avoid checking the request twice by adding a custom attribute to # request. This will be relevant when both decorator and middleware # are used. request.csrf_processing_done = True return None def _reject(self, request, reason): logger.warning('Forbidden (%s): %s', reason, request.path, extra={ 'status_code': 403, 'request': request, } ) return _get_failure_view()(request, reason=reason) def process_view(self, request, callback, callback_args, callback_kwargs): if getattr(request, 'csrf_processing_done', False): return None try: csrf_token = _sanitize_token( request.COOKIES[settings.CSRF_COOKIE_NAME]) # Use same token next time request.META['CSRF_COOKIE'] = csrf_token except KeyError: csrf_token = None # Generate token and store it in the request, so it's # available to the view. request.META["CSRF_COOKIE"] = _get_new_csrf_key() # Wait until request.META["CSRF_COOKIE"] has been manipulated before # bailing out, so that get_token still works if getattr(callback, 'csrf_exempt', False): return None # Assume that anything not defined as 'safe' by RFC2616 needs protection if request.method not in ('GET', 'HEAD', 'OPTIONS', 'TRACE'): if getattr(request, '_dont_enforce_csrf_checks', False): # Mechanism to turn off CSRF checks for test suite. # It comes after the creation of CSRF cookies, so that # everything else continues to work exactly the same # (e.g. cookies are sent, etc.), but before any # branches that call reject(). return self._accept(request) if request.is_secure(): # Suppose user visits http://example.com/ # An active network attacker (man-in-the-middle, MITM) sends a # POST form that targets https://example.com/detonate-bomb/ and # submits it via JavaScript. # # The attacker will need to provide a CSRF cookie and token, but # that's no problem for a MITM and the session-independent # nonce we're using. So the MITM can circumvent the CSRF # protection. This is true for any HTTP connection, but anyone # using HTTPS expects better! For this reason, for # https://example.com/ we need additional protection that treats # http://example.com/ as completely untrusted. Under HTTPS, # Barth et al. found that the Referer header is missing for # same-domain requests in only about 0.2% of cases or less, so # we can use strict Referer checking. referer = request.META.get('HTTP_REFERER') if referer is None: return self._reject(request, REASON_NO_REFERER) # Note that request.get_host() includes the port. good_referer = 'https://%s/' % request.get_host() if not same_origin(referer, good_referer): reason = REASON_BAD_REFERER % (referer, good_referer) return self._reject(request, reason) if csrf_token is None: # No CSRF cookie. For POST requests, we insist on a CSRF cookie, # and in this way we can avoid all CSRF attacks, including login # CSRF. return self._reject(request, REASON_NO_CSRF_COOKIE) # Check non-cookie token for match. request_csrf_token = "" if request.method == "POST": request_csrf_token = request.POST.get('csrfmiddlewaretoken', '') if request_csrf_token == "": # Fall back to X-CSRFToken, to make things easier for AJAX, # and possible for PUT/DELETE. request_csrf_token = request.META.get('HTTP_X_CSRFTOKEN', '') if not constant_time_compare(request_csrf_token, csrf_token): return self._reject(request, REASON_BAD_TOKEN) return self._accept(request) def process_response(self, request, response): if getattr(response, 'csrf_processing_done', False): return response # If CSRF_COOKIE is unset, then CsrfViewMiddleware.process_view was # never called, probaby because a request middleware returned a response # (for example, contrib.auth redirecting to a login page). if request.META.get("CSRF_COOKIE") is None: return response if not request.META.get("CSRF_COOKIE_USED", False): return response # Set the CSRF cookie even if it's already set, so we renew # the expiry timer. response.set_cookie(settings.CSRF_COOKIE_NAME, request.META["CSRF_COOKIE"], max_age = 60 * 60 * 24 * 7 * 52, domain=settings.CSRF_COOKIE_DOMAIN, path=settings.CSRF_COOKIE_PATH, secure=settings.CSRF_COOKIE_SECURE, httponly=settings.CSRF_COOKIE_HTTPONLY ) # Content varies with the CSRF cookie, so set the Vary header. patch_vary_headers(response, ('Cookie',)) response.csrf_processing_done = True return response
里面主要有两个函数,一个是process view,另一个是process response。这里就不得不说django middleware的工作原理了。
https://docs.djangoproject.com/en/1.6/topics/http/middleware/
process_request() is called on each request, before Django decides which view to execute.
process_view() is called just before Django calls the view.
process_response() is called on all responses before they’re returned to the browser.
所以这个middleware的process view会在请求到达view函数之前被调用,可以理解为一个过滤器吧。
if request.method not in (‘GET’, ‘HEAD’, ‘OPTIONS’, ‘TRACE’):
if getattr(request, ‘_dont_enforce_csrf_checks’, False):
return self._accept(request)
这里request里面有_dont_enforce_csrf_checks就直接进入view了,没有下面的检查了。所以我们只要自己给request添加一个这样的属性就好了。最直接的方法还是去写一个middleware啊,哈哈。
代码很简单
class DisableCSRFCheck(object):
def process_request(self, request):
setattr(request, ‘_dont_enforce_csrf_checks’, True)
相关文章推荐
- 插件管理框架 for Delphi(一)
- 使用CSS框架布局的缺点和优点小结
- 列举PHP的Yii 2框架的开发优势
- Windows窗体的.Net框架绘图技术实现方法
- 浅谈JavaScript 框架分类
- 轻量级javascript 框架Backbone使用指南
- javascript实现框架高度随内容改变的方法
- JS刷新框架外页面七种实现代码
- 超赞的动手创建JavaScript框架的详细教程
- asp.net4.0框架下验证机制失效的原因及处理办法
- 插件管理框架 for Delphi(二)
- 零基础学习AJAX之AJAX框架
- Ajax 框架学习笔记
- Flex中最好的MVC框架Mate框架
- JavaScript 异步调用框架 (Part 4 - 链式调用)
- JavaScript 异步调用框架 (Part 2 - 用例设计)
- 为什么使用框架 使用框架的优缺点
- JavaScript 异步调用框架 (Part 3 - 代码实现)
- js刷新框架子页面的七种方法代码
- JavaScript框架编程第1/2页