Так Шон больше по фронту. Я вообще всегда его считал фронт-энд разработчиком и удивлялся, когда что-то серверное у него находил.
И главное — это не class-based процессор, в нем прописаны проверки прав, и простой или неавторизованный пользователь просто не сможет создать нового пользователя. В данном случае эти проверки не перегрузить, а давать права всем подряд — не секурно.
1. Юзер может зайти сразу через HybridAuth, в первый раз — это создаст нового юзера MODX с привязанной соцсетью и случайным паролем.
Если потом админ поставит Login, то юзер сможет сбросить через него пароль и входить и по нему, и через соцсеть.
2. Login уже стоит, юзер входит\регистрируется через него, а потом привязывает соцсети в редактирвоании профиля.
Да, вот как раз сразу оба эти действия и надо было объединить, чтобы не приходилось делать или так, или так.
ОК, с этим ясно.
Ну я могу только поздравить авторов Login с таким решением. Еще один повод его не использовать.
Ну, писал его никто иной, как Шон МакКормик, а он как известно не последнее место в команде MODX занимал. Просто пакет старый, и тоже тогда еще не было class-based процессоров, а потом перепиливать не стали.
Раз уж я здесь сегодня глаза мозолю, то позволю себе еще один комментарий.
Для текущего юзера:
foreach ($modx->user->Services as $service) {
print_r($service->toArray());
}
Для любого другого юзера
$user_id = 10;
if ($user = $modx->getObject('modUser', $user_id)) {
$services = $user->getMany('Services');
foreach ($services as $service) {
print_r($service->toArray());
}
}
А почему в примере для остальных пользователей не написал просто foreach ($user->Services as $service) {…, а по старинке $user->getMany('Services');? Не привык еще к новому методу, или какие-то другие причины есть?
Первый пункт не совсем понятен. HybridAuth — самостоятельное дополнение, а не hook для Login. Они прекрасно работают вместе, и юзер, созданный через Login, может привязать к своему профилю соцсети и входить через них.
И без Login всё отлично работает — есть все нужные функции, включая редактирование профиля.
Василий, я не планировал тебя оскорбить, а просто вспомнил очень старый диалог здесь.
Саша Пекшев
11 месяцев назад
зачем делать hybdridAuth если уже у Безумкена это есть?
Николай Ланец
11 месяцев назад
ответ на комментарий пользователя Саша Пекшев
3. HybridAuth не работает совместно с другими средствами регистрации/авторизации, включая родной для MODX — Login. Элементарное доказательство — у него на сайте вход только через HybridAuth. А мой пакет полностью совместим и работает с Login. Вы можете в этом убедиться, скачав сборку или просто погоняя тестовый сайт. Так что если вас устраивают пакеты безумкина — это ваше дело. А меня качество и функциональность его пакетов не устраивает.
Саша Пекшев
11 месяцев назад
ответ на комментарий пользователя Николай Ланец
Да проблема с Login конечно у него есть, сам сталкивался с такой дилеммой и нехотя пришлось от Logina отказаться, хотелось бы увидеть отдельно как пакет ваш modHybridAuth, ведь я так понимаю он идет вместо с shopModx?
Зачем устанавливать Login, если у вас на сайте вход только через соцсети?
Вот в том-то и прикол, что не всегда люди хотят свои соцпрофили палить, и некоторые предпочитают обычную регистрацию. Не стоит исключать одно ради другого, это вместе дружит нормально.
Они прекрасно работают вместе, и юзер, созданный через Login, может привязать к своему профилю соцсети и входить через них.
А вот здесь, если можно, поподробней. Ты имеешь ввиду зарегиться юзером обычным способом, а потом в личном кабинете привязать соцпрофиль? Но у меня задача стояла чуть другая — обеспечить сразу регистрацию через Login. Зачем? А затем, чтобы не плодить два отдельных механизма. То есть есть Login-форма, через которую можно зарегиться обычным способом, а можно через нее зарегиться и социальным профилем. И вот тут как раз и всплывает та несовместимость, о которой я говорил: Login не использует родной процессор для регистрации пользователей, и следовательно не выполняются родные плагин-ивенты, когда бы можно было вклиниться в процесс регистрации. По этой причине в modHybridAuth входит сниппет-хук для Login-а.
Но в целом на мой пакет можно забивать, потому что он как и многие мои пакеты будет сопровождаться lowcontext-документацией и требованиями к программному уровню :)
P.S. Так, на заметку: не знаю, поправил ты или нет, но на modxcloud.com твой пакет барахлил из-за известных их проблем с сессиями, он у меня тупо не работал там.
Нет, не 1%. 1% — это только их комиссия. Плюс 1% за конвертацию WM (это так же их расходы, которые включены в конечный расход). Плюс комиссия конечной платежной системы.
Оплачивал Яндекс.Деньгами — 7% с платежа прогорело, на счет мой в юнитпее упало 93 копейки с рубля.
Но есть два НО:
1. В настройках аккаунта можно переложить комиссию на конечных покупателей до 100%. То есть все с платежа — ваше.
2. Зависит от того еще, на кого аккаунт, на физика или юрика. Если аккаунт на юрика, с того же яндекса конечная комиссия будет только 4%. Это ниже, чем у той же робокассы, которая 7% забирает.
Если здесь хотят только лирики, можно сносить нафиг топик и больше писать ничего не буду, так как все равно судя по всему некому. Все-таки для многих более популярные задачи — чекбоксы вставлять.
А если все же есть интерес к более глубоким MODX-технологиям, то уже спрашивайте что-нибудь, или хотя бы глупую лирику не разводите.
Вот, чисто пища для размышлений: список сниппетов, чанков и tv-полей проекта. Уверен, у многих на сайтах-визитках больше.
Да, теперь время будет. А то как раз эти три месяца и были заняты вот этим проектом.
Что еще вспомнишь? :)
На самом деле если уж хочешь типа подколоть, правильней было бы сказать «Колян, ды ты фигню показал. Вон у меня какие крупные проекты! Тот же хостинг для MODX-а, и еще вот куча всего...». Но ты-то знаешь, что это не идет в сравнение никакое. Конечно проект мы выложили пока сырой, но даже сейчас уже там технологий в разы больше, чем на вашем клауде, а по объему вообще сравнивать нечего. Чего только стоит запись видео с камеры пользователя на сервер на технологии WebRTC, с временными лимитами и т.п.
Так что если есть что по технической части сказать, то говори. А если хочешь просто типа поржать… Ну, в принципе, можешь ржать.
Дело не только в привычках, но и в различных методиках разработки. Я вот считаю, что все разработчики должны работать одновременно на едином проекте, а не на своих отдельных копиях, так как у каждого в отдельности может все работать, а когда сводишь все в одно, возникают как логические, так и технические ошибки. Когда все работают на одном проекте, тогда вероятность таких ошибок сильно снижается. Потом когда все ОК, тогда уже и сводишь гит и боевой проект.
Мы не программируем сейчас каждый в своей IDE. Все работают в админке в modxSDK.
Если интересно, я писал об этом здесь: modxclub.ru/blog/82.html
На хабре как-то была статья, типа «интуиция против средств тестирования». Там примеры приводились как разработчики, натыкаясь на баги, подключали средства выявления ошибок, и занимало это порой не мало времени. А другие разработчики основывались только на понимании своих проектов. Ему вот так сообщают об ошибке, он подумает немного, и потом лезет исправлять туда, где с большой вероятностью бага и находится. Причем в первом случае ребята часто одно лечили, другое колечили, а во втором случае человек сразу примерно знал где что может зацепить. И вот там и ставили вопрос, а действительно ли средства автоматизации тестинга и т.п. так хороши и необходимы?
Я не использую никакие такие средства. Весь проект держу в голове. Но я вот не представляю как бы мы это делали на чанках/сниппетах))) В процессе разработки много раз приходил к пониманию, что на чанках мы этого проекта просто не выполнили бы, или это заняло бы год, а не 3 месяца.
Да, там верстка рассчитана на минимум 1260px, и пока меньше и не будет. Таков дизайн, предоставленный заказчиком. В общем сейчас сайт не рассчитан на маленькие экраны. Это будет позже. Сейчас будет оттачиваться функциональная часть, а когда все будет боле менее отточено, будет под это рисоваться новый дизайн и будет новая верстка.
Только еще момент: таким образом нельзя установить свойства, которых еще нет у объекта. К примеру, если у объекта нет свойства test, то нельзя сделать так: $object->test = $value; Свойства test у объекта после этого просто не будет. Вот здесь как раз и придется использовать $object->set($key, $val), чтобы свойство было создано. За эту магию отвечают ООП-методы __set() и __get() у класса xPDOObject. И вот здесь как раз кроется самое интересное (для этого смотрите сорцы xPDO github.com/modxcms/xpdo/blob/master/xpdo/om/xpdoobject.class.php#L739 ). Дело в том, что в методах __get() и __set() сразу прописана работа со связями getOne()/setOne() и т.д. и т.п.
К примеру, можно сделать так: $profile = $user->Profile, что будет равнозначно $profile = $user->getOne('Profile'). Таким образом можно получить свойство $user->Profile->email, даже если именно в этот момент еще не был получен связанный объект modProfile для этого пользователя. Или вот так:
$user = $modx->newObject('modUser', array(
«username» => «NewUser»,
));
$profile = $modx->newObject(«modUserProfile», array(
«email» => $someEmail,
«password» => $somePass,
));
$user->Profile = $profile;
$user->save();
И будут записаны в БД и данные пользователя (modUser), и данные его профиля (modUserProfile).
А что мешает напрямую устанавливать значение свойства?
$user = & $modx->user;
$user->password = 12345;
$user->save();
И будет у вас в таблице в чистом виде пароль 12345.
Значения свойств не обязательно устанавливать через метод ->set(), где выполняются всякие модификации и т.п., их можно устанавливать напрямую, если само свойство у объекта уже есть. Это так же, как вы не установите $user->set('sudo', true);, так как там проверка, и если поле — sudo, то обламывается. Зато можно установить $user->sudo = true; $user->save();
И главное — это не class-based процессор, в нем прописаны проверки прав, и простой или неавторизованный пользователь просто не сможет создать нового пользователя. В данном случае эти проверки не перегрузить, а давать права всем подряд — не секурно.
Просто в разных случаях ты по разному написал, вот мне и стало интересно.
ОК, с этим ясно.
Ну, писал его никто иной, как Шон МакКормик, а он как известно не последнее место в команде MODX занимал. Просто пакет старый, и тоже тогда еще не было class-based процессоров, а потом перепиливать не стали.
А почему в примере для остальных пользователей не написал просто foreach ($user->Services as $service) {…, а по старинке $user->getMany('Services');? Не привык еще к новому методу, или какие-то другие причины есть?
Вот в том-то и прикол, что не всегда люди хотят свои соцпрофили палить, и некоторые предпочитают обычную регистрацию. Не стоит исключать одно ради другого, это вместе дружит нормально.
А вот здесь, если можно, поподробней. Ты имеешь ввиду зарегиться юзером обычным способом, а потом в личном кабинете привязать соцпрофиль? Но у меня задача стояла чуть другая — обеспечить сразу регистрацию через Login. Зачем? А затем, чтобы не плодить два отдельных механизма. То есть есть Login-форма, через которую можно зарегиться обычным способом, а можно через нее зарегиться и социальным профилем. И вот тут как раз и всплывает та несовместимость, о которой я говорил: Login не использует родной процессор для регистрации пользователей, и следовательно не выполняются родные плагин-ивенты, когда бы можно было вклиниться в процесс регистрации. По этой причине в modHybridAuth входит сниппет-хук для Login-а.
Но в целом на мой пакет можно забивать, потому что он как и многие мои пакеты будет сопровождаться lowcontext-документацией и требованиями к программному уровню :)
P.S. Так, на заметку: не знаю, поправил ты или нет, но на modxcloud.com твой пакет барахлил из-за известных их проблем с сессиями, он у меня тупо не работал там.
Оплачивал Яндекс.Деньгами — 7% с платежа прогорело, на счет мой в юнитпее упало 93 копейки с рубля.
Но есть два НО:
1. В настройках аккаунта можно переложить комиссию на конечных покупателей до 100%. То есть все с платежа — ваше.
2. Зависит от того еще, на кого аккаунт, на физика или юрика. Если аккаунт на юрика, с того же яндекса конечная комиссия будет только 4%. Это ниже, чем у той же робокассы, которая 7% забирает.
Через пять минут топик снесу, чтобы успели коммент прочитать.
Если здесь хотят только лирики, можно сносить нафиг топик и больше писать ничего не буду, так как все равно судя по всему некому. Все-таки для многих более популярные задачи — чекбоксы вставлять.
А если все же есть интерес к более глубоким MODX-технологиям, то уже спрашивайте что-нибудь, или хотя бы глупую лирику не разводите.
Вот, чисто пища для размышлений: список сниппетов, чанков и tv-полей проекта. Уверен, у многих на сайтах-визитках больше.
Что еще вспомнишь? :)
На самом деле если уж хочешь типа подколоть, правильней было бы сказать «Колян, ды ты фигню показал. Вон у меня какие крупные проекты! Тот же хостинг для MODX-а, и еще вот куча всего...». Но ты-то знаешь, что это не идет в сравнение никакое. Конечно проект мы выложили пока сырой, но даже сейчас уже там технологий в разы больше, чем на вашем клауде, а по объему вообще сравнивать нечего. Чего только стоит запись видео с камеры пользователя на сервер на технологии WebRTC, с временными лимитами и т.п.
Так что если есть что по технической части сказать, то говори. А если хочешь просто типа поржать… Ну, в принципе, можешь ржать.
Мы не программируем сейчас каждый в своей IDE. Все работают в админке в modxSDK.
Если интересно, я писал об этом здесь: modxclub.ru/blog/82.html
Я не использую никакие такие средства. Весь проект держу в голове. Но я вот не представляю как бы мы это делали на чанках/сниппетах))) В процессе разработки много раз приходил к пониманию, что на чанках мы этого проекта просто не выполнили бы, или это заняло бы год, а не 3 месяца.
Только еще момент: таким образом нельзя установить свойства, которых еще нет у объекта. К примеру, если у объекта нет свойства test, то нельзя сделать так: $object->test = $value; Свойства test у объекта после этого просто не будет. Вот здесь как раз и придется использовать $object->set($key, $val), чтобы свойство было создано. За эту магию отвечают ООП-методы __set() и __get() у класса xPDOObject. И вот здесь как раз кроется самое интересное (для этого смотрите сорцы xPDO github.com/modxcms/xpdo/blob/master/xpdo/om/xpdoobject.class.php#L739 ). Дело в том, что в методах __get() и __set() сразу прописана работа со связями getOne()/setOne() и т.д. и т.п.
К примеру, можно сделать так: $profile = $user->Profile, что будет равнозначно $profile = $user->getOne('Profile'). Таким образом можно получить свойство $user->Profile->email, даже если именно в этот момент еще не был получен связанный объект modProfile для этого пользователя. Или вот так:
$user = $modx->newObject('modUser', array(
«username» => «NewUser»,
));
$profile = $modx->newObject(«modUserProfile», array(
«email» => $someEmail,
«password» => $somePass,
));
$user->Profile = $profile;
$user->save();
И будут записаны в БД и данные пользователя (modUser), и данные его профиля (modUserProfile).
$user = & $modx->user;
$user->password = 12345;
$user->save();
И будет у вас в таблице в чистом виде пароль 12345.
Значения свойств не обязательно устанавливать через метод ->set(), где выполняются всякие модификации и т.п., их можно устанавливать напрямую, если само свойство у объекта уже есть. Это так же, как вы не установите $user->set('sudo', true);, так как там проверка, и если поле — sudo, то обламывается. Зато можно установить $user->sudo = true; $user->save();