xml rpc что такое

Окончательный вариант

POST /RPC2 HTTP/1.0
User-Agent: MyAppWord/5.1.2 (WinNT)
Host: server.localnet.com
Content-Type: text/xml
Content-length: 172

TranslateWord

Сервер, приняв наш запрос, передает его программе-демону, которая производит парсинг запроса, выделяет из него нужные данные и, найдя (например, по таблице) ссылку на нужный метод, вызывает его с переданными параметрами. Если тип и количество параметров правильные, то по окончании работы метода программа-демон принимает возвращенное значение, преобразует его в XML-описание и формирует ответ.

HTTP/1.1 200 OK
Connection: close
Content-Length: 166
Content-Type: text/xml
Date: Fri, 17 Jul 1998 19:55:08 GMT
Server: MyWordCheckSerwer/5.1.2-WinNT

MyAppWord
Сообщение об ошибке:

HTTP/1.1 200 OK
Connection: close
Content-Length: 166
Content-Type: text/xml
Date: Fri, 17 Jul 1998 19:55:08 GMT
Server: MyWordCheckSerwer/5.1.2-WinNT

faultCode
10

faultString

Перевод невозможен. Слово отсутствует в словаре.

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

Хотя наш пример, на первый взгляд, кажется надуманным и простым, тем не менее, на нем показано, как можно уже сегодня использовать XML-RPC для решения конкретных задач. Конечно, его возможности намного шире, и можно, например, представить себе распределенную ОС, построенную на XML-RPC, или системы визуализации данных, построенные по архитектуре X Window, но с применением все того же XML-RPC.

XML-RPC vs SOAP

Если для реализации удаленного вызова вы используете XML, то у вас есть выбор: использовать XML-RPC или же SOAP (Simple Object Access Protocol). О последней уже написано множество статей, поэтому предлагаем только сравнить обе технологии.

Вот некоторые характеристики, которые определяют различия XML-RPC или же SOAP:

Конечно, на первый взгляд «минус» в столбце SOAP встречается только единожды. Это создает иллюзию «всереализуемости всего» в нем. Но давайте присмотримся внимательнее. Основные типы данных у обоих конкурентов одинаковые. Но в XML-RPC отсутствует возможность задавать имена для массивов и структур (все структуры и массивы являются «анонимными»). Возможно, это упущение разработчиков, но решить эту проблему можно и самому, например вводя еще одну строковую переменную с именем массива или структуры (в случае, если таких объектов много, можно завести специальный массив «имен массивов»).

Да, ни одна из этих технологий не является панацеей от всех бед и не претендует на полноту. Большинство программистов и разработчиков спецификаций сходятся на том, что:

Выбрав SOAP, сразу смиритесь с тем, что у вашей команды разработчиков (или у вас самих) впереди много головной боли, которая начнется уже с момента чтения спецификаций. Но ведь зато вы будете иметь возможность в конце концов построить систему практически любой сложности и функциональности.

Источник

Дао Вебсервиса. (Или да хватит же изобретать велосипеды!)

Недавно на Хабре была опубликована статья под провокационным заголовком и призывом к прекращению изобретений велосипедов в API-строении. Поскольку тема мне интересна, то я просто не мог пройти мимо.
Увы, реальность за хабракатом меня сильно разочаровала — я увидел очередной велосипед, да еще и с квадратными колесами. (Коллеги, ничего личного, только техническое обсуждение.) Правда, авторы честно сказали, что увидели на нескольких сайтах модное слово REST и решили сделать по нему. Только вот поняли они этот «РЭСТ» по-своему, примерно как Дед Щукарь читал и понимал толковый словарь.
В этом топике я призываю по-настоящему покончить с велосипедами в API сайтов. Ведь получается какой анекдот: АПИ разрабатывается для упрощения доступа к сайту и легкости подключения внешних систем, а получается такой, что с ним еще сложнее, чем без него 🙂

Чуть ниже под катом я подпишу смертный приговор всем велосипедам в универсальных API. Чтобы не быть голословным, я все проиллюстрирую примерами.
Но должен предупредить сразу — после прочтения статьи вы не сможете без рвотного рефлекса смотреть на очередной велосипед Васи Пупкина под гордым названием «универсальное API сайта».

