Правда о сессиях - GET- и POST-данные

ОГЛАВЛЕНИЕ

GET- и POST-данные

Существует ещё два метода, которые клиент может использовать для
отсылки данных на сервер, и эти методы существуют гораздо дольше кук.
Клиент может поместить информацию в запрашиваемом URLе в строке запроса
или прямо в пути, хотя последний случай требует специфического
программирования, которое не освещено в этой статье. Как пример
использования строки запроса рассмотрим следующий:
GET /index.php?foo=bar HTTP/1.1
Host: www.example.org

Принимающий скрипт index.php может обратиться к $_GET['foo'] для получения значения параметра foo. Вследствие этого, большинство PHP-разработчиков говорят об этих данных как о GET-данных
(другие иногда ссылаются на них как на данные из запроса или
URL-переменные). Распространённой причиной путаницы является то, что
GET-данные могут существовать и в POST-запросе, так как они являются
просто частью запрашиваемого URLя и не зависят от метода запроса.

Другим методом, которым клиент может воспользоваться для
отсылки информации, является использование содержимого HTTP-запроса.
Этот способ требует, чтобы методом запроса являлся POST:
POST /index.php HTTP/1.1
Host: www.example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 7
foo=bar

В этом случае принимающий скрипт index.php может обращаться к $_POST['foo'] для получения значения параметра foo. PHP-разработчики обычно ссылаются на эти данные как на POST-данные, и именно так браузер передаёт данные, отсылаемые формой, в которой указано method="post".

Вообще же говоря, запрос может содержать и оба типа данных:
POST /index.php?getvar=foo HTTP/1.1
Host: www.example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
postvar=bar

Эти два дополнительных метода отправки данных в запросе могут
обеспечить замену кукам. В отличие от кук, поддержка GET- и POST-данных
не является опциональной, поэтому эти методы могут также быть более
надёжными. Рассмотрим уникальный идентификатор, называемый PHPSESSID {Б.С. начинающим: вообще, это имя-по-умолчанию может быть изменено разработчиком PHP-приложения на другое.}, включённый в запрашиваемый URL:
GET /index.php?PHPSESSID=12345 HTTP/1.1
Host: www.example.org

{Б.С. начинающим: в действительности встроенный PHP-шный
механизм управления сессией генерирует более длинные, чем 12345,
идентификаторы сессии.}

Этим достигается та же цель, что и заголовком Cookie,
так как клиент идентифицирует себя; однако такой способ требует гораздо
большего участия разработчика. Как только кука установлена, —
обязанностью браузера является возвращать её в последующих запросах.
Для передачи же уникального идентификатора посредством URLя разработчик
должен обеспечить, чтобы все ссылки, кнопки отправки форм и т.п.
содержали соответствующую строку запроса (впрочем, PHP может ему в этом
помочь, если вы включите директиву session.use_trans_sid). К
тому же, GET-данные отображаются в URLе и гораздо уязвимее, чем куки.
Фактически, ничего не подозревающие пользователи могут сохранить такой
URL в закладках, послать его другу или сделать с ним что угодно, что
может случайно раскрыть уникальный идентификатор.

Хотя POST-данные могут быть раскрыты с меньшей вероятностью,
передача уникального идентификатора как POST-переменной требует, чтобы
все запросы пользователя осуществлялись методом POST. Обычно этот
вариант не удобен, хотя дизайн вашего приложения и может сделать его
более жизнеспособным.