Работа с пользователями

[d1gi]

Давно витает мысль написать компоненты по работе с юзерами, а также затем оформить бандл для Symfony2 на данный момент начал формулировать описание каким функционалом в целом должна обладать подсистема работы с юзерами

мысли начал выкладывать сюда http://smart-core.org/wiki/Users

если кому интересно, предлагаю додумать каким функционалом еще должен обладать сабж

 

[alekciy]

Рекомендую разделить понятие "юзер" (аккаунт) и "человек". "Человек" это буквально человек. Одна единица человеческого существа. Юзер/аккаунт это некая виртуальная сущность и у одного человека их может быть много. Я предлагаю использовать термин именно юзера, а не аккаунт, т.к. считаю, что то, что обычно разработчики называют юзером является парой логин-пароль. И такое понимание сложилось просто чисто исторически. Не будем его ломать, так и оставляем.

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

Ни каких опросов провайдер и гаданий на кофейной гуще. Юзер хочет залогиниться, значит явно указывает какого провайдера нужно пнуть по поводу его учетки.

Складывать юзеров в разные таблицы тоже не следует. Зачем? Этим мы только усложняем бизнес-логику приложения закладывая в неё кучу багов. На вскидку юзер зарегался, у него один user_id, подвердился, переносим его в другую таблицу, user_id сменился. В схеме с биллинг-сервером (центральное хранилище юзеров) можно поиметь много секса. Опять же коллизии в user_id.

 

[Absinthe]

alekciy виртуальным юзер может быть только в книжках писателей-фантастов.

 

[fixxxer]

Рекомендую разделить понятие "юзер" (аккаунт) и "человек"...

Типичный пример того, как программисты любят все усложнить и нагородить три листа абстракций на пустом месте.

(У самого такое бывает, но я с этим борюсь).

 

[Koc]

Давно витает мысль написать компоненты по работе с юзерами, а также затем оформить бандл для Symfony2

не понял, а чем решение искаропки не устраивает + какие-нить FOSUserBundle, FOSTwitterBundle, EtcpasswdOauthBundle, FpOpenIdBundle?

 

[alekciy]

Типичный пример того, как программисты любят все усложнить и нагородить три листа абстракций на пустом месте.

Я всегда двумя руками за более простые решения. Но в системе с центральным биллингом такие решения оправданы. Как минимум на одно большом проекте приходилось сталкиваться с тем, что отсутствие такое разделения в архитектуру привело к проблемам в будущем. Когда человек в одной системе вошел под одним аккаунтом, на другом, под другим и на центральном биллинге сервере было два не привязанных к одному человеку аккаунта. А потом по мере развития проекта оказалось что бац, их нужно склеивать в один.

 

[fixxxer]

Это довольно редко надо. Решается вынесением авторизации в отдельный сервис типа ms passport / oauth.

 

[alekciy]

Это довольно редко надо. Решается вынесением авторизации в отдельный сервис типа ms passport / oauth.

Да, не часто. Но если оно изначально заложено архитектурно, то оно будет с ходу искаропки. На простых же проектах оно просто будет вырождаться в простой случай один-к-одному. Поэтому таки да, это усложнение системы, но оно вполне себе имеет право на жизнь.

 

[fixxxer]

А чем в sf2 oauth+openid не "искаропки"?

 

[alekciy]

А чем в sf2 oauth+openid не "искаропки"?

Если базироваться на фреймворке, то вполне искаропки.

 

[d1gi]

добавил схемы БД http://smart-core.org/wiki/Users, теперь вроде как более предметно уже смотрится затея

Koc, бандлы это хорошо, но требуется функционал которого в них нет... по этому сторонние бандлы буду юзать на сколько это будет возможно.

 

[Koc]

но требуется функционал которого в них нет...

какой именно?

 

[d1gi]

Koc
"Работа в мультисайтовом режиме. Здесь есть такая особенность: предположим используется удалённая база юзеров, а разные проекты на других серверах используют её для аутентификации, регистрации и т.д. В таком случае каждый проект имеет собственные настройки ролей для каждого юзера. В тоже время проект может быть мультисайтовым т.е. в зависимости от домена использовать разные настройки и вот в этом случае один и тотже юзер может считаться зареганым в системе, а может и нет. Т.е. на стороне проекта, будет некая «локальная БД аккаунтов» в которой будет копия юзеров из основной БД."

 

[d1gi]

alekciy
мысль с "людьми и аккаунтами" не ясна
с регистрацией во временную таблицу тоже сложностей не вижу... пока юзер не подтвердил емаил он и зайти не сможет в систему.

 

[alekciy]

alekciy
мысль с "людьми и аккаунтами" не ясна

Есть центральный биллинг-сервер С, есть два проекта А и Б. Клиент в проект А сделал вход через OpenID от яндекса, а в проект Б через твиттер. На сервере С две независимых аккаунта. А потом приходит задача от бизнеса - два аккаунта это один человек и изменение данных в одном аккаунте должны приводить к изменению в другом. Если это изначально не заложить в архитектуру, то начинается пиление движка. А это можно заложить изначально.

Т.е. у юзеров во временной таблице относительно системы user_id просто нет? В общем юзер не просто не может войти в систему, но для систему по сути не существует?

 

[d1gi]

alekciy
ваша идея с центральным сервером плотно пересекается с идеей, которая процитирована в этом посте: http://phpclub.ru/talk/threads/Работа-с-пользователями.72390/#post-646580

на данный момент именно эта мысль для меня является основной пример структуры БД выложил в вики


с регистрацией всё верно - пока не подтвердил - юзера в системе нет.

 

[alekciy]

alekciy
ваша идея с центральным сервером плотно пересекается с идеей, которая процитирована в этом посте: http://phpclub.ru/talk/threads/Работа-с-пользователями.72390/#post-646580

Значит выражена она не очень очевидно. Кстати, я про домены ни чего не говорю, я про схему "один_человек-много_аккаунтов", один-ко-многим. С доменами это уже следующий слой. Но вообще fixxxer я поддержу, функционал крайне специфичный и на практике действительно нужен только в больших проектах. Но я за данную схему просто потому, что на простом сайта она работает в вырожденном (т.е. частный случай) виде. Поэтому приоритет данного функционала делать высоким есть смысл только если есть такой большой проект на руках.

 

[d1gi]

alekciy, просто вы называете "есть два проекта А и Б", эти проекты могут различаться тем, что находятся на разных доменах.

ммм... под аккаунтом, что именно вы подразумеваете? по схемам БД видно, что у меня есть понятие "учетная запись" таблица users, и есть "логины" в таблице users_logins, это значит что у каждого юзеров может быть произвольное кол-во способов представиться системе, по паре логин/пароль, facebook, gplus, twitter и т.д. т.е. юзер сам настраивает все возможности представиться, например как тут https://sourceforge.net/account/openid

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

 

[alekciy]

Да, имею в виду в таком же духе.