Django user authentication system provides login_ The required function uses the decorator to restrict access to the page, using login_ The page of the view function of the required decorator can be accessed only by logged in users. login_ The required decorator is defined in Django contrib. auth. In the decorators module, is is is encapsulated inside_ Authenticated to determine whether the user logs in.
If you have logged in, enter the internal view and execute the view function logic.
If you are not logged in, you will be redirected to setting LOGIN_ The address specified by the URL configuration item.

1,login_required decorative function view

from django.contrib.auth.decorators import login_required

@login_required(login_url=reverse('users:login'))
def userinfo_view(request):
	return render(request, "user_center_info.html")

login_ The required decorator can decorate a view function (the function that receives the request parameter and returns the response response). If the user in the request has logged in, it will return the view function and return the response. If the user in the request is an anonymous user, it will return the redirection page.

2,login_required decorative class view
login_ The required decorator can directly decorate the function view, but cannot directly decorate the class view.

login_ The essence of the required decorator is to pass the function object to be decorated into login_ In the required () function, the function returns the decorated function object, so you can use login as long as you can get the function object of the function view_ Required to decorate.

As of class view_ The view () method is to turn the class view into a function view, as_ The return value of the view () method is a function object. If you want to use login_ The required decorator is used to decorate the class view, which can indirectly decorate as_ The return value of the view () method.

Next, let's talk about how to use decorators to decorate class views.

The first way is as_ The view () method is called when the url is configured, so you can decorate as when the url is configured_ The return value of the view () method.

# urls.py
re_path("info/$", login_required(views.UserCenterView.as_view()), name="info"),

# views.py
class UserInfoView(View):
	"""User center"""
	def get(self, request):
		"""Provide personal information interface"""
		return render(request, "user_center_info.html")

In the second way, when class inheritance, we can use super as_ The view () method calls as_view() method and get the function view, so we can also use login through class inheritance_ Required decoration as_view() returns a value.

# urls. Login is not used in py_ Required to decorate
re_path("info/$", views.UserCenterView.as_view(), name="info"),

Here are three schemes to realize the logic of the second method.

Scheme 1: override as in UserInfoView_ View () method, using login_required decoration super as_view() return value

# views.py
class UserCenterView(View):

    @classmethod
    def as_view(cls, **initkwargs):
        view = super().as_view()
        return login_required(view)   # Decoration method of class view

    def get(self, request: HttpRequest):
        """Open user center page"""
        return render(request, "user_center_info.html")

Summary: each page that needs to verify whether the user logs in needs to be rewritten as_view method.

Scheme 2: userinfoview - > LoginRequiredView - > view, rewrite as in LoginRequiredView_ View () method, using login_required decoration super as_view() returns a value.

# views.py
class LoginRequiredView(View):
	"""Verify that the user is logged in"""
	@classmethod
	def as_view(cls, *args, **kwargs):
		# Custom as_ In the view () method, call the as_ of the parent class. View() method
		view = super.as_view(*args, **kwargs)
		return login_required(view)

class UserCenterView(LoginRequiredView):
	"""User center"""
    def get(self, request: HttpRequest):
        """Open user center page"""
        return render(request, "user_center_info.html")

Summary: LoginRequiredView(object) depends on the View class View, but we will not use LoginRequiredView alone to create View instances, but only use LoginRequiredView to enhance the function of UserInfoView. Therefore, we do not need LoginRequiredView class to rely on View class View. For this demand, python has a habit of defining this class as Mixin class.

Scheme 3: use the MRO (method resolution order) feature of multi inheritance.

class LoginRequiredMixin(object):
    @classmethod
    def as_view(self, *args, **kwargs):
        view = super().as_view()
        return login_required(view)

class UserCenterView(LoginRequiredMixin, View):         #  mixin design pattern

    def get(self, request: HttpRequest):
        """Open user center page"""
        context = {
            "username": request.user.username,
            "mobile": request.user.mobile,
            "email": request.user.email,
            "email_active": request.user.email_active,
        }
        return render(request, "user_center_info.html", context)