Создаём собственный API – 7

Кирилл Евсеев, April 12, 2011

Приветствую всех, вытерпел до этого момента и не уснул на предыдущих частях статьи 🙂 Сегодняшняя статья последняя в цикле статей об API. Надеюсь, в качестве наглядного материала и источника новых идей вам этого хватит. А если не хватит, – задавайте свои вопросы в комментариях. Если так случится, что понадобятся новые дополнительные статьи на эту тему, то не думаю, что это будет очень большой проблемой 🙂

Но вернёмся к нашему API. В заключительной части статьи я покажу то, с чего начал во второй статье, а именно – фильтрация кода от нежелательных данных, полученных от пользователей. Прежде всего, давайте прикинем, что мы уже защитили.Итак:

  1. Мы можем без труда зашифровать протокол передачи данных и воспользоваться HTTPS
  2. Мы обеспечиваем жёсткий формат запроса. Любой запрос, в котором отсутствуют необходимые данные, игнорируется. Любой запрос, в котором есть дополнительные данные, непредусмотренные нашей логикой, отсекаются и игнорируются.
  3. Для выполнения запроса мы заставляем пользователя пройти авторизацию. Т.о. мы отфильтровываем пользователей, которым можно доверять от тех, которых мы вообще не знаем.
  4. Авторизованные пользователи отличаются друг от друга уровнем доступа – что позволено Юпитеру, не позволено быку(с).
  5. Запрос содержит пару – имя функции и массив аргументов.Мы проверяем, существует ли в нашем API такая функция и тестируем массив аргументов на количество переданных параметров и их типы. Таким образом, мы уже предотвращаем попытки смержить строку с целой переменной id, которые используются у нас в запросах.

Мы не проверяем синтаксис запросов, да это и ненужно. В случае проблем, API просто вернёт вызывающему хосту false. Мы не проверяем результат, который возвращают API функции, хотя у нас есть такая возможность. Однако, мы возвращаем вызывающему хосту результат as is. Для демонстрационной API-системы вполне нормально.

Сейчас мы реализуем последний штрих к этой картине. (more…)

Создаём собственный API-6

Кирилл Евсеев, April 5, 2011

Всем привет. Сегодня мы разработаем два ключевых класса. Во-первых, мы изменим способ обращения к Gateway и во-вторых, разработаем Api Handler который сможет быть по настоящему классом-контейнером для всей иерархии API.

Начнём с API Handler, чтобы изменения в Gateway были более очевидны. Забегая вперёд, заметим, что все изменения не касаются удалённого хоста. Т.о. драйвер для работы с API на удалённом хосте остаётся таким же. На API хосте мы всё так же принимаем запрос и всё так же возвращаем ответ, но, в данном случае, меняется способ обработки этого запроса и формат ответа в случае ошибки. Единственные изменения, которые должны произойти на удалённом хосте – это информация об авторизации (имя пользователя и пароль), которую необходимо добавить к запросу.

(more…)

Создаём собственный API-5

Кирилл Евсеев, March 31, 2011

Ну что ж, пришло время поговорить о безопасности. Но прежде чем мы приступим, я немного вернусь назад. В самой первой статье я говорил о том, что информацию можно вернуть вызываемому приложению как объект. Как вернуть информацию в виде массива мы уже разобрались. Массив – это просто данные, которыми удобно манипулировать.

Если вы хотите предоставить удалённым разработчикам объект, который, в т.ч., может обращаться к Host 1 для вызова API, достаточно просто создать этот объект на стороне API-сервера и вернуть вызываемому приложению вместе с классом (и всеми родительскими классами), который является типом этого объекта. Сделать это очень просто. Достаточно прочитать файл, в котором хранится определение класса, с помощью стандартных функций типа fopen и вернуть в качестве строки. На стороне приложения (Host 2) эту строку нужно сохранить в локальный файл (фактически получим копию файла на API-сервере) и подключить этот файл с помощью incude.

О том, как передаются сериализованные объекты, можно подробнее прочитать в справке PHP.
Теперь вплотную займёмся безопасностью. Условно, меры, которые мы можем предпринять, можно разделить на следующие пункты:

  1. Авторизация с уровнями доступа.
  2. Фильтрация запроса.
  3. Использование защищённого соединения.
  4. Использование различных трюков.

(more…)

Создаём собственный API-4

Кирилл Евсеев, March 6, 2011

Всем привет. Итак, пришло время создать классы Gateway и Connector и посмотреть на наш API в деле. Для этого нам понадобится доступ к удалённому хосту или виртуальные хосты Apache. Я буду использовать удалённый хост.

Итак, создайте на удалённом хосте структуру базы, как это было описано во второй части статьи. Теперь нужно написать класс Gateway, который реализует протокол передачи данных. Как я уже говорил, будем исходить из объективной простоты, а именно – наши данные будут передаваться в виде сериализованного и закодированного POST запроса. Хотя, никто не мешает разработать свой протокол и потратить на это пару килобаксов вашего заказчика.
(more…)

Создаём собственный API – 3

Кирилл Евсеев, February 21, 2011

Как я и обещал, сегодня мы допилим классы api_executor и api_functions. Для начала посмотрим на класс api_functions и интерфейс api_functions_itrfc. Интерфейс api_functions_itrfc теперь выглядит так: (more…)

Поиск по блогу:
Подписаться:
Популярные:
Облако тегов:
Разное:
Счетчик: