Как исправить неверный вывод request.user в django?

Question

[Andrei1penguin1]

Доброго времени суток, при создании авторизации отказался от велосипеда LoginView, так как переопределение и переделывание под то, что мне надо, займет гораздо больше времени, чем если написать самому
К сути проблемы:
Вот некоторые поля модели

class User(AbstractUser):
    username = models.CharField(max_length=100, null=True, blank=True, unique=True)
    login = models.CharField(max_length=100, verbose_name="Логин", blank=False, default="NULL")
    password = models.CharField(max_length=100, verbose_name="Пароль", blank=False, default="Null")

Кусок кода из вьюшки авторизации:

from django.views.generic import View
from django.contrib import auth
from myapp.models import User


class Login(View):
    def post(self, request):
        login = request.POST.get("username", "")
        password = request.POST.get("password", "")
        login_objects = [login.get("login") for login in User.objects.all().values()]
        if login in login_objects:
            if User.objects.filter(login = login).values()[0].get("password") == password:
                user = auth.authenticate(login=login, password=password)
                auth.login(request, user)
                try:
                    return render (request, "page.html")
                finally:
                    return redirect("url_page")

Также есть зарегистрированный суперпользователь

И в любом месте в любом время request.user выдает админа, даже AnonymousUser получить не удается

Что делать?

Comments

[Ilya Chichak]

1) почему храните пароль в открытом виде?
2) почему логин, раз уж до этого дошло, не уникальный?
3) почему не используете формы?
4) зачем перебирать пользователей если authenticate возвращает найденного по login-password пользователя или None, если ничего не нашел?

при создании авторизации отказался от велосипеда LoginView

если все сделать правильно, а не писать свои велосипеды, LoginView будет занимать около 5-6 строк и работать будет куда эффективнее и быстрее

[Andrei1penguin1]

Ilya Chichak, шифрование пароля ещё не сделал, оно будет
Логины используются уникальные, это видно из первого if
В данном случае написать несколько строк быстрее, чем выделять отдельный файл на форму
Метод authenticate я обнаружил недавно, не успел переделать код
Мне нужно свое шифрование, свои поля в юзере без поля username, свои шаблоны, свои ошибки и нужен лучший контроль над кодом

[Andrei1penguin1]

Dr. Bacon,
Потому что они обязательно заполняются в регистрации, нуль поставлено, чтобы не ругалось django
Тут соглашусь, нужен способ побыстрее, что вы можете предложить?
Почему нет понимания, все прекрасно работает

[Andrei1penguin1]

Dr. Bacon, кастомные решения мне совершенно не подходят

[Andrei1penguin1]

Dr. Bacon, что я конкретно не понял

[Ilya Chichak]

1) с шифрованием прям нормально справляется джанговый PasswordField, причем еще и выбор алгоритма есть и возможность написать свой алгоритм - никто не запрещает, чо уж
2) если упороться и сделать двустороннее шифрование, типа получается пользователь по логину, расшифровывается пароль, сравнивается с введеным - это будет отдельный шедевр. любое шифрование и дешифрование - CPU bound процесс (ибо математика). следвательно, даже если запустить все это в 10 воркеров, я, подобрав логин по времени ответа, смогу запустить 11 процессов, которые будут долбить с нужным логином и всяким мусором в пароле и все, сайт прилег
3) нет, уникальности логина НЕ видно исходя из

login = models.CharField(max_length=100, verbose_name="Логин", blank=False, default="NULL")

где нет "unique=True". а строковый "NULL" - это вообще прекрасно. Если хотябы открыть документацию, там найдется, что а) строковые поля не стоит делать nullable - придется разруливать проблемы, когда в одной строке будет None, а в другой '' б) при все том же создании пользователей, если не будет указан login - новые пользователи будут все с login="NULL". и как с этим жить - непонятно
в случае, если будут создаваться логины-пароли не через веб, а из консоли или каким либо другим образом, эти "if" - не спасут
4) тут проверяется, что login есть в базе, но не проверяется его уникальность
5) зачем выделять отдельный файл на форму?

