Уникальная почта пользователя

[DrMartiner]

Доброго времени суток!

Сделайте, пожалуйста, уникальную почту пользователя: если такая почта уже есть, то при регистрации пользователь с такой же почтой не регистрируется, а авторизуется как существующий.

PS: это самое адекватное джанго-приложение для авторизации через соц. сети

[marazmiki]

Доброго,

Спасибо за тёплые отзывы, но я Вас, пожалуй, разочарую: эта задумка не очень ложится в идеологию работы django-ulogin. Всё-таки email - это точно такое же поле, как и first_name, например, поэтому оно оказаться быть неуникальным в рамках одной соц. сети (например, у разных жж-юзеров допускается один email).

К тому же, в каком-нибудь проекте e-mail вообще может не быть нужным, поэтому хардкодить дополнительные проверки, обрекая тем самым юзера на ввод ненужного в общем-то имейла - тоже идея так себе.

А вот idenity гарантирует уникальность.

Думаю, в Вашем случае лучше либо форкнуть django-ulogin, либо написать собственное приложение django_ulogin_email, которое подключалось бы к проекту и расширяло оригинальный django-ulogin. Навскидку, это новое приложение должно работать как-то так:

• Модель ULoginEmail с полем email и внешним ключом на django_ulogin.ULoginUser;
• Вьюшка EmailPostBackView, унаследованная от django_ulogin.views.PostBackView, в которой перекрыты методы handle_authenticated_user и handle_anonymous_user (это они отвечают за создание учёток);
• В urls.py подключить эту вьюху раньше оригинальной, чтобы запросы обрабатывала она.

В общем, частный случай вполне решаем, как мне кажется :-)

[DrMartiner]

Да, случай частный. Только сейчас подумал о том, что в случае Твиттера и Вконтакта пользователь указывает произвольную почту, никак не подтверждённую соц. сетью.
У меня авторизация по почте и паролю. Если 2 одинаковые почты, то будет падает с ошибкой:
"get() returned more than one User -- it returned 2! Lookup parameters were {'email': u'some@mail.com'}"

Сказать пользователю о том, что такая почта уже есть в случае Твиттера и ВК нет, т. к. её спрашивают на стороне uLogin.

Как бы вы решили задачу с уникальной почтой?

[DrMartiner]

Кстати, может быть, сделать опцию ULOGIN_UNIQUE_EMAIL (default=False):

if ULOGIN_UNIQUE_EMAIL:
  user, created = User.objects.get_or_create(email=email)
else:
  user = User(email=..., is_active=True, ...)

[marazmiki]

Как бы вы решили задачу с уникальной почтой?

Запретил бы пользоваться email в качестве логина :-) По-другому, кажется, никак в свете вышеозначенного. В общем-то, ulogin для того и придумывали, чтобы уйти от стандартной схемы "логин-пароль".

Да и вообще, поле email в auth.User неуникально и даже, кажется, на нём нет индексов. Использовать его как логин определённо не стоит. Если непременно надо аутентифицироваться по имейлу, лучше его писать в username. Он хотя бы уникальный и индексируемый.

Кстати, может быть, сделать опцию ULOGIN_UNIQUE_EMAIL (default=False):

Лучше не надо. Нехорошо общие решения подстраивать под частные.

[DrMartiner]

В том-то и дело, что не можем отказаться от авторизации по почте.
Лано, чтонить придумаю :)

Отличный сервис! Отличное приложение!

[stelzzz]

Здравствуйте!
Есть какие-то подвижки в этом направлении?
Приложение отличное, но тоже встала проблема с использованием e-mail в роли username.
Можно ли "вклиниться" в процесс авторизации на стадии, когда django-ulogin создаёт нового пользователя в системе? Чтобы использовать свою логику (в данном случае проверить поле e-mail от ulogin и username, в случае совпадения передать id этого пользователя, иначе - создать). Этот сигнал будет очень полезен для реализации подобных задач.

[marazmiki]

Доброго дня,

Я по-прежнему уверен, что использовать e-mail как идентификатор вредно. Поэтому никаких подвижек в этом направлении нет и не планируется.

С другой стороны, это приложение разрабатывалась во времена Django 1.3х и, соответственно, под стандартного User. В Django 1.5, как Вы, возможно, знаете, появилась штатная возможность использовать собственную модель вместо auth.User. В ней поля могут быть какими угодно и называться как угодно.

Вот в этом направлении двигаться стоит, правда, я пока не очень представляю как. Возможно, решение косвенным образом позволит решить и Ваши проблемы. Но лучше бы Вам всё же отказаться от мысли использовать e-mail как идентификато - коллизии возможны.

[stelzzz]

Согласен, вредно и не безопасно.
Поэтому и нужны какие-то точки в системе, которые можно было бы переопределять.
Например тут https://github.com/marazmiki/django-ulogin/blob/master/django_ulogin/views.py#L82
было бы удобно задавать свою логику:
К примеру для google, yandex, mailru создавать логин(или проверять существует ли пользователь) на базе email (у этих провайдеров он будет подтвержденным и уникальным), для vkontakte и других - создавать на какой-то другой базе.

Так приложение будет более гибким.

[marazmiki]

Приложение тем гибче, чем проще. Читайте - чем в нём меньше ветвлений и условностей =)

Лучше предоставить программисту возможность самому работать с сохраняемым объектом (а это сделать всё равно придётся в реалиях Django 1.5). Как он напишет, так и будет.