сценарий поддверждения удаленных вызовов через xml-rpc
25.01.2008Написать плагин социальной сети не составляет большого труда. В который раз повторю старую истину: написать исполняемый код (исходник) можно за один - три дня. Я этого пока не делаю по следующим причинам: пока что нет детального представления работы плагина и протокола обмена данными. Есть уже точное понимание как будет работать плагин на каждом участке. Я писал про уведомление о новом комментарии. Как это я описал раньше есть лазейка для спамеров. Когда вы оставляете комментарий на блоге у друга, этот блог должен уведомить вас о новом вашем комментарии: ваш блог должен ответить либо отказом, либо согласием, либо ожидает модерации. Предположим, что спамер послал вам уведомление о якобы вашем комментарии - тогда вы будете завалены спамом. Вывод: вызов всех удаленных функций (rpc - remote procedure call) должен иметь еще один параметр - типа сессионный ключ/пароль доступа для обратного подтверждающего вызова (callback). Получается масло масленое - подтверждение подтверждения. Продемонстрирую как оно будет работать:
1. Клиент уведомляет блог автора комментария
2. Блог автора получает уведомление
3. Блог автора проверяет урлы и запрашивает у вызвавшего клиента, что это именно он уведомляет
4. у клиента запускается сервер, который получает запрос на подтверждение - он сравнивает полученные данные с имеющимся в базе (сессионный ключ) и дает отмашку
5. Блог автора получает от клиента подтверждение и после этого наконец таки дает ответ клиенту и соответственно может забрать комментарий к себе.
Можно немного оптимизировать вызовы и в пункте 3 сделать один вызов для подтверждения уведомления и получения самого комментария.
Почему же такие сложности? Да очень просто - любой спамер может вызвать эти функции, а такой протокол гарантирует что два домена обменяются данными: на каждом этапе будет резолвиться имя, а ведь нет гарантированного способа что ты это ты не прибегая к сертификатам и https. Решение должно работать на любом хостинге, в том числе и на бесплатном. Можно было бы обойтись без обратных вызовов, если использовать зарегистрированный логин и пароль на одной из сторон. Возможным бы решением этого мог бы быть рассмотренный мной openid, но вот возиться с ним не хочется - ведь мое решение будет работать без привлечения дополнительных сущностей. Использование openid значительно увеличивает цену разработки плагина: время и усилия по разбору документации по openid, тестирование, наличие ошибок в сторонних библиотеках и изучение этих библиотек, увеличение нагрузки на сервер (об этом явно написано в плагине openid для wordpress). Для установки плагина тогда потребуется таскать с собой библиотеку openid и следить за ее обновлениями. Когда как мое решение ничего подобного не требует и будет физически находится всего водном файле php. У кого есть какие соображения?
Мой блог находят по следующим фразам
• запись данных ping
• робоблог
• сервер социальной сети программа
• Как удалить плагин. Сообщение уже отправляю а код никакой не приходит!
• удаление плагина
• как удалить плагин
Комментарии (10) на запись “сценарий поддверждения удаленных вызовов через xml-rpc”
Пингбеки
- ссылка на подписку на rss2email.ru одним кликом | Программы для блогов
- Подавление диалоговых окон Word | Программы для блогов
- Рейтинг записей | Программы для блогов
- индексирование сайта yandex | Программы для блогов
- страницы (Page) в wordpress и исключение страницы из списка | Программы для блогов
- Привет мир! | Программы для блогов
- openid - что это такое | Программы для блогов
- Картинки панели инструментов для блог клиента | Программы для блогов
- Каким должен быть блог клиент? | Программы для блогов
- проектирование xml rpc интерфейса для плагина социальной сети wordpress | Программы для блогов
- Бесплатный хостинг с предустановленным wordpress | Программы для блогов
- Социальная сеть из блогов на wordpress | Программы для блогов
- доступ к комментариям по xml-rpc в wordpress: проблемы с преобразовании дат | Программы для блогов
- SSL и Basic Authentication для прокси | Программы для блогов
- Проектирование многопоточного (multi thread) приложения | Программы для блогов
- Invokable методы в xmlrpc сервере | Программы для блогов
Оставить комментарий
Ok. Если можно обойтись без open_id, это есть хорошо. Но вот по поводу разрешений на коммуникацию... Может, просто сделать, как в почте? "Разрешить всем", "разрешить только тем, кого я добавил в белый лист", "разрешить всем, кого я не внес в черный лист"?
И еще, немного не к этой статье, просто сразу все в кучу. Коммуникация blog-to-blog, ИМХО, не должна сводиться только к обменам комментами и проставлением trackback'ов. Очень уж мне нравится такая штука, как "Лента друзей". И если я где-то что-то комментировал, то хотелось бы апвтоматом и подписываться на другие комменты к этому материалу. А заодно и вносить канал блога (по крайней мере, иметь кнопочку для этого) в свою "ленту друзей". Я в своем первом комменте здесь писал про Dasher - RSS-агрегатор, который выводит каналы в админке блога (на Dashboard). Вот если бы его еще напильником подработать и прицепить к сюда... Вот тогда получим полноценную коммуникацию, на основе которой уже можно строить социальную сеть.
К своему стыду, смею признаться, что я практически не пользуюсь rss для чтения: либо на сайт захожу, либо по почте через rss2email.ru получаю новые выпуски. По поводу интеграции с rss у меня нет никаких возражений, просто я в этом пока не разбираюсь, но не думаю что могут возникнуть какие либо сложности с этим
>Я ведь так намудрил это только ради защиты от спамеров.
Вот-вот. Open_id подразумевал выявление спаммеров и защиту от них. А здесь именно ручной отбор "друзей"/"врагов" просто обязателен будет.
Что же касается RSS, то там все просто. Генерится .xml-файл с обновлениями сайта, к которому обращаешься и читаешь.
А началось все у меня с того, что получение последних записей друзей из БД (как это реализовано в wpmu) нагружает эту самую БД (сильно). А продолжилось тем, что хочется добавлять в "ленту друзей" не только блоги на том же сервисе, но и на другом... и stand-alone... и выдачу поисковиков по моим любимым запросам. В общем, та же "лента друзей", как в ЖЖ, только с большим охватом (поставь плагин, поиграйся).
Проблема возникает, если нужно сделать записи "только для друзей". Т.е. как определить, кто пытается считать канал - "друг" или посторонний? И опять же, генерить несколько .xml-файлов - "для всех", "для друзей" и т.д. и давать разные адреса? Или же считывать адрес сервера/сайта, корторый к тебе обращается и генерить файл на лету? Вот, open_id я и планировал использовать для определения, кто пришел и уже по этому определению генерить xml. Но если можно такую проверку сделать без open_id... хочу :)
Считывание и вывод RSS-каналов, на самом деле, тоже может дать приличную нагрузку на сервер + трафик (каналов, хотя бы, 20 будет в ленте...). Т.е. нужно кэшировать результаты. Но если тупо обновлять кэш с заданной периодичностью, то все-равно непроизводительно получается - часть каналов обновилась, часть нет. А вот пинг позволит оповестить блог-приемник, что было обновление - канал надо считать. Тогда считывание каналов можно сделать при первом заходе в ленту (причем, только тех, которые обновились) и держать кэш до следующего пинга.
Как я понял open_id не гарантирует от спама - всего лишь упрощает авторизацию и заполнения профиля. Никто не мешает спамеру воспользоваться open_id - будет тоже самое ручное модерирование, вобщем никаких заметнных преимуществ. У блогера есть адрес его блога, а у обычного пользователя его нет, вот для них и нужен open_id. Определить, кто считывает рсс, то бишь скачивает файл по http достоверно невозможно: если через браузер, то помогут куки, если через какой то агрегатор то нет. Да и вообще куки могутбыть отключены или через прокси скачиваю, я вот например постоянно пользуюсь сжимающим прокси, который стоит у меня на сайте и поэтому часто на сайтах показывается не мой ип адрес, а ип адрес моего сайта. Предположу, что ты не очень знаешь протокол http?
Про рсс - задача стоит добавить рсс в дашборд или для общего пользования? Меня всегда интересовало, как рсс ридеры работают - опрашивают каждый урл? У больших (яндекс, гугл, фидбурнер) есть всем известные урлы для пингования, куда и пингуется новая запись. У себя на сайте я выложил файл из 120 пингоприемников. Это тоже мысль - включить в плагин пингование списка друзей. Но вот как быть с лентой от яндекса? Яндекс не будет то пинговать твой блог. Вот еще одна идея для сервиса - сайт пингующий об обновлениях рсс - один для всех. Чуствую что что то я не догоняю, посмотрю ка твой плагин
>Про рсс - задача стоит добавить рсс в дашборд или для общего пользования?
- Лента выводится в Dashboard (RSS-агрегатор для собственного использования). По идее можно придумать вариант расшаривания (на странице или виджетом) - что-то вроде "я читаю", раз комментарии планируется на странице выводить.
>Предположу, что ты не очень знаешь протокол http?
- ага, а если точнее, то я даже не программист
>посмотрю ка твой плагин
- :), и учитывая мое "не программист", можешь сразу прикинуть несколько фишек?
1. Не могу придумать, как сделать категории для каналов.
2. Хочется предусмотреть возможность не удаляя каналы из списка, отключать их вывод (в оригинале каналы не удалялись вообще, зато можно было не воводить, я просто поменял
'installed_feeds'=>$dasher_options['installed_feeds']
на 'installed_feeds'=>$dasher_options['feeds_to_display']. Т.е. я так примерно понимаю, что надо добавить еще что-то вроде deleted_feeds и второй чекбокс, где installed_feeds deleted_feeds, но с синтаксисом проблемы.
И как бы заодно понять, использует плагин кэш wp или нет? ИМХО, не использует (хотя обращается к wordpress'овскому rss.php), но, блин, "не программист"...
>а что требуется? Кешировать или нет?
- кэшировать, т.к. не только для личного использования
ключевое слово cache его и искать в текстах плагинов
- ага! нашел! почитал, кэширует :)!