python - django rest framework: order of decorators, auth classes, dispatch to be called -


very confused order of decorators, auth classes, dispatch called in djangorestframework. seems little different django framework knowledge.

some codes:

#operation_logger: customized decorator class fileview(apiview):     parser_classes = (multipartparser,)#a     authentication_classes = (basicauthentication,)#b      @permission_classes((isauthenticated,))#c     @method_decorator(csrf_exempt)#d     @method_decorator(operation_logger)#e     def dispatch(self, request, *args, **kwargs):#f        return super(fileview, self).dispatch(request, *args, **kwargs)      @method_decorator(operation_logger)#g     def post(self, request):#h         print "xxxxpost" 

what order of (a),b,c,d,e,f,g,h called when handling requests? seems b called after f before g , h?

by way, @ beginning, project traditional django project. know request should go through middlewares. now, added new app, hosts apis drf. i not sure whether request apis go through middlewares or not?

thanks

the call order specified:

  1. @method_decorator(csrf_exempt)
  2. @method_decorator(operation_logger) (#e)
  3. dispatch() calls initial() calls check_permissions() evaluates permission_classes (#b).
  4. @method_decorator(operation_logger) (#g)
  5. post()

one thing won't work, however:

@permission_classes((isauthenticated,)) on method adds permission_classes field callable (whatever is) returned (#e). doesn't work class-based views , no-op.

other parts have no fixed order, used on demand:

the authenticator called whenever needed, i.e. when user or authentication information accessed on request object.

same thing parser_classes. these passed request object , used lazily when request information accessed, e.g. request.data.


Comments

Popular posts from this blog

jOOQ update returning clause with Oracle -

java - Warning equals/hashCode on @Data annotation lombok with inheritance -

java - BasicPathUsageException: Cannot join to attribute of basic type -