Django: Tweaking @login_required decorator

Question

I want to begin a private Beta for my website. I have a splash page where a user can enter a code to then access the rest of the site. Currently, all the other site pages (except the splash page) consist of a series of redirects set up by requiring user login (via @login_required decorator).

I want both logged in users and people who enter the Beta Tester code to be able to access the rest of the site. That means that I can't just use the decorator for all my views.

Should I alter the @login_required decorator itself? I'm more tempted to just do the following (I added a session variable if user enters correct code on splash page).

def view_name(request):
    user=request.user  
    if not user.id or not request.session.get('code_success'):
           return HttpResponseRedirect('/splash/')

Does this seem reasonable? I'd hate to have to repeat it for all my views

Brendan

Steve Mayne · Accepted Answer · 2013-01-31T08:28:47.237

36

Write your own decorator - it's fairly straight forward. In fact, if you look at the Django source for login_required, you should be able to fiddle around with a copy for your own purposes.

def my_login_required(function):
    def wrapper(request, *args, **kw):
        user=request.user  
        if not (user.id and request.session.get('code_success')):
            return HttpResponseRedirect('/splash/')
        else:
            return function(request, *args, **kw)
    return wrapper

edited Jan 31 '13 at 08:28

answered Apr 15 '11 at 15:09

Steve Mayne

22,285
4
49
49

Hi Steve, this seems like a good solution. I tried it out. First, I got an traceback telling me that renderer() was taking an argument. I then tried to add optional args/kwargs (renderer(*args, *kwargs)) and I got a practically indecipherable traceback that claimed there were MiddleWare errors. I then stripped renderer() from the overall function defintion, leaving just wrapper. That worked, though it's not recognizing request.session.get('code_success') – Ben Apr 15 '11 at 15:54
I've edited the solution (for others who see it) - does it look correct now? – Steve Mayne Apr 15 '11 at 17:15
yeah it works now, Steve. I have one question, though. When I look at other decorators, I often see this ////return wraps(func)(wrapper)///. It doesn't seem like it the wraps function would be relevant here, but I've seen a similar tutorial where it's used. What's the story there? – Ben Apr 15 '11 at 17:39
I'm not sure I've seen cases where that's done - do you have an example? – Steve Mayne Apr 15 '11 at 19:22
Link to Django source: https://docs.djangoproject.com/en/dev/_modules/django/contrib/auth/decorators/#login_required – Marshall Aug 11 '16 at 19:04

score 4 · Answer 2 · answered Apr 15 '11 at 15:06

4

I would recommend using a middleware instead. That will make it easier to drop once you move out of your private beta. There are a couple examples of login required middlewares on djangonsippets:

http://djangosnippets.org/snippets/1220/
http://djangosnippets.org/snippets/136/

I would recommend taking one of those and tweaking it to include you beta code logic.

answered Apr 15 '11 at 15:06

Mark Lavin

24,664
5
76
70

Hi Mark, that makes sense. I haven't fiddled around with using the non-standard middleware yet. The RequireLoginMiddleWare is cool and definitely would have saved me some time. I'm going to try these both out. Thanks! – Ben Apr 15 '11 at 15:13

pymen · Answer 3 · 2016-09-01T12:22:49.267

HOW to re-use (tweak) internal Django login_required

For example, you need to allow access to page for only users who passed login_required checks and also are Coaches - and (save) pass coach instance to you view for further processing

decorators.py

from django.contrib.auth.decorators import login_required
from django.core.urlresolvers import reverse
from django.http import HttpResponseRedirect

from profiles.models import CoachProfile


def coach_required(function):
    def wrapper(request, *args, **kwargs):
        decorated_view_func = login_required(request)
        if not decorated_view_func.user.is_authenticated():
            return decorated_view_func(request)  # return redirect to signin

        coach = CoachProfile.get_by_email(request.user.email)
        if not coach:  # if not coach redirect to home page
            return HttpResponseRedirect(reverse('home', args=(), kwargs={}))
        else:
            return function(request, *args, coach=coach, **kwargs)

    wrapper.__doc__ = function.__doc__
    wrapper.__name__ = function.__name__
    return wrapper

views.py

@coach_required
def view_master_schedule(request, coach):
    """coach param is passed from decorator"""
    context = {'schedule': coach.schedule()}
    return render(request, 'template.html', context)

score 0 · Answer 4 · answered Apr 15 '11 at 15:14

0

I would create a guest account and login people that enter the Beta Tester code to that account. Something along these lines:

def beta_code_accepted(request):
    guest_user = User.objects.get(username='beta_guest')
    login(request, guest_user)

Once your beta is complete, just disable the splash view.

answered Apr 15 '11 at 15:14

mif

1,121
8
5

Right, but I also want the guest user to be able to register a full account. Normally, I redirect from register page for logged in users. I guess that I can allow logged in users to register and this would work. I don't see a problem with this, right? – Ben Apr 15 '11 at 15:26
The problem here is that I have logic in other parts of my application that depend on the {{user.is_authenticated}} context variable. I don't want beta guests to be able to have perm to certain things. I'd then have to add a permission layer on top of this methodology. – Ben Apr 15 '11 at 16:05
1

I see. Maybe you can modify the register page to check for logged-in guest users. If you detect a guest account, show them a message that suggests to register for a full account or continue as guests. – mif Apr 15 '11 at 16:15

Django: Tweaking @login_required decorator

4 Answers4

Linked