Отправляет email-рассылки с помощью сервиса Sendsay

Веб-разработка: пособие начинающим

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Левитас: Почему Ваш бизнес-сайт не работает?" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Март 2011   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Александр Левитас

Статистика

10.726 подписчиков
-23 за неделю
←   Все выпуски   →

Веб-разработка? Это просто! Создаём собственный API-5


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

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

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

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

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

В этой части статьи мы обсудим авторизацию и подготовимся к п.2. Что касается защищённого соединения - речь идёт о передаче данных по протоколу HTTPS, с которым cURL отлично работает.

Однако, можно продолжать передавать данные по HTTP, но добавить к нашему протоколу функцию шифрования. Это просто бездонная тема и останавливаться на этом мы не будем (возможно, мы рассмотрим некоторые идеи в других статьях, не касающихся API). В любом случае, относительно п.4., - я подкину вам пару идей, которые вы можете использовать в своих рабочих приложениях уже сейчас:

  1. В запросе передавать не имена функций, а их хэши.
  2. Клиент шифрует свой запрос функцией encrypt_foo_client и передаёт его API-серверу. API-сервер шифрует запрос функцией encrypt_foo_server и возвращает его API-клиенту. API-клиент расшифровывает запрос функйцией decrypt_foo_client и возвращает запрос серверу. Сервер расшифровывает запрос функцией decrypt_foo_server и приступает к работе. (см. подробнее симметричные/ассимитричные криптосистемы, криптосистемы с открытыми/закрытыми ключами)
  3. Использовать контрольную сумму, хэш случайной строки и т.п., которые будут каждый раз проверятся, чтобы установить подлинность запроса.

На самом деле, если речь идёт о деньгах, все эти танцы с бубном вполне оправданы. Но, как учит нас мистер Кевин Митник - какой бы сложной ни была система, критическая уязвимость - это человеческий фактор :) Так что приступим к авторизации и оставим проблемы безопасности данных на совесть вашего бюджета.

Продолжение статьи Создаём собственный API-5 Вы можете прочитать на сайте "Веб-разработка? Это просто!".
В избранное