Отправляет 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
Автор
Александр Левитас

Статистика

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

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


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

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

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

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

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

Сейчас мы реализуем последний штрих к этой картине. Вернее, я дам вам идею, как можно это сделать. Скажу сразу, идея не отличается особенной производительностью, т.к. в ней полно вложенных циклов и рекурсии. Если вам покажется эта часть критически важной, оставьте свой отзыв в комментариях и я изменю код на более производительный. Кроме того, в рамках решения потенциальных проблем безопасности, было бы неплохо ограничить длину пользовательского запроса и ввести таймаут. Таймаут - на соединение между Host 1 и Host 2. Длинна (сериализованного или десериализованного) запроса -для того, чтобы вам не устроили DoS. Бывают же доброжелатели.

В общем, эти моменты я оставляю на ваше усмотрение и привожу пару последних классов в этой серии статей, которые позволят добавлять фильтры к аргументам. Кстати, как фильтровать - это тоже вопрос из серии прав доступа. Возможно, у вас появится такой серьёзный и крупный клиент, которому понадобится предоставить метод в духе api_any_query(). Хотя, тогда он сможет у вас украсть всю базу ;) Но, тем не менее.

Полный текст статьи Создаём собственный API - 7 а также другие статьи, посвященные вопросам веб-разработки, Вы можете на сайте Веб-разработка? Это просто!.

В избранное