Как использовать decor_required декораторы в классах на основе django

Ответ 1

В документах CBV указано несколько стратегий:

1. Добавьте декоратор в свой маршрут urls.py, например, login_required(ViewSpaceIndex.as_view(..))

2. Украсьте свой метод CBV dispatch с помощью method_decorator, например,

   from django.utils.decorators import method_decorator
   
   @method_decorator(login_required, name='dispatch')
   class ViewSpaceIndex(TemplateView):
       template_name = 'secret.html'
   

   До Django 1.9 нельзя использовать method_decorator в классе, поэтому вы должны переопределить метод dispatch:

   class ViewSpaceIndex(TemplateView):
   
       @method_decorator(login_required)
       def dispatch(self, *args, **kwargs):
           return super(ViewSpaceIndex, self).dispatch(*args, **kwargs)
   

3. Используйте миксины доступа, такие как django.contrib.auth.mixins.LoginRequiredMixin, доступные в Django 1. 9+ и хорошо изложенные в других ответах здесь:

   from django.contrib.auth.mixins import LoginRequiredMixin
   
   class MyView(LoginRequiredMixin, View):
   
       login_url = '/login/'
       redirect_field_name = 'redirect_to'
   

Причина, по которой вы получаете TypeError, объясняется в документации:

Примечание: method_decorator передает * args и ** kwargs в качестве параметров оформленному методу класса. Если ваш метод не принимает совместимый набор параметров, он вызовет исключение TypeError.

Ответ 2

Вот мой подход, я создаю mixin, который защищен (это хранится в моей библиотеке mixin):

from django.contrib.auth.decorators import login_required
from django.utils.decorators import method_decorator

class LoginRequiredMixin(object):
    @method_decorator(login_required)
    def dispatch(self, request, *args, **kwargs):
        return super(LoginRequiredMixin, self).dispatch(request, *args, **kwargs)

Всякий раз, когда вы хотите, чтобы представление было защищено, вы просто добавляете соответствующий mixin:

class SomeProtectedViewView(LoginRequiredMixin, TemplateView):
    template_name = 'index.html'

Просто убедитесь, что ваш микшинг первым.

Обновление: Я опубликовал это еще в 2011 году, начиная с версии 1.9. Django теперь включает этот и другие полезные миксины (AccessMixin, PermissionRequiredMixin, UserPassesTestMixin) в качестве стандарта!

Ответ 3

Здесь альтернатива, использующая декораторы на основе классов:

from django.utils.decorators import method_decorator

def class_view_decorator(function_decorator):
    """Convert a function based decorator into a class based decorator usable
    on class based Views.

    Can't subclass the `View` as it breaks inheritance (super in particular),
    so we monkey-patch instead.
    """

    def simple_decorator(View):
        View.dispatch = method_decorator(function_decorator)(View.dispatch)
        return View

    return simple_decorator

Затем это можно использовать просто так:

@class_view_decorator(login_required)
class MyView(View):
    # this view now decorated

Ответ 4

Я понимаю, что эта нить немного устарела, но здесь все мои два цента.

со следующим кодом:

from django.utils.decorators import method_decorator
from inspect import isfunction

class _cbv_decorate(object):
    def __init__(self, dec):
        self.dec = method_decorator(dec)

    def __call__(self, obj):
        obj.dispatch = self.dec(obj.dispatch)
        return obj

def patch_view_decorator(dec):
    def _conditional(view):
        if isfunction(view):
            return dec(view)

        return _cbv_decorate(dec)(view)

    return _conditional

теперь у нас есть способ запланировать декоратор, поэтому он станет многофункциональным. Это фактически означает, что при применении к обычным декораторам, например:

login_required = patch_view_decorator(login_required)

этот декоратор по-прежнему будет работать, когда используется так, как он был изначально предназначен:

@login_required
def foo(request):
    return HttpResponse('bar')

но также будет работать правильно при использовании так:

@login_required
class FooView(DetailView):
    model = Foo

Это, кажется, отлично работает в нескольких случаях, с которыми я недавно столкнулся, включая этот реальный пример:

@patch_view_decorator
def ajax_view(view):
    def _inner(request, *args, **kwargs):
        if request.is_ajax():
            return view(request, *args, **kwargs)
        else:
            raise Http404

    return _inner

Функция ajax_view записывается для изменения представления (на основе функции), так что она вызывает ошибку 404 всякий раз, когда этот просмотр посещается без аякс-вызова. Просто применяя функцию патча в качестве декоратора, этот декоратор также настроен на работу с представлениями на основе классов

Ответ 5

Для тех из вас, кто использует Django> = 1.9, он уже включен в django.contrib.auth.mixins как AccessMixin, LoginRequiredMixin, PermissionRequiredMixin и UserPassesTestMixin.

Таким образом, чтобы применить LoginRequired к CBV (например, DetailView):

from django.contrib.auth.mixins import LoginRequiredMixin
from django.views.generic.detail import DetailView


class ViewSpaceIndex(LoginRequiredMixin, DetailView):
    model = Space
    template_name = 'spaces/space_index.html'
    login_url = '/login/'
    redirect_field_name = 'redirect_to'

Также хорошо иметь в виду порядок микширования GCBV: миксины должны идти с левой стороны, а класс базового представления должен идти с правой стороны. Если порядок отличается, вы можете получить сломанные и непредсказуемые результаты.

Ответ 6

Если это сайт, на котором большинство страниц требует, чтобы пользователь вошел в систему, вы можете использовать промежуточное ПО для принудительного входа в систему во всех представлениях, кроме тех, которые особо отмечены.

