Создаём собственный API – 7
Приветствую всех, вытерпел до этого момента и не уснул на предыдущих частях статьи 🙂 Сегодняшняя статья последняя в цикле статей об API. Надеюсь, в качестве наглядного материала и источника новых идей вам этого хватит. А если не хватит, – задавайте свои вопросы в комментариях. Если так случится, что понадобятся новые дополнительные статьи на эту тему, то не думаю, что это будет очень большой проблемой 🙂
Но вернёмся к нашему API. В заключительной части статьи я покажу то, с чего начал во второй статье, а именно – фильтрация кода от нежелательных данных, полученных от пользователей. Прежде всего, давайте прикинем, что мы уже защитили.Итак:
- Мы можем без труда зашифровать протокол передачи данных и воспользоваться HTTPS
- Мы обеспечиваем жёсткий формат запроса. Любой запрос, в котором отсутствуют необходимые данные, игнорируется. Любой запрос, в котором есть дополнительные данные, непредусмотренные нашей логикой, отсекаются и игнорируются.
- Для выполнения запроса мы заставляем пользователя пройти авторизацию. Т.о. мы отфильтровываем пользователей, которым можно доверять от тех, которых мы вообще не знаем.
- Авторизованные пользователи отличаются друг от друга уровнем доступа – что позволено Юпитеру, не позволено быку(с).
- Запрос содержит пару – имя функции и массив аргументов.Мы проверяем, существует ли в нашем API такая функция и тестируем массив аргументов на количество переданных параметров и их типы. Таким образом, мы уже предотвращаем попытки смержить строку с целой переменной id, которые используются у нас в запросах.
Мы не проверяем синтаксис запросов, да это и ненужно. В случае проблем, API просто вернёт вызывающему хосту false. Мы не проверяем результат, который возвращают API функции, хотя у нас есть такая возможность. Однако, мы возвращаем вызывающему хосту результат as is. Для демонстрационной API-системы вполне нормально.
Сейчас мы реализуем последний штрих к этой картине. (more…)
Создаём собственный API-6
Всем привет. Сегодня мы разработаем два ключевых класса. Во-первых, мы изменим способ обращения к Gateway и во-вторых, разработаем Api Handler который сможет быть по настоящему классом-контейнером для всей иерархии API.
Начнём с API Handler, чтобы изменения в Gateway были более очевидны. Забегая вперёд, заметим, что все изменения не касаются удалённого хоста. Т.о. драйвер для работы с API на удалённом хосте остаётся таким же. На API хосте мы всё так же принимаем запрос и всё так же возвращаем ответ, но, в данном случае, меняется способ обработки этого запроса и формат ответа в случае ошибки. Единственные изменения, которые должны произойти на удалённом хосте – это информация об авторизации (имя пользователя и пароль), которую необходимо добавить к запросу.
Создаём собственный API-5
Ну что ж, пришло время поговорить о безопасности. Но прежде чем мы приступим, я немного вернусь назад. В самой первой статье я говорил о том, что информацию можно вернуть вызываемому приложению как объект. Как вернуть информацию в виде массива мы уже разобрались. Массив – это просто данные, которыми удобно манипулировать.
Если вы хотите предоставить удалённым разработчикам объект, который, в т.ч., может обращаться к Host 1 для вызова API, достаточно просто создать этот объект на стороне API-сервера и вернуть вызываемому приложению вместе с классом (и всеми родительскими классами), который является типом этого объекта. Сделать это очень просто. Достаточно прочитать файл, в котором хранится определение класса, с помощью стандартных функций типа fopen и вернуть в качестве строки. На стороне приложения (Host 2) эту строку нужно сохранить в локальный файл (фактически получим копию файла на API-сервере) и подключить этот файл с помощью incude.
О том, как передаются сериализованные объекты, можно подробнее прочитать в справке PHP.
Теперь вплотную займёмся безопасностью. Условно, меры, которые мы можем предпринять, можно разделить на следующие пункты:
- Авторизация с уровнями доступа.
- Фильтрация запроса.
- Использование защищённого соединения.
- Использование различных трюков.
Создаём собственный API-4
Всем привет. Итак, пришло время создать классы Gateway и Connector и посмотреть на наш API в деле. Для этого нам понадобится доступ к удалённому хосту или виртуальные хосты Apache. Я буду использовать удалённый хост.
Итак, создайте на удалённом хосте структуру базы, как это было описано во второй части статьи. Теперь нужно написать класс Gateway, который реализует протокол передачи данных. Как я уже говорил, будем исходить из объективной простоты, а именно – наши данные будут передаваться в виде сериализованного и закодированного POST запроса. Хотя, никто не мешает разработать свой протокол и потратить на это пару килобаксов вашего заказчика.
(more…)
Создаём собственный API – 3
Как я и обещал, сегодня мы допилим классы api_executor и api_functions. Для начала посмотрим на класс api_functions и интерфейс api_functions_itrfc. Интерфейс api_functions_itrfc теперь выглядит так: (more…)