Доступ к пользователю в общих представлениях на основе классов

Я пытаюсь проверить, является ли user.is_authenticated() или user.has_perm(), но кажется невозможным расширение генерирующих представлений на основе классов django. Единственный метод, который я нашел, где появляется request, это get().

class MyDetailView(DetailView):
    def get(self, request, **kwargs):
        import pdb
        pdb.set_trace()
        self.object = self.get_object()
        context = self.get_context_data(object=self.object)
        return self.render_to_response(context)

там я обнаружил, что request.user является экземпляром AnonymusClass независимо от того, вошел я в систему или нет.

(Pdb) request.user.__class__
<class 'django.contrib.auth.models.AnonymousUser'>

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

(Pdb) self.request.user.is_authenticated()
False

Я пытался переопределить другие методы, такие как get_object(), get_context_data() и другие. У каждого из них есть атрибут self.request, но user по-прежнему Anonymus.

Итак, мой вопрос: Как я должен проверить, вошел ли пользователь в систему, используя представления на основе классов!?

Означает ли это, что я должен (вернуться и) использовать представления на основе функций?

Я использую Python 2.7.1+ и Django version 1.4 pre-alpha SVN-16627




В ответ на сообщение EVIAAC: Использование декораторов login_required или permissions_required не вариант. Мне нужно проверить разрешения/вход в систему после получения объекта: если объект имеет логическое поле registration_required, установленное на True, только зарегистрированные пользователи смогут видеть страницу, другие будут перенаправлены на страницу входа (пример поведения заимствован из django.contrib.flatpages).


django django-authentication firefox django-generic-views
person seler    schedule 21.08.2011    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Работает правильно в 1.3:

class TestView(DetailView):
    def get(self, request, **kwargs):
        import ipdb; ipdb.set_trace()

ipdb> request.user
<User: zk>
ipdb> request.user.is_authenticated()
True

Возможно баг?

person zeekay    schedule 21.08.2011
comment
Это должно быть что-то еще. Я создал тестовый проект с тестовым приложением с тестовой моделью с тестовым представлением, используя django 1.3, и результат все тот же. Может быть, я что-то упускаю. Не могли бы вы опубликовать полный тестовый код? - person seler; 21.08.2011
comment
Это полный код. Не хватает только urlconf, как и следовало ожидать: url(r'^test', TestView.as_view()) - person zeekay; 21.08.2011
comment
Похоже, что эта ошибка присутствует только при использовании Firefox, что довольно странно. :/ - person seler; 21.08.2011
comment
Также проверил другой проект 1.3, не уверен, что вы можете делать неправильно. - person zeekay; 21.08.2011
comment
Я также использую Firefox и не вижу такого поведения. - person zeekay; 21.08.2011
comment
Возможно, ошибочное дополнение, я полагаю? - person zeekay; 21.08.2011
comment
Это чистая установка xubuntu с firefox. Не знаю, почему это происходит. При использовании браузера ссылок я могу получить доступ к request.user. - person seler; 21.08.2011
comment
Такое же поведение в хроме - anonymususer - person seler; 21.08.2011
comment
Здесь отлично работает в хроме. И сафари, если уж на то пошло. - person zeekay; 21.08.2011
comment
Это ошибка в django 1.4. Спасибо за помощь. - person seler; 21.08.2011
comment
@seler, если ответ зикея помог вам решить вашу проблему, вы должны принять его. Кроме того, если вы обнаружили проблему, вы должны добавить ее как ответ, а не просто комментарий. - person agf; 22.08.2011

arrow_upward
1
arrow_downward

Попробуйте использовать декораторы из django.contrib.auth.decorators. В вашем urls.py вы можете сделать что-то вроде:

from django.contrib.auth.decorators import login_required

...
url(r'^something/?$', login_required(MyDetailView.as_view()))
...

Для проверки разрешений вы можете использовать декоратор premissions_required. Для получения дополнительной информации ознакомьтесь с документацией: https://docs.djangoproject.com/en/dev/topics/auth/#the-login-required-decorator

person Drekembe    schedule 21.08.2011
comment
использование декораторов login_required или permissions_required не вариант. Мне нужно проверить разрешения/вход в систему после получения объекта: если объект имеет логическое поле registration_required, установленное на True, только зарегистрированные пользователи смогут видеть страницу, другие будут перенаправлены на страницу входа (пример поведения из django.contrib.flatpages). - person seler; 21.08.2011
comment
Ах. В этом случае я бы порекомендовал написать свои собственные представления, поскольку они, похоже, требуют более конкретного поведения. Нет смысла пытаться впихнуть это поведение в общие представления. - person Drekembe; 21.08.2011
comment
В общих представлениях нет ничего плохого. Проблема возникает в представлениях на основе классов, в общих представлениях на основе функций она работает отлично. Поскольку в django появились [общие] представления на основе классов, кажется правильным использовать их. - person seler; 21.08.2011

arrow_upward
0
arrow_downward

Я использую миксины для представлений на основе классов. В этом случае вы можете сделать это следующим образом:

Общие представления и аутентификация на основе классов Django

person cor    schedule 12.03.2014