Итак на сегодня наиболее распространенными способами доступа к API сайтов являются:
1. XML-RPC.
2. REST (с оговоркой, что это не протокол, а подход).
3. SOAP.

Базовые технологии и сравнение

XML-RPC

Примерно так же просто выглядят сообщения об ошибках. Такой ответ легко распарсить даже человеку, не говоря уже про машину. Такая простота сослужила ему двоякую службу: с одной стороны он не был принят заказчиком и не стал стандартом, а с другой — понравился толпе простых незамороченных программистов. Этим ребятам нужно было простое и надежное средство обмена информацией между системами, они не хотели заморачиваться на такую хрень как красивый УРЛ, схема документа и прочие академизмы. Первое, что они хотели получить — простую работающую систему. И до сих пор XML-RPC помогает им в этом.
Итак:
+ : простота, краткость сообщений, минимальная проверка формата данных,
— : недостаточная строгость, требуется отдельное описание сервиса.

POST /api/object.php?object_id=445&action=delete&user_id=255&auth_key=0Jf4tet5 HTTP/1.1

При этом, если XML-RPC использует из HTTP-протокола только транспортную часть для передачи XML-ки запроса/ответа, то REST задействует HTTP по-полной: здесь и авторизационные заголовки, content-negotiation — предпочтения по формату, языку, кодировке и виду ответа, различные служебные заголовки, безгеморная передача бинарных данных и т.п. Ошибки хорошо описываются кодами HTTP 4xx и 5xx. Можно видеть, что REST — органичная надстройка над HTTP. Это неудивительно ведь Рой — один из разработчиков протокола HTTP. Вообще, чем больше я разбираюсь с этим протоколом тем больше мне кажется, что он опередил свое время лет на 20, и чем дальше развивается веб, тем больше возможностей мы из него используем.
Само тело сообщения может передаваться в разных форматах: классическом XML либо гиковском JSON. Вообще, REST это не протокол, это подход, и как раз здесь заключена его гибкость, он как бы говорит нам: «Ребята, берите базовые принципы, а дальше делайте как вам удобно». Близость к HTTP-протоколу упрощает и ускоряет его обработку веб-серверами.
Итак:
+ : гибкость, простота, скорость обработки (особенно важно для крупных сайтов), органичность протоколу, мультиформатность, компактность.
— : отсутствие строго контроля данных, из практических соображений приходится выходить за рамки идеальной модели.

— Фак май мозг! — воскликнете вы и будете абсолютно правы — Это что же, ради передачи фитюльки на 10 байт мне надо всю эту лабуду писать?
— Да — скажет Логика, и вы, засучив рукава пойдете учить всю эту кучу технологий.

— Сюда еще и XML Schema приплели зачем-то? Какого хрена? А вы уверены, что эти ребята правильно понимают смысл слова «Simple»? — такие мысли будут вас посещать, и это хорошо — вы на верном пути.

Но и это не все: чем больше копаешься в SOAP тем больше всяких разных технологий вылазит на тебя. Когда вы дойдете до WSDL (Язык описания веб-сервисов), вы поймете почему, начиная с какой-то версии, разработчики перестали воспринимать название SOAP как аббревиатуру, а начали понимать буквально — soap («мыло»). В этот момент ваши мысли будет занимать одна идея: почему во всем этом зоопарке технологий отсутствует технология rope («веревка»).

Еще через какое-то время вы воскликните: «Ну нафиг, давайте уж без меня: сами придумали — сами и возитесь. Я вам не машина мегабайты иксэмеля в мозгу парсить!».
Поздравляю: теперь вы постигли дао вебсервисов!

Да! Дао веб-сервиса именно в этом и состоит: это язык общения машин и человеку нафиг не надо туда лезть. Надо просто его использовать. Ведь когда вам нужна какая-то программа, вы ее запускаете, а не лезете в бинарный код, чтобы исполнять его в мозгу. Точно так же вы не отправляете HTTP-запросы руками в командной строке, а используете браузер. Так зачем здесь лезть в эту гопу голыми руками, да еще хвастаться кто залез по локоть, а кто по самое плечо? Надо просто его использовать.

Просветленные API

