Пишем модуль uLogin для Kohana 3.2

[Gero]

В Kohana вообще-то используется MVC. Формировать HTML-код в файле класса, реализующего логику — плохая практика.

[PomanoB]

Ну мне показалось нецелесообразным делать View для одной строчки подключения скрипта.
А Ulogin::factory()->render(), естественно должен вызываться из View. Я показал просто единый пример вызова и обработки

[Gero]

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

[Gero]

Кроме того, вы используете фреймворк, стандарты которого документированы. И даже есть пример в стандартной поставке, чтобы не было желания писать неправильно. Пренебрегать данными стандартами категорически нельзя, тем более новичкам.

[Fedcomp]

К сожалению фреймворк очень плохо задокументирован.

[Gero]

Не настолько, чтобы не заметить в нем наличие MVC )

[Fedcomp]

Это видно без документации)
Но когда я изучал этот фреймворк, документации было чуть больше чем ничего, все вещи приходилось выуживать в инете по кусочкам.
К счастью предпочитаю в большинстве проектов юзать симфони, хотя, когда нужно быстро сколотить небольшое приложение Kohana. Хочу попробовать silex для очень маленьких скриптов.

[Peretyaka]

if ($this->config['type'] == 'window')
   return '<a href="#" id="uLogin"><img src="http://ulogin.ru/img/button.png" width=187 height=30 alt="МультиВход"/></a><script src="http://ulogin.ru/js/widget.js?'.$params.'"></script>';
else
   return '<div id="uLogin"></div><script src="http://ulogin.ru/js/widget.js?'.$params.'"></script>';

Там не только скрипт, есть еще ссылка и href="#" — это довольно криво, в таких случаях лучше использовать span. Я не могу ее поменять для своего сайта из-за требований ulogin? Если так, то это еще можно было бы назвать каким-то аргументом.

В статье есть спорные моменты, этот не единственный, но в целом, если вынесите html в шаблон хотя бы ради соблюдения стандартов Kohana, то пойдет как мануал новичкам.

[PomanoB]

Обновил статью, добавил View'ы
HTML брал с официального сайта uLogin

[makingoff]

Ничего с собой не могу поделать. Читаю название этого фреймворка как «Какаха» и всё тут.

[Fedcomp]

PomanoB, значительно лучше сделать ULogin как модуль коханы.

[PomanoB]

Так статья этому и посвящена) Это и есть модуль к Kohana

[dohlik]

Очень приятно, что про Kohana на Хабре все еще пишут :)

Теперь немного критики, не факт, что объективной ;). Как-то все это выглядит, ммм, неООПшно, чтоли.

1. Зачем использовать file_get_contents(), когда есть Request::factory()? Он ведь и для внешних запросов может использоваться.
2. Заполнение данных пользователя после логина выглядит очень коряво. ORM предлагает различные плюшки типа ->values(), а также фильтрацию данных при передаче значений в модель.
3. Я для своего модуля аутентификации делал отдельные драйверы для каждого провайдера. Они уже сами разбирали входящие данные, зная о нужных полях. Соответственно в конфиге уже не придется хранить провайдерозависимые данные. Правда, в моем случае свободы у эти провайдеров было побольше (разные УРЛы, ключи и т.д.), но не суть. Потенциально возможностей для расширения больше получается (опять же, я не в курсе работы с uLogin, поэтому могу ошибаться)
4. Вьюшки уж очень замусоренные. Анализ конфигов вынесите в контроллер, и передавайте в шаблон уже готовые значения

Что касается статьи в целом.

1. Добавьте наверное в начале общее описание проблемы. Т.е. что есть в начале (аутентификация через Auth + желание прикрутить uLogin), чего не хватает и какие проблемы надо решить. А то Вы сразу в дебри кода ныряете, и непонятно, а чего собственно в процессе кодинга мы хотим добиться.
2. А Вы как-то решаете проблему дублирования пользователей? Имеется в виду вход одним юзером через разных провайдеров. Опять же, не знаю, помогает ли в этом как-то uLogin… Просто судя по таблице в БД связь 1-к-1 получается.
3. Было бы неплохо выложить код модуля на Github. И качать не придется, чтобы посмотреть отдельные куски.

[PomanoB]

1, 2, 4. Спасибо, исправил
3. Тут вся прелесть uLogin'а в том, что если не будет полей, помеченных как обязательные, он запросит их у пользователя. А нам на вход попадают все обязательные поля

1. Добавил
2. Ну тут уж ничего не сделать, если хочет заходить через разных, у них identity будут разные. Может только ники совпадут, и валидацию не пройдёт пользователь
3. Сделал

[Big_Shark]

Выложите модуль на GitHub чтобы можно было отправлять вам пулл реквесты и отписываться о ошибках, таким образом модуль достаточно быстро может видоизмениться в лучшею сторону.
Касательно модуля, я бы создал отдельную таблицу с зависимостями, это позволило бы привязать одновременно акаунты из разных соц сетей, и не вспоминать каждый раз при входе на сайт через какую соц сеть я создавал акаунт.

[PomanoB]

На github выложил, насчёт полей — неплохая идея, постараюсь сделать в следующей версии.

[DelphiST]

Зачем вы строите $params вручную, когда можно использовать http_build_query() либо кохановский URL::query()?

[PomanoB]

http_build_query() и, соответственно, URL::query() кодируют запятую, используемую как разделитель полей в ulogin, в шестнадцатеричное представление через %.