пока сие драфт, но будем добавлять и вероятно появится версионность
API-cервисы сайтов (предоставляемые сервисы)
Виджеты отображения информации
Интеграция суб-модулей с другими drupal-модулями
Данный документ составлен и дополняется с целью формализации требований к модулю Open Login версии 2.x
Этот модуль будет представлять из себя программный интерфейс между Друпалом и сторонними сервисами через другие модули-плагины. Сторонние модули-плагины, в свою очередь, должны будут реализовать интерфейс с отдельными сервисами, которые в свою очередь предоставляют свое API для доступа к своим службам. Например, mail.ru предоставляет API для авторизации, доступа к списку друзей, к альбомам фотографий, к публикациям в ленту “что нового” и пр. Весь фокус в том, что все эти сервисы имеют очень много общего в настройках и конфигурации и лишь небольшие отличия в конкретных реализациях вызовов функций API сторонних сервисов (это предположение, я четко не знаю величину сходства и различия, по меньше мере у всех есть публичный и секретный ключ).
Текущий модуль Open Login (1.x) переходит в Open Login widget, и он занимается только авторизацией через OpenID, точнее это просто виджет для OpenID.
В самый последний момент родилась идея сделать это отдельным модулем не затрагивая Open Login.
Пожелания и идеи описываются в самом конце документа
ссылки на документацию API провайдеров сервисов:
Сервис/сайт | ||||
login[a] | login | login | ||
users[b] | users | users | ||
connect | ||||
френдование | friends | friends | ||
Фото | photos | photos | ||
Аудио | audio | audio | ||
Видео | video | |||
Статус | guestbook | wall | ||
stream | ||||
notifications | ||||
Оплата и баланс | payments | secure | ||
connect | ||||
widget | ||||
places | ||||
notes | ||||
pages | ||||
questions | ||||
offers |
Модуль предусматривает набор хуков, для идентификации суб-модулей, хранения их настроек и сервисов, которые они предоставляют
Авторизация пользователя
Авторизация сайта
Открытые вопросы:
hook_openlogin_info() - сбор информации по провайдерам и их методам
hook_openlogin_user() - для drupal7 наверно нужно будет раздробить
Открытые вопросы:
Связь drupal пользователей с пользователями сервисов
openlogin_users {
uid - users.uid
provider - строка, имя провайдера
puid - строка, идентификатор пользователя для провайдера
created - UNIX timestamps
}
для связи сайта с сервисами наверно стоит
openlogin_sites {
drupal_private_key - результат drupal_get_private_key() потребуется для мультисайтинга
provider - строка
provider_keys - TEXT, сериализованый массив значений, необходимый для авторизации drupal-сайта на сервисе
}
Способы привязки конфигурации
openlogin_mappings { // by andypost
mapping - строка,например login, users, node, photo
provider - строка, например mail_ru, vk_api
status - int,включено ли (0/1)
data - text, сериализованые настройки конкретного маппинга
}
Предлагаю следующий формат данных: // by dan
openlogin_handlers { // обработчики привязок
hid - Handler ID
name - String (Имя обработчика, login, users, node, photo, cck_profile, etc.)
provider - String, (mail_ru, vk_api)
status - int (включено или нет (0/1))
data - Text (дополнительные данные)
}
openlogin_mapping{ // сами привязки, связаны с таблицей openlogin_handlers через hid
mid - Mapping ID
hid - Handler ID
source - String (идентификатор поля на стороне друпала)
destination - String (идентификатор сущности на стороне провайдера)
data - Text (дополнительные данные)
}
Таблица маппингов (openlogin_mapping) может использоваться не всеми обработчиками, например для хранения настроек логина (обработчик login) достаточно сериализованных данных в столбце openlogin_handlers.data, а вот для таких обработчков как node или cck_profile уже нужны настройки отдельных полей.
Резюмируя - если обработчик привязывает сущность друпала, то должно хватить openlogin_handlers, если привязываются поля, то используем дополнительно openlogin_mapping. Думаю этого должно быть достаточно, третий уровень добавлять не стоит. Пока не стоит :)
Виджеты отображения информации
Вывод информации о привязке пользователя к сервису
варианты:
Все отображаемые элементы модуля должны темизироваться через шаблоны, определяемые в самом модуле. Дополнительные, определенные суб-модулями элементы темизируются в суб-модулях.
Основная вкладка
включение и отключение маппингов
на дополнительных вкладках настройка маппингов для включенных провайдеров
По идее каждая страница настройки выглядит как таблица, строки которой выводят включенные операции провайдеров для данной сущности, которая описывается таблицей. Как пример смотреть.
Дополнительные вкладки - включенные мапинги
таблица как описано выше
Общие настройки Mail.ru вКонтакте Yandex.ru | ||||||||||||
|
Общие настройки Mail.ru вКонтакте Yandex.ru |
Настройки модуля |
Авторизация
Блоки, виджеты, форматеры
Обмен данными между drupal и сервисом - mapping
Share
Статистика регистраций
CCK, fields - drupal 6/7
media,
Organic groups (?),
Views,
Spaces
Facebook-style Statuses (Microblog) - сбор статусов, твитов
(?)
provider - суб-модуль предоставляющий интеграцию с внешним сайтом-сервисом
mapping (маппинг) - привязка сущностей друпала (ноды, комменты, поля) к сущностям провайдера.
Например, связать конкретное поле материала с audio, video, photo
Я бы сказал так (в дополнение) возможность указать какое поле CCK отправлять для публикации у провайдера. И обратно, в каком поле CCK (или в каком поле Profile) публиковать данные от провайдера. Часть маппингов предоставляется основным модулем + есть возможность подключать новые маппинги через суб-модули.
хендлер - ???
http://vkontakte.ru/developers.php
http://api.yandex.ru/ авторизация openid (работает) http://help.yandex.ru/openid/?id=1112020
http://www.rambler.ru/all.shtml
[a]предоставляет первичные данные о пользователе (login name) - ingumsky
[b]Дополнительные данные о пользователе - ingumsky
[c]полагаю должна быть конфигурация модуля, где под каждый функционал (users, photos,...) будет отдельная вкладка для настройки прав - apostnikov
[d]главное не переусердствовать с настройками!!! аватар и имя стоит настраивать на привычных местах, остальное можно вынести на вкладки, просмотр и редактирование сделать под право - только для автора профиля - apostnikov
[e]схлопывание черевато чисткой кеша, заменой uid для неизвестных сущностей (сменой авторства) - apostnikov