Да, это возможно, но не очень прямолинейно. Усложняющим фактором является то, что декоратор Django login_required
на самом деле проходит через 2 уровня косвенности (одна динамическая функция и еще один декоратор), чтобы в итоге оказаться в django.contrib.auth.decorators._CheckLogin, который является классом с методом __call__
.
Допустим, у вас есть не-django, декорированная функция, которая выглядит так:
def my_decorator(func):
def inner():
return func()
return inner
@my_decorator
def foo():
print foo.func_name
# results in: inner
Проверить, была ли функция foo
обернута, можно так же просто, как проверить имя объекта функции. Вы можете сделать это внутри функции. Имя на самом деле будет именем последней функции-оболочки. В более сложных случаях вы можете использовать модуль inspect
для просмотра внешних фреймов от текущего фрейма, если вы ищете что-то конкретное.
Однако в случае Django тот факт, что декоратор на самом деле является экземпляром класса _CheckLogin
, означает, что функция на самом деле не является функцией и, следовательно, не имеет свойства func_name
: попытка выполнения приведенного выше кода вызовет исключение.
Однако просмотр исходного кода для django.contrib.auth.decorators._CheckLogin
показывает, что экземпляр _CheckLogin
будет иметь свойство login_url
. Это довольно простая вещь для проверки:
@login_required
def my_view(request):
is_private = hasattr(my_view, 'login_url')
Поскольку _CheckLogin
также используется для реализации других декораторов аутентификации, этот подход также будет работать для permission_required
и т. д. Однако у меня никогда не было необходимости использовать это, поэтому я действительно не могу комментировать, что вы должны искать, если у вас есть несколько декораторов вокруг одного представления ... упражнение, оставленное читателю, я думаю (проверить стек фреймов?).
Однако в качестве незапрошенного редакционного совета я бы сказал, что проверка самой функции, чтобы увидеть, была ли она обернута таким образом, кажется мне немного неудобной. Вы, вероятно, можете представить всевозможные непредсказуемые действия, ожидающие, когда новый разработчик придет в проект, как пощечину какому-то другому декоратору. На самом деле, вы также подвержены изменениям в самой среде django... риску безопасности, ожидающему своего часа.
По этой причине я бы рекомендовал подход Ван Гейла как нечто явное и, следовательно, гораздо более надежную реализацию.
person
Jarret Hardie
schedule
29.03.2009