PHP: торгуй смело!
Никита Кислицин
Xakep, номер #056, стр. 056-078-1
(nikitoz@real.xakep.ru)
В прошлом выпуске мы приступили к написанию собственной системы интернет-торговли. Тогда я рассказывал о создании пользовательской части проекта, сегодня же речь пойдет о реализации административного интерфейса системы. А чтобы не повторяться (похожие задачи мы уже не раз решали), существенное внимание я уделю не затрагиваемой до сих пор технологии web-сессий; также речь пойдет о проблемах оптимальной настройки интерпретатора PHP и веб-сервера Apache.
Что такое сессия?
Что такое сессия, ты, я полагаю, знаешь не понаслышке :). Технология же сессий в рамках web-программирования - вещь значительно более приятная. Основная идея здесь заключается в том, что программисту предоставляется возможность сохранять какие-то управляющие данные на сервере в некотором адресном пространстве, доступ к которому однозначно идентифицируется при помощи специального длинного ключа - так называемого идентификатора сессии (session id). Таким образом, сессия - это набор информации, хранящейся на сервере, доступ к которой имеет лишь интерпретатор PHP, пользователю же совсем не обязательно об этом знать.
Для чего все это нужно? Причин, побудивших создателей PHP включить в язык поддержку сессий, несколько. Во-первых, абсолютно все web-разработчики сталкиваются с проблемой передачи переменных в рамках одного сеанса. Так, например, некоторые кодеры вешают пользователю множество кукисов, которые при каждом обращении к серверу гоняются туда-сюда. Некоторые передают нужные данные посредством GET и POST-запросов (мы до сих пор делали именно так). Оба варианта на редкость наивны, неудобны, небезопасны, да и попросту глупы (здесь нельзя полностью согласиться с автором - очень многие программисты используют GET и POST-запросы для передачи параметров - прим. ред.). Так, например, если юзер пользуется для доступа в интернет локальной сетью, все пакеты могут быть легко отснифаны. Соответственно, и его парольчики, plain-text'ом летящие от роутера к роутеру, будут у злоумышленника как на ладони (опять же, если сетка построена на свитчах, а шлюзом в инет является роутер, маловероятно, что пакеты с паролями будут перехвачены - прим. ред.). Кроме того, никто не даст стопроцентной гарантии, что данные не фальсифицированы пользователем. Поэтому нам приходилось после каждого запроса пользователя заново проверять полученные данные на достоверность - ведь он, например, мог поменять логин на чужой, и получить доступ к системе с чужими правами. Это, помимо чисто программистских проблем, создавало ненужную в серьезных задачах нагрузку на сервер - мы каждый раз составляли запрос, напрягали SQL-сервер, а потом уже парсили результат sql-запроса.
Все это лишнее, достаточно лишь один раз удостовериться в правильности введенных данных, разместить в пространстве сессии идентификатор пользователя, которому можно уже на 99.999% доверять (честно говоря, злоумышленник и к этим данным может получить доступ, но это уже проблема системного администратора). Ведь любая сохраняемая переменная криптуется стойким алгоритмом, а доступ к ней осуществляется с помощью 128-битного ключа, подобрать который очень сложно :).