API сайта и веб-сервисы — это не что-то милостиво спущенное на нас с небес создателями сайта! Это банальная библиотека функций, которую мы можем встроить в свою программу. Этот вывод становится совершенно естественным, когда вы начинаете мыслить глобально за пределами своего компьютера.
Если вам нужна новая уже готовая либа в проекте, что вы делаете? Скорее всего просто скачиваете, устанавливаете и используете? Пишете в начале программы use/require/import/include/… а дальше просто вызываете функции. Почему же работа с веб-библиотекой должна быть сложнее?
Вот теперь, просветлившись, мы можем начать работать с просветленным API.

Сейчас в качестве примера мы 1 минуту сделаем работу с API Аэрофлота, будем подглядывать за табло Шереметьево без отрыва задницы от стула. Я беру свой любимый язык и на нем пишу все примеры. Уверен, в вашем языке есть аналогичные модули. Ну а если их там нет, то самое время задуматься, так ли взаимна ваша любовь 😉

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

Стойте-стойте, а как же вся эта лабуда с XML, REST, передачей параметров, парсингом ответов и всеми прочими атрибутами «крутого» API?
Лучше всего на это отвечает фильм «Матрица», кадр из которого мне захотелось вынести в заголовок:

Только перестав думать о ложке сайтовом API как о чем-то реальном, сложном, можно начать гнуть ее комфортно использовать.
Это и есть просветленное API — прозрачное и светлое настолько, что вы его не замечаете, когда работаете. Для вас это просто локальная библиотека. А вся остальная механика с сетевыми заморочками происходит где-то внутри и вас не напрягает.

Как отличить сайтовое API от говна.

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

Выводы

В наше время наличие API для сайта претендующего на внимание программистов, всевозможные интеграции и прочее — не повод для гордости, а предмет первой необходимости. Но мало сделать API, даже если вы используете самые модные принципы — надо его сделать удобным и прозрачным. И технология передачи данных здесь имеет значение 10-й важности — это вообще не нужно прикладному программисту. Он должен просто взять и использовать вашу библиотеку.
Если вы хотите получить его внимание, чтобы он потратил свое время на интеграцию с вами — сделайте первый шаг — потратьте время на него. Дайте ему очень простую и понятную библиотеку.
Не надо кивать на то, что «мы сделали как твиттер — дали REST-подобный интерфейс». Вы забываете главное — у твиттера на каждый язык программирования по 5-10 библиотек, которые можно просто скачать и использовать не заморачиваясь на протокол rest/xmlrpc/soap.

Источник

Руководство по xmlrpc.php в WordPress (что это такое, риски и как отключить)

Протокол «XML-RPC» был разработан для стандартизации взаимодействия между различными системами, что означает, что приложения вне WordPress (например, другие платформы для ведения блогов и клиенты) могут взаимодействовать с ядром вашего WordPress сайта.

WordPress использует «XML-RPC» с момента его создания и он проделал очень полезную работу. Без него WordPress был бы изолирован от остального Интернета.

Однако у xmlrpc.php есть свои недостатки. Он способен открыть уязвимости вашего сайта WordPress, и теперь его заменил WordPress REST API, который намного лучше работает как связь между WordPress и другими приложениями.

В этом посте мы объясним, что такое xmlrpc.php в WordPress, почему желательно бы его отключить, и поможем определить, работает ли он на вашем сайте.

Содержание

Что такое xmlrpc.php в WordPress?

Итак, как вы уже знаете, «XML-RPC» – это протокол, который обеспечивает связь между WordPress и другими системами. Добились этого путем стандартизации этих коммуникаций с использованием «HTTP» в качестве транспортного механизма и «XML» в качестве механизма кодирования.

XML-RPC появился гораздо раньше чем сам WordPress: он присутствовал в программном обеспечении для ведения блогов «b2», одна из ветвей которого использовалась для создания WordPress в уже далёком 2003 году. Частично, код ПО «b2» хранится в файле с именем xmlrpc.php в корневом каталоге сайта. Да, он все еще существует, хотя «XML-RPC» в значительной степени устарел.

Стоит уточнить, что «XML-RPC» взаимодействовал не только с приложением, он также использовался для обеспечения связи между WordPress и другими платформами для ведения блогов, он подключал, так называемые «Pingbacks» (обратные ссылки), а также работал с плагином Jetpack.

