Всем привет. Сегодня мы поговорим о переменных переменных и выясним, зачем они всё таки нужны (или не нужны).

В самом простом виде переменные переменных показаны в справке PHP. А именно –

$a = 'hello';
$$a = 'world';
echo $a . ${$a}; 

Подобная кривая конструкция выдаст на экран hello world. Другими словами, ${$a} эквивалентна вызову $hello. Не правда ли.. ужасно? Добавим сюда проблему неоднозначности, которая возникает при попытке обратиться к элементам массива (это подробно описано в справке по адресу http://ua.php.net/manual/en/language.variables.variable.php), добавим сюда возможность добавлять к имени переменной любое количество знаков доллара, о которой обычно не пишут в учебниках, и возникнет вполне закономерное недоумение – зачем это вообще нужно?

Самое главное правило, которого должен придерживаться любой разработчик в любом проекте – код пишется для людей, а не для машин. Это правило помимо негласного этикета в среде профессионалов в виде комментариев и отступов, ещё и экономически обоснованно. Дело в том что сегодня разработка ПО стремительно дешевеет (не без помощи демпинга индусов). Прямым следствием является то, что поддерживать код должно быть дешевле, чем его писать. Т.о. становится понятно, что читабельный, понятный и простой в понимании код, куда как более ценен, чем процессинг формы на Brainfuck’e (кто не в курсе, пусть насладится http://en.wikipedia.org/wiki/Brainfuck), пусть даже на Brainfuck’e этот процессинг работает на 0.0001 секунду быстрее.

Добавим сюда огромные вычислительные возможности современных серверов, которые могут прожевать мегаметры самого бездарного кода в течение секунды и станет понятно, что деньги, затрачиваемые на поддержку, должны быть минимальными. Разработчик должен иметь возможность спокойно и быстро разобраться в коде, написанном соседней командой, даже через пару лет после финального релиза проекта. Реалии PHP вполне это позволяют – всё таки это скриптовый язык, а не ассемблер.
(more…)

Всем привет. Сегодня мы коснёмся одной очень интересной темы, которая очень слабо освещена в рунете. Тема эта больше теоретическая, и, скорее всего, в обычных проектах вы с этим не столкнётесь никогда, но уж если столкнётесь и не будете знать, что перед вами, пара-тройка бессонных ночей вам гарантированна. С другой стороны, если перед вами возникнет задача, где можно использовать пивот, вы сможете резко повысить производительность вашей системы. А для веб производительность всегда была критична. Попробуем же потратить пол часа сейчас и отлично выспаться потом, когда-нибудь в будущем 🙂

Итак, пивот. Что это такое и с чем его едят? Скажу сразу, к пиву это не имеет никакого отношения. А имеет отношения к реляционным базам данных, например, к MySQL. Пивот – это разворот таблицы. Или таблица разворота. Вот видите, это уже, практически, пивот. Придумали эту штуку два оч. умных дядьки – Бил Джелен и Майк Александер. Подробнее об истории пивота можно посмотреть в английской википедии (http://en.wikipedia.org/wiki/Pivot_table).

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

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

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

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

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

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

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

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

(more…)

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

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

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

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

(more…)