Deprecate has_permission and login_required in favor of new API
asvetlov opened this issue · comments
I'm thinking about opposite direction: deprecate and remove these decorators.
Please consider two snippets:
@has_permission('read')
async def handler(request):
return web.Response()
and
async def handler(request):
check_permission(request)
return web.Response()
check_permission from second example works basically as existing has_perission decorator.
It raises HTTPForbidden if the user is not authorized.
The main advantage is debugging. In decorator approach basically there is no line to put a breakpoint for debugging permission checks for the handler. The decorator is executed before first handler's line. Setting a breakpoint to decorator itself leads to debugging all handlers with decorator applied, not the specific one.
Also, it solves the problem of class based views (and any other web handlers organization style). The check can be done in any place of code, it is pretty readable and straightforward.
Completely agree with your points but I am afraid that decorator feature will be asked a lot of times, since this is how other frameworks doing permissions (both Django and flask advocate login_required decorator)
We can document the reason for decision
Ok I understand your position but if I want offer a more hight-level API, can I do it without have line to put a breakpoint ?
Perhaps a debug mode can be added, I saw that Python3.7 will add new built-in breakpoint() function (https://www.python.org/dev/peps/pep-0553/)
Setting a breakpoint to decorator itself leads to debugging all handlers with decorator applied, not the specific one.
Here is one possible workaround
def login_required(f):
if f.__name__ == 'handler2':
import pdb; pdb.set_trace()
Alternatively IDEs like PyCharm have conditional breakpoints - in this case you don't need two lines above.
It requires changing or setting a breakpoint on the outer project, not user's application.
Isn't it better if the implementation of the check_permission remains for the user. In that case there is no need to remove decorator, just some func parameter in has_permission, which by default will be the current implementation of the permission checking. It will also allow to use more sofisticated permission checks, e.g. http://www.django-rest-framework.org/api-guide/permissions/#examples
Done by 0.3 release