Django, redirect all non-authenticated users to landing page
I have a django website with many urls and views. Now I have asked to redirect all non-authenticated users to a certain landing page. So, all views must check if user.is_authenticated() and return to a new set of landing pages.
Can it be done in a pretty way, instead of messing with my views.py / urls.py that much?
9 Answers 9
There is a simpler way to do this, just add the «login_url» parameter to @login_required and if the user is not login he will be redirected to the login page. You can find it here
You can use Middleware.
Something like this will check user auth every request:
Also, don’t forget to enable it in settings.py
another option is to add it to your urls.py patterns, see this answer
As of Django 1.10, the custom middleware classes must implement the new style syntax. You can use the following class to verify that the user is logged in while trying to access any views.
This can be done with middleware.
I’ve found a really nifty djangosnippet that does exactly what you are asking for. You can find it here, and it looks like:
After authentication it’s not redirecting to next page in django
I am not able to redirect to next page in Django after authentication.I have already defined next in views.py file and calling that value but in URL its redirecting to Login page with URL as below:
And without @login_required its working properly
After putting Username and Password redirecting to
1 Answer 1
You’ve got some different things going on that are affecting it.
You have settings.LOGIN_URL set to login/ but your urls.py file directs / to the login function. For this answer, I’m changing settings.LOGIN_URL to / to match your url file.
Your login/views.py file only needed a few changes now that we’ve updated the urls.py file.
I cleaned up some of the import statements that were unnecessary and I removed redirect_field_name=’next’ from @login_required because ‘next’ is the default value.
We need to check both the POST and GET objects to get the next parameter.
The biggest change is after we authenticate the user and validate that they’re active, instead of return HttpResponseRedirect(settings.LOGIN_REDIRECT_URL) we just do return HttpResponseRedirect(‘/home’) or send them to the next url that we grabbed from the POST / GET data.
Once you have that, unless there’s something else I’m missing, @login_required should properly redirect to your login page if the user isn’t logged in.
Redirect if already logged in through Django urls?
Currently I use these patterns to log in and out
Inspite of having LOGIN_REDIRECT_URL = ‘/profile/’ in my settings.py, Django does not send me to /profile/ if I want to access /login/ when I’m already logged in.
Can I somehow redirect in the URL patterns of the auth system? I’m reluctant to write a custom view for that.
6 Answers 6
I use something like this in my urls.py:
How about riding the Django login view?
Then add this little piece of code in that view:
If you want to do something else in template itself for the register user:
I ended up writing a decorator for such task.
Please take note that I’ve made it quick & dirty.
Looking at the source code on Github, the default login view provided by django.contrib.auth will only use LOGIN_REDIRECT_URL if the login form is submitted via a POST request, and it has no next parameter. (The docs mention this too).
If you want different behaviour, I’d recommend writing your own login view.
You could use this decorator
On your projects urls.py file ( url_patterns list), add redirect_authenticated_user=True as a parameter in login path like this:
Not the answer you’re looking for? Browse other questions tagged django or ask your own question.
Linked
Related
Hot Network Questions
Subscribe to RSS
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
site design / logo © 2021 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2021.9.16.40231
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.
Django: Redirect logged in users from login page
I want to set up my site so that if a user hits the /login page and they are already logged in, it will redirect them to the homepage. If they are not logged in then it will display normally. How can I do this since the login code is built into Django?
10 Answers 10
I’m assuming you’re currently using the built-in login view, with
or something similar in your urls.
You can write your own login view that wraps the default one. It will check if the user is already logged in and redirect if he is, and use the default view otherwise.
and of course change your urls accordingly:
The Django 1.10 way
For Django 1.10, released in August 2016, a new parameter named redirect_authenticated_user was added to the login() function based view present in django.contrib.auth [1].
Example
From that file, the relevant part within the urlpatterns variable definition is the following, which uses the already mentioned redirect_authenticated_user parameter with a True value:
The Django 1.11 way
For Django 1.11, released in April 2017, the LoginView class based view superseded the login() function based view [2], which gives you two options to choose from:
/usr/local/lib/python3.6/site-packages/django/contrib/auth/views.py:54: RemovedInDjango21Warning: The login() view is superseded by the class-based LoginView().
Example
From that file, the relevant part within the urlpatterns variable definition is the following, which again uses the already mentioned redirect_authenticated_user parameter with a True value, but passing it as an argument to the as_view method of the LoginView class:
Документация Django 3.0
Django предоставляет возможности аутентификации и авторизации пользователей, обычно этот механизм называют системой аутентификации, т.к. эти функции связаны.
User objects¶
Основные атрибуты пользователя:
Создание пользователей¶
Самый простой способ создать пользователя – использовать метод create_user() :
Создание суперпользователя¶
Суперпользователя можно создать с помощью команды createsuperuser :
Смена пароля¶
Django не хранит пароль в открытом виде, хранится только хеш (смотрите раздел о работе с паролями ). Поэтому не советуем менять пароль напрямую. Именно по этой причине пользователь создается через специальную функцию.
Пароль можно сменить несколькими способами:
manage.py changepassword *username* offers a method of changing a user’s password from the command line. It prompts you to change the password of a given user which you must enter twice. If they both match, the new password will be changed immediately. If you do not supply a user, the command will attempt to change the password whose username matches the current system user.
Вы можете изменить пароль программно, используя метод set_password() :
Changing a user’s password will log out all their sessions. See Сброс сессии при изменении пароля for details.
Authenticating users¶
request is an optional HttpRequest which is passed on the authenticate() method of the authentication backends.
Права доступа и авторизация¶
Django comes with a built-in permissions system. It provides a way to assign permissions to specific users and groups of users.
Эта система используется админкой Django, но вы можете использовать её и в своем коде.
Админка использует проверку прав следующим образом:
Права доступа по умолчанию¶
When django.contrib.auth is listed in your INSTALLED_APPS setting, it will ensure that four default permissions – add, change, delete, and view – are created for each Django model defined in one of your installed applications.
Модель Permission редко используется напрямую.
Группы¶
Модель django.contrib.auth.models.Group предоставляет возможность группировать пользователей, добавляя им набор прав доступа. Пользователь может принадлежать нескольким группам.
Программное создание прав доступа¶
Кроме добавления своих прав доступа через класс Meta модели, вы также можете создать их напрямую. Например, создадим право доступа can_publish для модели BlogPost в приложении myapp :
Proxy models need their own content type
In older versions, proxy models use the content type of the concrete model.
Кеширование прав доступа¶
The ModelBackend caches permissions on the user object after the first time they need to be fetched for a permissions check. This is typically fine for the request-response cycle since permissions aren’t typically checked immediately after they are added (in the admin, for example). If you are adding permissions and checking them immediately afterward, in a test or view for example, the easiest solution is to re-fetch the user from the database. For example:
Proxy models¶
Proxy models work exactly the same way as concrete models. Permissions are created using the own content type of the proxy model. Proxy models don’t inherit the permissions of the concrete model they subclass:
In older versions, permissions for proxy models use the content type of the concrete model rather than content type of the proxy model.
Аутентификация в запросах¶
Как авторизовать пользователя¶
Следует отметить, что любые данные установленные в анонимной сессии будут сохранены в сессии пользователя после его авторизации.
Данные пример показывает как вы можете использовать обе функции authenticate() и login() :
Selecting the authentication backend¶
When a user logs in, the user’s ID and the backend that was used for authentication are saved in the user’s session. This allows the same authentication backend to fetch the user’s details on a future request. The authentication backend to save in the session is selected as follows:
In cases 1 and 2, the value of the backend argument or the user.backend attribute should be a dotted import path string (like that found in AUTHENTICATION_BACKENDS ), not the actual backend class.
Как отменить авторизацию пользователя¶
Следует отметить, что функция logout() не выбрасывает никаких ошибок, если пользователь не был ранее авторизован.
Ограничение доступа для неавторизованных пользователей¶
Прямой путь¶
The raw way to limit access to pages is to check request.user.is_authenticated and either redirect to a login page:
… или отображение сообщения об ошибке:
Декоратор login_required¶
Для краткости кода вы можете использовать декоратор login_required() :
Функция login_required() делает следующее:
По умолчанию, в параметре «next» строки запроса хранится путь, по которому должен быть перенаправлен пользователь в результате успешной аутентификации. Если вам потребуется использовать другое имя для этого параметра, то воспользуйтесь необязательным аргументом redirect_field_name декоратора login_required() :
The login_required decorator does NOT check the is_active flag on a user, but the default AUTHENTICATION_BACKENDS reject inactive users.
Примесь LoginRequired ¶
Вы можете установить любой из параметров AccessMixin для управления обработкой неаутентифицированных пользователей:
Just as the login_required decorator, this mixin does NOT check the is_active flag on a user, but the default AUTHENTICATION_BACKENDS reject inactive users.
Ограничение доступа для авторизованных пользователей с помощью дополнительной проверки¶
Для ограничения доступа пользователям на основе определённых прав или какой-либо другой проверке, вам следует выполнять те же действия, что описаны выше.
You can run your test on request.user in the view directly. For example, this view checks to make sure the user has an email in the desired domain and if not, redirects to the login page:
Декоратор user_passes_test() принимает для необязательных аргумента:
Вы можете переопределить метод test_func() класса для того, чтобы указать тест, который будет выполнен. Далее, вы можете указать любой параметр AccessMixin для настройки обработки неаутентифицированных пользователей:
Цепочка из UserPassesTestMixin
Если TestMixin1 вызовет super() и примет результат в работу, то TestMixin1 не будет больше работать в одиночку.
Декоратор permission_required¶
Довольно частой задачей является проверка наличия определённого права у пользователя. Для решения этой задачи Django предоставляет удобный декоратор permission_required() :
codename>» (т.е., polls.can_vote для права на модель в приложении polls ).
Декоратор также может принимать перечисление прав, в этом случае пользователь должен обладать всеми правами для того, чтобы получить доступ к представлению.
Следует отметить, что декоратор permission_required() также принимает необязательный аргумент login_url :
This also avoids a redirect loop when LoginView ’s redirect_authenticated_user=True and the logged-in user doesn’t have all of the required permissions.
Примесь PermissionRequiredMixin ¶
This mixin, just like the permission_required decorator, checks whether the user accessing a view has all given permissions. You should specify the permission (or an iterable of permissions) using the permission_required parameter:
Вы можете установить любые параметры AccessMixin для изменения обработки неаутентифированных пользователей.
Вы также можете переопределить эти методы:
Перенаправление неаутентифицированных запросов в CBV представлениях¶
class AccessMixin ¶ login_url ¶
Сброс сессии при изменении пароля¶
If your AUTH_USER_MODEL inherits from AbstractBaseUser or implements its own get_session_auth_hash() method, authenticated sessions will include the hash returned by this function. In the AbstractBaseUser case, this is an HMAC of the password field. Django verifies that the hash in the session for each request matches the one that’s computed during the request. This allows a user to log out all of their sessions by changing their password.
The default password change views included with Django, PasswordChangeView and the user_change_password view in the django.contrib.auth admin, update the session with the new password hash so that a user changing their own password won’t log themselves out. If you have a custom password change view and wish to have similar behavior, use the update_session_auth_hash() function.
update_session_auth_hash (request, user)¶
This function takes the current request and the updated user object from which the new session hash will be derived and updates the session hash appropriately. It also rotates the session key so that a stolen session cookie will be invalidated.
Представления аутентификации¶
Использование представлений¶
Существует несколько разных методов для реализации данных представлений в вашем проекте. Самым простым способом будет подключение схемы URL из django.contrib.auth.urls в вашу схему, например:
Это действие добавить следующие шаблоны URL:
Представления добавляют имя для URL для упрощения ссылок на них. Обратитесь к документации на URL для получения детальной информации по использованию именованных шаблонов URL.
Если вам требуется больше контроля над вашими URL, вы можете указывать специальное представление в вашей схеме URL:
Все представления для аутентификации¶
Имя URL: login
Обратитесь к документации на URL для получения информации по использованию именованных шаблонов URL.
Attributes:
extra_context : Словарь с контекстными данными, которые будут добавлены в текущий контекст, перед его передачей в шаблон.
Enabling redirect_authenticated_user can also result in a redirect loop when using the permission_required() decorator unless the raise_exception parameter is used.
Here’s what LoginView does:
If you have customized authentication (see Customizing Authentication ) you can use a custom authentication form by setting the authentication_form attribute. This form must accept a request keyword argument in its __init__() method and provide a get_user() method which returns the authenticated user object (this method is only ever called after successful form validation).
Отмена авторизации пользователя.
Имя URL: logout
Attributes:
Контекст шаблона:
Отменяет авторизацию пользователя, затем перенаправляет на страницу авторизации.
Имя URL: Значения по умолчанию нет
Необязательные аргументы:
Имя URL: password_change
Позволяет пользователю изменить его пароль.
Attributes:
Контекст шаблона:
Имя URL: password_change_done
Страница, отображаемая после того, как пользователь изменил свой пароль.
Attributes:
Имя URL: password_reset
Позволяет пользователю сбросить свой пароль, генерируя одноразовую ссылку, которая может быть использована для сброса пароля, и отправляя её на зарегистрированную электронную почто пользователя.
If the email address provided does not exist in the system, this view won’t send an email, but the user won’t receive any error message either. This prevents information leaking to potential attackers. If you want to provide an error message in this case, you can subclass PasswordResetForm and use the form_class attribute.
Пользователь, отмеченный флагом отменённого пароля (см. set_unusable_password() ), не может запросить сброс пароля. Так сделано, чтобы предотвратить неправильное использование при работе с внешними источниками аутентификации, например, с LDAP. Следует отметить, что они не получат никаких сообщений об ошибках, так как это вскрыло бы наличие аккаунта, и никакого сообщения на почту не будет отправлено.
Attributes:
Контекст шаблона:
Контекст шаблона электронной почты:
Пример registration/password_reset_email.html (шаблон тела письма):
Такой же контекст используется для шаблона заголовка сообщения. Заголовок должен быть представлен одной строкой простого текста.
Имя URL: password_reset_done
The page shown after a user has been emailed a link to reset their password. This view is called by default if the PasswordResetView doesn’t have an explicit success_url URL set.
Если предоставленный адрес электронной почты не существует в системе, пользователь не активирован или имеет деактивированный пароль, то пользователь будет перенаправляться на это представление, но никаких писем ему отправляться не будет.
Attributes:
Имя URL: password_reset_confirm
Представляет форму для ввода нового пароля.
Keyword arguments from the URL:
Attributes:
extra_context : Словарь с контекстными данными, которые будут добавлены в текущий контекст, перед его передачей в шаблон.
The reset_url_token class attribute was added.
Контекст шаблона:
Имя URL: password_reset_complete
Представление, которое информирует пользователя об успешном изменении пароля.
Attributes:
Вспомогательные функции¶
Перенаправляет на страницу аутентификации и, в случае её успешного прохождения, затем перебрасывает на другой URL.
Обязательные аргументы:
Необязательные аргументы:
Встроенные формы¶
Если вы не желаете использовать встроенные представления, но и формы переписывать не хотите, то система аутентификации предоставляет несколько встроенных форм, расположенных в django.contrib.auth.forms :
Форма, используемая в интерфейса администратора, для изменения пароля пользователя.
Принимает user в качестве первого неименованного параметра.
Форма для аутентификации пользователя.
Принимает request в качестве первого неименованного аргумента, который сохраняется в экземпляре формы для использования подклассами.
Например, позволяем всем пользователям проходить аутентификацию, невзирая на их статус активности:
Или позволяем только некоторым активным пользователям проходить аутентификацию:
Форма, через которую пользователь может менять свой пароль.
Форма для генерации и отправки одноразовой ссылки для сброса пользовательского пароля.
send_mail (subject_template_name, email_template_name, context, from_email, to_email, html_email_template_name=None)¶
By default, save() populates the context with the same variables that PasswordResetView passes to its email context.
Форма, которая позволяет пользователю изменять свой пароль без ввода старого пароля.
Форма, используемая в интерфейсе администратора для изменения информации о пользователе и его списка прав.
A ModelForm for creating a new user.
Аутентификационные данные в шаблонах¶
Пользователи¶
Права¶
Here’s a more complete example of checking permissions in a template:
Также позможен поиск прав с помощью выражения <% if in %>. Например:
Управление пользователями в интерфейсе администратора¶
Создание пользователей¶
Вы должны видеть сылку на «Пользователи» в разделе «Auth» на главной странице интерфейса администратора. Страница «Добавить пользователя» отличается от других страниц интерфейса, так как она требует, чтобы вы ввели имя пользователя и пароль перед тем как дать вам возможность редактировать остальные поля модели.
Также следует отметить, что если вам нужен пользоватедль, который бы позволил создавать пользователей с помощью интерфейса администратора, вам следует дать ему право на добавление пользователей и право на изменение пользователей (т.е., права «Добавить пользователя» и «Изменить пользователя»). Если пользователь обладает правом создания пользователей, но не имеет права на их редактирование, тогда он не сможет создавать пользователей. Почему? Потому что, если у вас есть право на создание пользователей, у вас есть возможность создать суперпользователей, которые могут в свою очередь, изменять других пользователей. Таким образом, Django требует наличие прав на добавление и изменение пользователей в целях безопасности.
Продумайте как вы позволяете управлять правами. Если вы предоставите обычному пользователю право на редактирование пользователей, это будет означать то же самое, что и предоставление ему прав суперпользователя, так как он сможет повысить права пользователей, включая себя!