3

I'm trying to check if user.is_authenticated() or if user.has_perm() but it seems impossible extending django Class-based genering views. The only method I found where the request appears is 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)

there I found that request.user is instance of AnonymusClass no matter if I'm logged in or not.

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

so checking for authentification or perms will always fail:

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

I've tried overriding other methods such as get_object(), get_context_data() adn others. I each of them there is self.request attribute available, but user is still Anonymus.

So my question is: How on Earth am I supposed to check if user is logged in using Class-based views!?

Does it mean I have to (go back and) use function-based views?

I'm using Python 2.7.1+ and Django version 1.4 pre-alpha SVN-16627




In response to EVIAAC post: Using login_required or permissions_required decorators is not an option. I need to check for permissions/logon after I retrieve object: if object has boolean field registration_required set to True only reqistered users will be able to see the page, others will get redirected to logon page (example behavior borrowed from django.contrib.flatpages).

seler
  • 8,127
  • 3
  • 38
  • 53

3 Answers3

2

Works properly in 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

Possibly a bug?

zeekay
  • 49,858
  • 13
  • 107
  • 105
  • That must be someting else. I;ve created testproject with testapp with testmodel with testview using django 1.3 and it's still same result. Maybe there is someting I'm missing. Could you please post you full test code? – seler Aug 21 '11 at 15:21
  • That is the full code. The only thing missing is the urlconf, which is as you'd expect: `url(r'^test', TestView.as_view())` – zeekay Aug 21 '11 at 15:27
  • It appears that this bug is present only using firefox which is quite odd. :/ – seler Aug 21 '11 at 15:32
  • Checked in another 1.3 project as well, not sure what you could be doing wrong. – zeekay Aug 21 '11 at 15:33
  • I also use Firefox, and don't see this behavior. – zeekay Aug 21 '11 at 15:33
  • Possibly an errant add-on I suppose? – zeekay Aug 21 '11 at 15:37
  • It's clean instalation of xubuntu with firefox. No idea why this is happening. While using links browser I can acces request.user. – seler Aug 21 '11 at 15:43
  • Same behavior in chrome - anonymususer – seler Aug 21 '11 at 15:52
  • Works fine in chrome here. And safari, for that matter. – zeekay Aug 21 '11 at 16:05
  • It's a bug in django 1.4. Thank you for your help. – seler Aug 21 '11 at 16:52
  • @seler, if zeekay's answer helped you solve your problem, you should accept it. Also, if you've found the problem, you should add it as an answer, not just a comment. – agf Aug 21 '11 at 20:13
1

Try using the decorators from django.contrib.auth.decorators. In your urls.py, you can do something like:

from django.contrib.auth.decorators import login_required

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

For checking permissions, you can use the premissions_required decorator. For more info, check out the docs: https://docs.djangoproject.com/en/dev/topics/auth/#the-login-required-decorator

Drekembe
  • 2,398
  • 2
  • 13
  • 11
  • using `login_required` or `permissions_required` decorators is not an option. I need to check for permissions/logon after I retrieve object: if object has boolean field `registration_required` set to `True` only reqistered users will be able to see the page, others will get redirected to logon page (example behavior from `django.contrib.flatpages`). – seler Aug 21 '11 at 14:42
  • Ah. In that case, I'd recommend writing your own views, since they seem to require more specific behavior. No sense in trying to shoehorn this behavior into generic views. – Drekembe Aug 21 '11 at 14:49
  • There's nothing wrong about generic views. The problem appears in class-based views, in function-based generic views it works perfectly. Since django has introduced class-based [generic] views it seems proper to use them. – seler Aug 21 '11 at 14:53
0

I use mixins for class based views. In this case, you can do it like this:

Django Class-Based Generic Views and Authentication

Community
  • 1
  • 1
cor
  • 3,194
  • 22
  • 45