django-ulogin
django-ulogin copied to clipboard
marazmiki
улучшить тестовый проект
Прошу немного улучшить тестовый проект с целью продемонстрировать возможность привязывания (и удаления) нескольких аккаунтов разных провайдеров к 1 и тому же пользователю джанги
Т.е. в настоящее время тестовый проект позволяет протестировать следующее: я могу войти через VK, система создаст пользователя. Далее, я выйду и войду через Twitter, система создаст нового пользователя.
Как мне бы хотелось: я вошел через VK и, не выходя из VK, вошел через Twitter, система во втором случае не сделала отдельный аккаунт, а просто привязала твиттер к первому аккаунту. А у меня появилась бы возможность удалять связь моего аккаунта с соцсетью (например, если мне потребовалось сменить твиттер или я решил отказаться от его дальнейшего использования).
Прошу немного улучшить тестовый проект с целью продемонстрировать возможность обычной регистрации (пусть система сгенерирует и покажет форму регистрации на базе указанных обязательных и не обязательных полей). Некоторые пользователи принципиально не хотят связывать свои аккаунты на сайтах с аккаунтами соцсетей по соображениям безопасности и они предпочтут ввести username/email и пароль. В настоящее время логин UUID, необходимо или разрешить пользователям его менять или в это поле всем пользователям автоматически прописывать email. (Или, к примеру, ставить на поле email индекс, чтобы была проверка уникальности данных, хранимых в этом поле)
Если кто-то из пользователей наткнется на этот баг, знайте - в настоящее время данный плагин подходит
- только если все потенциальные пользователи имеют аккаунты в соцсетях (юзернейм длинный нечитаемый UUID, они не будут его вводить вручную)
- только если ваши пользователи достаточно пунктуальны и помнят, с какого конкретно провайдера они заходят на ваш сайт (если они как я - то скоро на каждого пользователя появится куча дублей, сегодня из твиттера зайдет, завтра с фэйсбука) Вообщем, система интересная, но требует допиливания...
Доброго времени суток,
Спасибо за обстоятельный и развёрнутый отзыв о django-ulogin. Попробую ответить по всем пунктам билета, но в самую первую очередь, дабы избежать недопонимания в дальнейшем, проиллюстрирую процесс работы django-ulogin:
- На какой-либо странице нашего django-сайта вставляется виджет ulogin, в котором указываются все необходимые нам поля.
- Пусть пользователь, зашедший на сайт, кликает на иконку любого провайдера.
- Открывается popup-окошко ulogin, где пользователь идентифицирует себя и авторизует свой доступ к тому или иному провайдеру
- Сервер ulogin выполняет POST-запрос к нашему django-сайту на URL страницы postback и передаёт ему всю информацию, которая нам нужна для работы (см. п.1)
- Страница postback определяет, входил ли кто с этой записью раньше.
- Если входил (есть модель
ULoginUser, связанная с identity, которую вернул ulogin), то находит джанго-пользователя, который входил и аутентифицирует его. - Если не входил, то создаётся новая запись (опять же модель
ULoginUser) и к ней привязывается текущий request.user (если пользователь анонимный, то User сперва создастся, а потом аутентифицируется).
- Если входил (есть модель
- Ну и делается редирект на начальную страницу :-)
Прошу немного улучшить тестовый проект с целью продемонстрировать возможность привязывания (и удаления) нескольких аккаунтов разных провайдеров к 1 и тому же пользователю джанги
Проблем с привязыванием нескольких провайдеров к одному auth.User нет: т.к. вновь созданный экземпляр ULoginUser будет связываться с текущим request.user, нужно всего лишь выводить виджет всем пользователям, а не только анонимным. Не думаю, что изменение
{% if request.user.authenticated %}{% ulogin_widget %}{% endif %}
на
{% ulogin_widget %}
достойно упоминания в демо-проекте: всё-таки самую базовую функциональность он предоставляет.
А вот удаление (отвязывание того или иного аккаунта от django-пользователя) - идея интересная, спасибо. Запишу на будущее.
Прошу немного улучшить тестовый проект с целью продемонстрировать возможность обычной регистрации (пусть система сгенерирует и покажет форму регистрации на базе указанных обязательных и не обязательных полей).
Это лишнее и вообще не джанго-вэй :-) Философия Джанго гласит, что нужно делать маленькие, атомарные приложения, которые делают что-то одно, но хорошо. Если django-ulogin умеет аутентифицировать пользователей через соц. сети, зачем ему замахиваться на таких гигантов, как django-registration, django-accounts или django-userena? С другой стороны, никто не запрещает пользоваться любым из этих "регистраторов" вместе с django-ulogin. Вся интеграция будет сделана на уровне шаблонов.
Некоторые пользователи принципиально не хотят связывать свои аккаунты на сайтах с аккаунтами соцсетей по соображениям безопасности и они предпочтут ввести username/email и пароль.
Странная точка зрения, я считаю. Ну да ладно, не мне судить :-)
В настоящее время логин UUID, необходимо или разрешить пользователям его менять
Опять же выходит за рамки задач django-ulogin. Я придерживаюсь точки зрения, что лучше десять маленьких приложений, чем одно большое. Так и поддерживать легче, и запутаться сложнее. И подойдёт лучше.
UUID в качестве юзернейма, конечно, печально. Но это самое простое, что удалось придумать. К тому же, и в README, и в демо-проекте есть пример переименования на лету. Подобный код можно использовать не только в сигналах, но и в собственных вьюхах.
..или в это поле всем пользователям автоматически прописывать email. (Или, к примеру, ставить на поле email индекс, чтобы была проверка уникальности данных, хранимых в этом поле)
Зачем?!
только если все потенциальные пользователи имеют аккаунты в соцсетях (юзернейм длинный нечитаемый UUID, они не будут его вводить вручную)
Это не замена django-registration сотоварищи, а дополнение
только если ваши пользователи достаточно пунктуальны и помнят, с какого конкретно провайдера они заходят на ваш сайт (если они как я - то скоро на каждого пользователя появится куча дублей, сегодня из твиттера зайдет, завтра с фэйсбука)
Вкратце резюме такое:
- Идея с отвязываем аккаунтов от текущего юзера - клёвая и нужно будет её реализовать
- Регистрация и редактирование учётных записей (включая юзернейм) - лишнее
- Изменять демо-проект нерационально (ну, разве только если Вы займётесь :-))
-
нужно всего лишь выводить виджет всем пользователям, а не только анонимным
Странно, у меня почему-то не получается...
Я зашел через VK, далее, не выходя из VK, через фэйсбук и ожидал увидеть два новых кортежа в табличках django_ulogin_uloginuser и communitybase_userinfo в phppostgreadmin, но не увидел... там остали только те два кортежа с момента регистрации через VK...
-
Ещё вспомнил, что в гайде установке не написано про добавление 'django.core.context_processors.request', по умолчанию его нет (TEMPLATE_CONTEXT_PROCESSORS по умолчанию вообще нет в settings.py), ну это так, мелкий баг документации...
-
Еще есть одна проблема - у меня не получается сделать кнопки крупными и изменить набор провайдеров. Скопировал из демо-проекта в settings.py ULOGIN_SCHEMES, он их не видит (ставлю большие кнопки - так и остаются маленькими, набор провайдеров то же не меняется), а если я напишу ULOGIN_DISPLAY = 'button', то работает ок (показывает большие кнопки)
или при использовании виджета, мне надо явно прописывать ему нужную schem'у?
-
наверное, лучше использовать uuid1, это позволит исключить малейшую ошибку с генерацией неуникального ключа в случае многосерверных конфигураций
-
а что если добавить ункальное uuid поле к юзерам и использовать его, а не юзернейм? это потребует изменения таблички юзеров и не так красиво выглядит, но зато пропадет желание менять их... (конкретно в моем случае это было бы удобно, я планирую использовать Couchbase, то есть проще 1 раз сформировать идентификатор и не менять его, чем следить потом за тем, чтобы обновлять это не только в джанге, но и в других местах) а менять логин (юзернейм) - это как-то не очень правильно, мне кажется... мне бы хотелось, чтобы пользователь был обязан его ввести вместе с email вне зависимости от того, каким способом он регистрируется... ну а uuid пусть будет отдельно, обеспечить его уникальность в многосерверных конфигурациях проще... это так... потоковые мысли...
Оффтопик:
Странная точка зрения, я считаю. Ну да ладно, не мне судить :-)
Многие разработчики не любят mail.ru/вконтакт/одноклассники/фэйсбук (возможно, зависть (дуров украл идею, какой он плохой...) к некоторым из них, возможно пренебрежение (mail.ru/одноклассники для блондинок) по отношению к другим), зато любят гугл и твиттер... А фанаты 4chan (и других имиджбордов) не будут регистрироваться через соцсети, потому что боятся деанонимизации... Тоже не разделяю их мнение, но довольно часто сталкиваюсь с подобной реакцией, поэтому логично иметь какое-то запасное решение (обычную регистрацию)... Если ulogin в данном случае никак не конфликтует с другими аппами - отлично...
Странно, у меня почему-то не получается...
Дико извиняюсь, ввёл в заблуждение :-(
Та логика, которую я описывал в предыдущем комментарии, была реализована для конкретного проекта и по моему недосмотру в репозиторий (и, разумеется, релиз django-ulogin на pypi) не попала. Тут действительно каждый раз создаются пользователи. Обещаю исправиться.
в гайде установке не написано про добавление 'django.core.context_processors.request'
Спасибо, добавлю.
у меня не получается сделать кнопки крупными и изменить набор провайдеров. Скопировал из демо-проекта в settings.py ULOGIN_SCHEMES, он их не видит (ставлю большие кнопки - так и остаются маленькими, набор провайдеров то же не меняется), а если я напишу ULOGIN_DISPLAY = 'button', то работает ок (показывает большие кнопки)
Похоже на ошибку. Вы используете master-версию из гитхаба, или ставили из pypi? Если второе, то там несколько бородатая версия, которая существенно отличается от того, что в гитхабе (руки не доходят бампнуть). В частности, поддержки мультивиджетов там нет.
наверное, лучше использовать uuid1, это позволит исключить малейшую ошибку с генерацией неуникального ключа в случае многосерверных конфигураций
Пожалуй, лучше подождать до первой жалобы на коллизию,а там уже действовать по обстоятельствам :-)
а что если добавить ункальное uuid поле к юзерам и использовать его, а не юзернейм? это потребует изменения таблички юзеров и не так красиво выглядит, но зато пропадет желание менять их...
К auth.User? Ни в коем случае. Один апп вмешается, другой вмешается, третий (при этом каждый ничего не будет знать о других). Что получится-то в итоге?
а менять логин (юзернейм) - это как-то не очень правильно, мне кажется... Нет ничего плохого в том, чтобы менять логин. Главное, чтобы он был уникальным, вот и всё.
мне бы хотелось, чтобы пользователь был обязан его ввести вместе с email вне зависимости от того, каким способом он регистрируется...
Это реалии лично Вашего проекта, к другим они могут быть неприменимы :-) У модели User поле email вообще необязательное:
>>> from django.contrib.auth.models import User
>>> u = User.objects.create(username='demo1')
>>> u
<User: demo1>
>>> u.pk, u.email, u.username
(4L, '', 'demo1')
Согласитесь, глупо его требовать для регистрации там, где оно не нужно? :-) Я считаю, что маленькое reusable-приложение не стоит затачивать под какой-то один проект.
Вы используете master-версию из гитхаба, или ставили из pypi?
скорее всего, это был pypi (из гитхаба стараюсь ничего не ставить, если работает из pypi) так как не всегда понятно, насколько стабильная там версия)
Пожалуй, лучше подождать до первой жалобы на коллизию,а там уже действовать по обстоятельствам :-)
не дождётесь :-) факторы:
- маленькая распространенность ulogin
- преимущественное использование 1 сервера (там вообщем-то без разницы, что использовать)
- низкая вероятность прохождения жалобы по цепочке (от посетителей владельцам сайта, от владельцев сайта программистам, от программистов разработчикам (сюда)), на каждом этапе проще забить, чем передавать дальше ввиду единичной жалобы :-)
вообщем, я сообщил, а вы уж сами решайте, надо или нет... http://stackoverflow.com/a/1785670 :-)
К auth.User? Ни в коем случае. Один апп вмешается, другой вмешается, третий (при этом каждый ничего не будет знать о других). Что получится-то в итоге?
Да, в таких случаях обычно просто префиксы юзают и всё (какой-нибудь там x_ulogin_uuid, к примеру)... но это, вероятно, не Django-way, если он важен - тогда не делайте так :-) вспомнилось, что в SAP есть такие договоренности, если начинается с X-Z - это объекты заказчика... возможно, Djangо' сообществу стоило бы перенять опыт других систем...
Просто, как мне кажется, если каждый апп будет добавлять по ещё одной табличке к табличке пользователя - запутаться в структуре базы будет в разы сложнее... Ну, да, ладно =)
Про необязательность поля email я сам не понимаю, почему так? Я считаю это багом... В большинстве случаев я рассматриваю email таким же вторым логином, который должен быть уникальным для всех пользователей.
Если честно, email я считаю одним из важных полей. Если пользователь его не указал - практически невозможно помочь ему восстановить пароль, невозможно отправить какую-то рассылку с новостями проекта, наверное, было бы неплохо иметь возможность самому добавлять какие-то поля, которые нужно вывести для обязательного или опционального заполнения (т.е. сверх тех полей, которые предлагает uLogin, иметь возможность добавить свои в список обязательных и опциональных, например, поле телефона может быть весьма полезно)...
В uLogin я немного разочаровался...
При попытке войти через гугл он просит информацию о моих контактах
The site ulogin.ru is requesting access to your Google Account for the product(s) listed below.
Email address - ... Google Contacts
Зачем uLogin мои контакты? Я не хочу, чтобы владельцы uLogin или владельцы сайта, где я регистрируюсь, знали, какие email'ы находятся у меня в записной книжке... На других сайтах при попытке войти через гугл, таких вопросов не задают (я расцениваю это как просьбу поделиться клиентской базой или просьбу добровольно запустить троян :-)). Но раз уж uLogin получает доступ - почему она не делится информацией с владельцем сайта о контактах пользователей? Или я что-то не правильно понял и ничего, кроме контактов самого пользователя (его личных, а не его знакомых), не передаётся?
Вероятнее всего, буду использовать дальше django social auth (django) и velruse (pyramid). Но желаю дальнейших успехов в разработке таких систем как loginza/ulogin/Janrain Engage/Gigya и плагинов к ним - конкуренция на пользу конечным пользователям. :-)
Ну, то что архитектура django.contrib.auth в целом не фонтан, известно всем давным-давно :)
Один из core-девелоперов джанги, Jacob Kaplan Moss, опубликовал примерный вектор развития auth. Вероятно, что в следующих версиях так и будет.
А что касается e-mail... Вот прямо сейчас я делаю систему, в которой вся аутентификация идёт через мобильные телефоны. Адрес e-mail не используется в принципе :-)
Зачем uLogin мои контакты? Я не хочу, чтобы владельцы uLogin или владельцы сайта, где я регистрируюсь, знали, какие email'ы находятся у меня в записной книжке
Лучше этот вопрос задавать создателям ulogin, а не сторонним разработчиков плагинов :-) По всей видимости, приложение так зарегистрировали. И судя по документации, ulogin в ответ присылает ограниченный набор полей (фамилия, имя, e-mail, аватарка, фотография, страничка соц. сети, телефон). Никакие контакты не присылает. Да и не нужны они для аутентификации. Следовательно, владельцы сайтов знать ничего не будут.
По поводу контактов... Не думаю, что их сохраняют: для функционирования они не нужны, а ulogin себя позиционирует как честный проект, который уже некоторое время существует. Попробуйте задать им этот вопрос на reformal?
Интересные планы) Спасибо за ссылку.
Про ulogin - наверное, действительно, просто так получилось... Но выглядит со стороны это, конечно, немного зловеще :-) Но для меня сейчас это не так актуально. Я подумал и решил использовать собственные приложения соцсетей (у uLogin, если я правильно понял, такое возможно по запросу и платно) через django social auth. Это позволит в будущем не зависеть от конкретной реализации (от uLogin) и использовать все возможности интеграции социальных сетей с сайтом, т.е. более гибкое решение. Единственное, что жалко - виджетик неплохой у uLogin... Надо будет что-нибудь похожее придумать...
Оффтопик:
А что касается e-mail... Вот прямо сейчас я делаю систему, в которой вся аутентификация идёт через мобильные телефоны. Адрес e-mail не используется в принципе :-)
ваша система интересна, к сожалению, может поспособствовать продвижению цензуры в интернете (что меня как либертарианца совсем не устраивает), но диктаторы будут довольны... :-)
дело в том, что анонимные имэйлы можно сделать бесплатно (на каждый сайт свой и установить между ними связь будет непросто), что позволит свободно выражать свои мысли на любые темы... то есть у администрации сайта есть возможность проверить, что это именно тот самый человек, который заводил аккаунт, но нет возможности проверить, кто этот человек в реальной жизни... и это гарантирует свободу общения и безопасность...
в вашей системе обеспечить такое же будет сложнее... придётся тратить время и деньги на поиск анонимных симок (в идеале 1 симка на 1 сайт, что, впрочем, всё равно даст возможность при желании оператора связать их по координатам), т.е. используя симку, будет возможным отследить местонахождение каждого пользователя...
возможно, эта система будет полезна в ряде случаев (на сайтах госучреждений), но, надеюсь, ею не будут злоупотреблять, так как она во многом будет ставить под удар безопасность пользователей...