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:
@method_decorator(csrf_exempt)
@method_decorator(operation_logger)
(#e)dispatch()
callsinitial()
callscheck_permissions()
evaluatespermission_classes
(#b).@method_decorator(operation_logger)
(#g)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
Post a Comment