избавляясь от шифрования пароля автоматически пропадает возможность правильно сравнивать пароли за константное время. что открывает дверь для подбора пароля

по поводу лучшего контроля над кодом:

class AuthForm(forms.ModelForm):
    def __init__(*args, **kwargs):
        self.user = None
        super().__init__(*args, **kwargs)

    def clean():
        cleaned_data = super().clean()
        self.user = authenticate(cleaned_data['login'], cleaned_data['password'])
        if not self.user:
            self.add_error('password', 'Password is incorrect')
        return cleaned_data

    class Meta:
        model = get_user_model()
        fields = ('login', 'password')

def auth(request):
    form = AuthForm(request.POST or None)
    if form.is_valid():
        login(request, form.user)
        return redirect('...')
    return render(request, 'template.html', {'form': form, ...})

где здесь недостаточно контроля за кодом?

Хотя, возможно (только возможно), хочется прям все реализовать самому. Ок. Только зачем тогда Django?
Фигачь на фласке или чем-нибудь модном, типа FastAPI. Хочешь джаговый ОРМ - peewee

а вообще, для лучшего контроля над кодом, надо читать исходники - будешь понимать, как это работает, не будешь бояться это использовать

[Andrei1penguin1]

Да, возможно есть смысл присмотреться к формам, но это позже, сейчас мне необходимо сделать, чтобы работало хоть как-то, времени немного
И я все равно не понимаю, почему проверка уникальности логина через перебор базы не так надёжно, как через параметр unique?

[Andrei1penguin1]

Dr. Bacon, я подошёл близко к решению проблемы, но мне нужна ваша помощь
В django.contrib.auth есть файл backends, в нём есть класс ModelBackend, а в этом классе, непосредственно, функция authenticate
Я проверил, юзера берёт верно, дальше идёт условие, при выполнении которого возвращается юзер, а значит, решается проблема:

if user.check_password(password) and self.user_can_authenticate(user):

Второе условие возвращает True, а сравнение паролей выдаёт False, и я не знаю, почему, так как пароль в бд совпадает с тем, что получает данная функция
Но больше всего мне непонятно, почему check_password принимает один аргумент, в то время как, согласно документации, должен принимать пароль, введённый пользователем и зашифрованный пароль из базы данных, то есть два аргумента
Проблему решил, стерев первое условие, так как фактически оно уже написано в моей вьюхе, но редактирование кода django, как я считаю, не совсем грамотное решение

[Andrei1penguin1]

Спасибо, но я все равно не понимаю, почему этот метод возвращает False, переданный же пароль совпадает с паролем из бд

def check_password(self, raw_password):
        """
        Return a boolean of whether the raw_password was correct. Handles
        hashing formats behind the scenes.
        """
        def setter(raw_password):
            self.set_password(raw_password)
            # Password hash upgrades shouldn't be considered password changes.
            self._password = None
            self.save(update_fields=["password"])
        return check_password(raw_password, self.password, setter)

Answer 1

[Rodion]

Наверное, всё дело в том, что у Вас не передопределена настройка AUTH_USER_MODEL. Предлагаю покопать в этом направлении, поскольку, если мне память не изменяет, в объект запроса пользователь попадает на основе именно той настройки.

Comments

[Andrei1penguin1]

Эта настройка у меня определена, дело в том, что пользователь создаётся, проходит авторизацию, если логин есть и если пароль подходит к логину, то есть все хорошо
Только не создаётся пользовательская сессия, и даже после перезапуска сервера остаётся сессия админа
Причем в middleware все вроде бы определено верно

Answer 2

[alternativshik]

написана какая-то дичь.

Comments

[Andrei1penguin1]

Ну и что же вы не смогли понять?