Pre Django 1.10 middleware.py:

from django.contrib.auth.decorators import login_required
from django.conf import settings

EXEMPT_URL_PREFIXES = getattr(settings, 'LOGIN_EXEMPT_URL_PREFIXES', ())

class LoginRequiredMiddleware(object):
    def process_view(self, request, view_func, view_args, view_kwargs):
        path = request.path
        for exempt_url_prefix in EXEMPT_URL_PREFIXES:
            if path.startswith(exempt_url_prefix):
                return None
        is_login_required = getattr(view_func, 'login_required', True)
        if not is_login_required:
            return None
        return login_required(view_func)(request, *view_args, **view_kwargs) 

views.py:

def public(request, *args, **kwargs):
    ...
public.login_required = False

class PublicView(View):
    ...
public_view = PublicView.as_view()
public_view.login_required = False

Сторонние представления, которые вы не хотите переносить, могут быть исключены из настроек:

settings.py:

LOGIN_EXEMPT_URL_PREFIXES = ('/login/', '/reset_password/')

Ответ 7

Используйте привязки Django. Он предоставляет множество полезных миксинов, которые легко доступны. У него красивые документы. Попробуйте.

Вы даже можете создать свои собственные микшины.

http://django-braces.readthedocs.org/en/v1.4.0/

Пример кода:

from django.views.generic import TemplateView

from braces.views import LoginRequiredMixin


class SomeSecretView(LoginRequiredMixin, TemplateView):
    template_name = "path/to/template.html"

    #optional
    login_url = "/signup/"
    redirect_field_name = "hollaback"
    raise_exception = True

    def get(self, request):
        return self.render_to_response({})

Ответ 8

В моем коде я написал этот адаптер для адаптации функций-членов к функции, не являющейся членом:

from functools import wraps


def method_decorator_adaptor(adapt_to, *decorator_args, **decorator_kwargs):
    def decorator_outer(func):
        @wraps(func)
        def decorator(self, *args, **kwargs):
            @adapt_to(*decorator_args, **decorator_kwargs)
            def adaptor(*args, **kwargs):
                return func(self, *args, **kwargs)
            return adaptor(*args, **kwargs)
        return decorator
    return decorator_outer

Вы можете просто использовать это так:

from django.http import HttpResponse
from django.views.generic import View
from django.contrib.auth.decorators import permission_required
from some.where import method_decorator_adaptor


class MyView(View):
    @method_decorator_adaptor(permission_required, 'someapp.somepermission')
    def get(self, request):
        # <view logic>
        return HttpResponse('result')

Ответ 9

Это очень легко с django> 1.9 с поддержкой PermissionRequiredMixin и LoginRequiredMixin

Просто импортируйте из аутентификации

views.py

from django.contrib.auth.mixins import LoginRequiredMixin

class YourListView(LoginRequiredMixin, Views):
    pass

Подробнее читайте в Авторизация в django

Ответ 10

Если вы выполняете проект, требующий множества тестов разрешений, вы можете наследовать этот класс.

from django.contrib.auth.decorators import login_required
from django.contrib.auth.decorators import user_passes_test
from django.views.generic import View
from django.utils.decorators import method_decorator



class UserPassesTest(View):

    '''
    Abstract base class for all views which require permission check.
    '''


    requires_login = True
    requires_superuser = False
    login_url = '/login/'

    permission_checker = None
    # Pass your custom decorator to the 'permission_checker'
    # If you have a custom permission test


    @method_decorator(self.get_permission())
    def dispatch(self, *args, **kwargs):
        return super(UserPassesTest, self).dispatch(*args, **kwargs)


    def get_permission(self):

        '''
        Returns the decorator for permission check
        '''

        if self.permission_checker:
            return self.permission_checker

        if requires_superuser and not self.requires_login:
            raise RuntimeError((
                'You have assigned requires_login as False'
                'and requires_superuser as True.'
                "  Don't do that!"
            ))

        elif requires_login and not requires_superuser:
            return login_required(login_url=self.login_url)

        elif requires_superuser:
            return user_passes_test(lambda u:u.is_superuser,
                                    login_url=self.login_url)

        else:
            return user_passes_test(lambda u:True)

Ответ 11

Я сделал это исправление на основе решения Josh

class LoginRequiredMixin(object):

    @method_decorator(login_required)
    def dispatch(self, *args, **kwargs):
        return super(LoginRequiredMixin, self).dispatch(*args, **kwargs)

Использование образца:

class EventsListView(LoginRequiredMixin, ListView):

    template_name = "events/list_events.html"
    model = Event

Ответ 12

Прошло много времени, и теперь Джанго так сильно изменился.

Посмотрите здесь, как оформить представление на основе классов.

https://docs.djangoproject.com/en/2.2/topics/class-based-views/intro/#decorating-the-class

Документация не включала пример "декораторов, которые принимают любой аргумент". Но декораторы, которые принимают аргументы, выглядят так:

def mydec(arg1):
    def decorator(func):
         def decorated(*args, **kwargs):
             return func(*args, **kwargs) + arg1
         return decorated
    return deocrator

поэтому, если мы хотим использовать mydec в качестве "обычного" декоратора без аргументов, мы можем сделать это:

mydecorator = mydec(10)

@mydecorator
def myfunc():
    return 5

Таким же образом, использовать permission_required с method_decorator

мы можем сделать:

@method_decorator(permission_required("polls.can_vote"), name="dispatch")
class MyView:
    def get(self, request):
        # ...