Как стать автором
Обновить

Комментарии 13

Лучше все-таки явно укажите в заголовке, что речь про Django.
Поддерживаю, сначала тоже в код тупил, потом думал что это косяк программеров кто работал ДО нашего главгероя, и только когда посмотрел маленький тег в подвале постав понял что речь о поведении django…
А какая ещё бизнес-логика может стоять за этой проверкой?
Может, это средство забанить юзера, а реализуется оно установкой нового пароля и блокировкой сброса пароля.
Чтобы забанить пользователя, есть флаг is_active. А вот какая тут может быть бизнес-логика, придумать не могу.
А почему вы после соц. регистрации не кинули пользователя на форму добивания данных, или не сгенерировали ему пароль сами? Тем более, раз у вас есть возможность отвязать социальную сеть от учетной записи.
Чтобы пользователю не заморачиваться. Если он регистрируется через соц. сети, то с большой вероятностью он и входить будет через них. Тем более, что основная аудитория проекта — люди технически неграмотные, которые даже не знают, что такое пароль и куда его вводить (я не утрирую).

Отвязать соц. сеть — это скорее исключительный случай. Если он произойдет, думал я, так пользователь восстановит пароль. Я ж не знал, что так нельзя.
Так в чем сложность была сгенерировать пароль самостоятельно? Когда пользователь попробовал бы войти по логину/паролю то отослали бы его на форму восстановления пароля, либо на форму ввода нового пароля.
Если вы делаете регистрацию через несколько соц. сетей то хорошим тоном считается сделать ассоциацию учетных записей (чтобы не было отдельно записи для вконтакте и отдельной для фейсбук). Объединить это все лучше в нормально профиле, который не привязан к какой-то конкретной социалке. Django Social Auth как и Python Social Auth хоть и говорят, что могут автоматически проводить ассоциацию учеток, но честно предупреждают, что работает это не во всех случаях и по-хорошему бы сделать отдельную форму.
Собственно, сложности нет. Так и сделаю. Меня в данной ситуации больше всего это стыдливое continue возмутило. По мне, так лучше б уж Exception вылетал — отловить проще.

А ассоциация, конечно, и так делается. Не идеально, есть там что еще поправить.
Еще один хороший пример как не нужно делать imhonet.ru/
Была авторизация по openid, переделали дизайн и убрали ее, точнее не работала, а потом и вовсе убрали.
Писал пару раз в сапорт, по поводу восстановления аккаунта — не ответили.

Всегда нужно генерировать пароль пользователю заходящему через соц. сеть.
«Благодарите» человека по имени jezdez, который закрыл вот этот баг таким коммитом.
+… versionchanged:: 1.4
+ Users flagged with an unusable password (see
+ :meth:`~django.contrib.auth.models.User.set_unusable_password()`
+ will not be able to request a password reset to prevent misuse
+ when using an external authentication source like LDAP.
Открываем документацию… О чудо! Все документированно!!!

docs.djangoproject.com/en/1.7/topics/auth/default/#django.contrib.auth.views.password_reset

Users flagged with an unusable password (see set_unusable_password() aren’t allowed to request a password reset to prevent misuse when using an external authentication source like LDAP. Note that they won’t receive any error message since this would expose their account’s existence but no mail will be sent either.

Почему нельзя сбросить пароль если он изначально не задан? Если пользователю запрещен вход кроме как через LDAP/VK/FB/.., если, например, у нас приложение с жесткой завязкой на FB API, то логично, что ему НЕЛЬЗЯ иметь локальный вход ибо последствия непредсказуемы.
Да кто ж читает ее, эту документацию?!

А если серьезно — да, mea culpa. Спасибо. Как ни странно, если с Андроидом я как-то приучился сначала читать доки, а потом уже лезть в исходники, то с Django как-то не заладилось. И вроде документация у них очень хорошая, но поиск по ней… Google в ней лучше ориентируется, нежели их собственное решение. Или это я не умею его готовить?
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации