login_required y protección de vistas

A dashboard or profile page should only open for signed-in users. Django makes protecting those views simple and consistent. 🚧

The login_required decorator guards a view: anonymous visitors are bounced to the login page automatically.

Place @login_required right above your view function. That single line is all it takes to lock the page down.

When access is denied, Django redirects to the URL in LOGIN_URL. Set it in settings so the bounce lands on your login page.

The redirect adds a next query value with the original URL, so after login the user returns to the page they wanted. 🎯

For class-based views, use the LoginRequiredMixin instead of the decorator. List it first among the base classes.

The LoginRequiredMixin must come before the generic view in the class definition, or the protection will not apply.

Sometimes you want manual control. Read request.user.is_authenticated and branch yourself instead of using the decorator.

To require a specific right, not just any login, use permission_required. It checks the user holds the named permission.

In templates, wrap private links with user.is_authenticated so guests never even see buttons they cannot use.

Hiding a link is not real security. Always guard the view itself too, since users can type any URL directly.

You locked pages with login_required and LoginRequiredMixin, set LOGIN_URL, and learned to guard views, not just hide links. ✅