Опираясь на то, что «REST API» заменил «XML-RPC», вам следует отключить xmlrpc.php на своем WordPress сайте. Давайте разбираться почему это нужно сделать.

Почему рекомендуется отключить xmlrpc.php?

Основная причина, по которой вы должны отключить xmlrpc.php на своем WordPress сайте, заключается в том, что он может открыть уязвимости и стать целью атак.

Теперь, когда «XML-RPC» больше не нужен для связи вашего сайта со сторонними ПО, нет причин держать протокол открытым. Было бы разумно сделать ваш сайт более безопасным, не так ли?

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

Давайте рассмотрим конкретные уязвимости более подробно.

1. DDoS-атаки через пингбеки XML-RPC

Эта связь стала возможной благодаря протоколу «XML-RPC», но ее заменил «REST API» (как вы уже усвоили).

Если на вашем сайте включен «XML-RPC», злоумышленних потенциально может организовать DDoS-атаку на сайт, используя xmlrpc.php для отправки большого количества пингбеков на ваш сайт за короткое время. Это может перегрузить ваш сервер и вывести его из строя.

2. Brute Force атаки через XML-RPC

Каждый раз, когда xmlrpc.php делает запрос, он отправляет имя пользователя и пароль для аутентификации. Это представляет собой серьезную угрозу безопасности а вот «REST API» этого не делает. Фактически, «REST API» использует метод «OAuth», который отправляет токены для аутентификации вместо имен пользователей или паролей.

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

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

Работает ли xmlrpc.php на вашем WordPress сайте?

Первое, что вам нужно сделать, это определить, активен ли xmlrpc.php на вашем сайте WordPress.

Это непросто проверки наличия файла. Файл является частью каждой установки WordPress и будет присутствовать, даже если «XML-RPC» отключен.

Всегда делайте резервную копию своего сайта, прежде чем что-либо удалять. В нашем случае не удаляйте просто файл xmlrpc.php, потому что он сломает ваш сайт.

Чтобы проверить, активен ли xmlrpc.php на вашем WordPress сайте, используйте сервис проверки. Этот сервис автоматически проверит ваш сайт и сообщит, активен ли протокол или нет.

Проверяем используется ли xmlrpc.php в WordPress сайте

Вот результат, который вы получите если проверите wordpresslab.ru через этот сервис. «XML-RPC» отключен!

Итак, если вы запустите проверку и увидите, что xmlrpc.php все еще используется на вашем сайте, как вам его отключить?

Как отключить xmlrpc.php на своём WordPress сайте?

Допустим вы отправили сайт на проверку, как написано выше и получили вот такой результат:

Проверка успешна, xmlrpc.php активен

Ну что же, протокол активен, давайте отключать.

Самым простым способом будет установка и активация плагина Disable XML-RPC, не смущайтесь что плагин не обновлялся больше года. Обновлять там нечего, так как он содержит всего одну строчку кода:

Именно этот фильтр и отключает протокол «XML-RPC» на WordPress сайте. А если всё же не хочется использовать плагины, то достаточно вставить вышеупомянутый фильтр в файл functions.php вашей темы (желательно дочерней).

В каких случаях стоит оставить xmlrpc.php?

В некоторых случаях xmlrpc.php может быть полезен и его не следует полностью отключать.

Это всё! Если ни одна из этих причин не является особенно веской для вас – смело отключайте.

Единственная причина, по которой этот файл все еще находится в WordPress – это обратная совместимость. Для всех, кто хочет поддерживать свои сайты в актуальном состоянии и работает с новейшими технологиями, отключение xmlrpc.php – лучший вариант.

Подведем итог

Протокол «XML-RPC» был разработан еще до создания WordPress как средство взаимодействия WordPress с внешними системами и приложениями. Ему присущи недостатки в плане безопасности, и он может сделать ваш сайт уязвимым для атак.

Начиная с версии 4.4 в WordPress ядро была интегрирована поддержка «REST API», что делает «XML-RPC» абсолютно не нужным. Если вы выполните описанные выше действия, отключив эту функцию, вы повысите безопасность своего сайта.

Если у вас есть вопросы – спрашивайте в комментариях и мы обязательно вам ответим.

Источник

• ← М бубер считал что диалогическая позиция является
• insufficient vis thaumcraft 4 что делать →