@BarneyGumble

Как провериться на админа в шаблоне Django?

Достался в наследство рабочий сайт-каталог на Django. Работая раньше только с PHP на бэкенде, я с столкнулся с одной проблемой, касающейся проверки админских прав в шаблоне (хотя говорят, что раньше всё работало...как обычно)

Имею в шаблоне index.html следующее:

{% if is_admin %}
    <a href="#" class="edit-button">Edit</a>
{% endif %}


Условие не отрабатывает, кнопка не появляется, хотя в админке я залогинен под админом

В файле models.py где описаны все модели, есть строка подключения этой библиотеки

from django.contrib.auth.models import User, Group

Однако ниже в коде ни в каком классе эта библиотека не используется. По крайне мере, я не нашёл где и должна ли вообще :)

Подскажите, куда копать?)

is_admin - это какая-то базовая функция проверки, или пользовательская, прописанная где-то. Если так, то где искать её описание?
  • Вопрос задан
  • 1960 просмотров
Пригласить эксперта
Ответы на вопрос 2
@antonksa
Давайте по порядку.

1. Шаблонизатор джанго. Принимает на вход html (на самом деле не тольк, а любой текстовый файл) и коробку с новогодними подарками (нет) переменными, так называемый контекст. При обработке шаблона шаблонизатор заменяет специальный синтаксис {{ имя_переменной }} которые он ищет в контекстте (контекст это обычный словарь ключ-значение).

2. User. Юзер это встроенная в джанго модель юзера. Ее можно заменить своей, но 90% используется эта. Middleware авторизации получает объект запроса, перед тем как он будет передан на обработку во View. В 90% случаев опять же используется встроенная миддлварь из модуля django.contrib.auth. Миддлварь ковыряется в куках, находит session_key и ищет в базе данных (в 90% случаев, ну вы понели) какому юзеру соответствует эта сессия. После этого добавляется/модифицируется property экземпляра HttpRequest. Этому аттрибуту присваивается выковырянный из БД экземпляр User или, если юзер не авторизован, AnonymousUser.

3. View вызывает функцию render которая принимает шаблон и контекст. для сбора контекста у класса View есть метод get_context который собирает контекст в кучу. Даже если вы просто написали самый банальный
class MyFuckingView(TemplateView):
    template_name = 'some/module/template.html'

то при обработке get запроса будет вызван get_context из родительского класса TemplateView.

4. По умолчанию джанга пропихивает в контекст request и еще некоторые вещи ( экземпляр view, который был использован и в зависимости от использованного CBV (class based view) там может быть queryset, object и другие штуки. Еще раз, это встроенный функционал, поэтому если вы модифицируете контекст, то вам всегда нужно вызывать метод родителя, чтобы это не потерялось:
class MyFuckingView(TemplateView):
    template_name = 'some/module/template.html'

    def get_context(self):
        ctx = super().get_context()
        ctx['model_name'] = 'Sasha Grey'
        ctx['category'] = 'Milf anal'
        return ctx


5. Наконец резюмируя, в вашем случае в контексте должен быть request. is_admin там могло появиться только принудительно. Модифицируйте шаблон:
{% if request.user.is_admin %}
    <a href="#" class="edit-button">Edit</a>
{% endif %}

и все должно заработать. И перечитайте то что я писал выше - туториал по джанго можно осилить за день-два, это очень с одной стороны простой и с другой продуманный и вымученный за 13 лет существования всем сообществом фреймворк.
Ответ написан
Whitejamer
@Whitejamer
{% if user.is_superuser %}
    # Hello, admin.
{% endif %}

Если объяснить, то user это request.user контекстная переменная которая создается автоматически.
Источник: https://stackoverflow.com/questions/11916297/djang...
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы