Постоянные процессы, механизмы управления сеансами и так далее Большинство из них мы рассмотрим в последующих примерах, но, поскольку сохранение информации является одной из основных идей разработки серверных сценариев, коротко рассмотрим все эти приемы по порядку.
Параметры запроса в строке URL
С этим приемом мы познакомились выше в этой главе: жестко определенные параметры URL в динамически сгенерированных гиперссылках встраиваются в страницы ввода, возвращаемые в качестве ответа. Включение имени сценария и его входных параметров в такие ссылки позволяет непосредственно управлять действиями следующей страницы при их выборе. Параметры передаются от клиента на сервер автоматически, как часть запроса в стиле GET.
Передача параметров запроса является простой задачей — достаточно из CGI-сценария вывести в стандартный поток вывода корректно сформированный адрес URL в составе страницы ответа (соблюдая при этом некоторые соглашения по экранированию, с которыми мы познакомимся далее в этой главе). Ниже приводится фрагмент из реализации клиента электронной почты с веб-интерфейсом, пример которого демонстрируется в следующей главе:
script = "onViewListLink.py" user = ‘bob’ mnum = 66 pswd = ‘xxx’
site = ‘ pop.myisp.net’
print(‘<a href="%s?user=%s&pswd=%s&mnum=%d&site=%s">View %s</a>’ % (script, user, pswd, mnum, site, mnum))
Получающийся в результате адрес URL содержит достаточно информации для управления следующим сценарием, который будет вызван щелчком по гиперссылке:
<a href="onViewListLink.py?user=bob&pswd=xxx&mnum=66&site=pop.myisp. net">View 66</a>
Параметры запроса играют роль переменных в памяти и позволяют передавать информацию между страницами. Их удобно использовать для передачи информации между страницами в пределах одного и того же сеанса работы. Поскольку каждый сгенерированный адрес URL может включать различные параметры, такая схема позволяет обеспечить контекст в зависимости от действий пользователя. Каждая ссылка в списке доступных для выбора альтернатив, например, может подразумевать выполнение различных операций, определяемых различными значениями параметров. Кроме того, пользователи могут помещать ссылки с параметрами в закладки, чтобы вернуться к определенному этапу в последовательности взаимодействий.
Но поскольку сохраненная таким способом информация теряется при закрытии страницы, этот прием бесполезен, когда необходимо сохранять данные между сеансами. Кроме того, данные, добавленные в конец адреса URL, видны пользователю и могут сохраняться в файле журнала на сервере; в некоторых ситуациях может потребоваться зашифровать их вручную, чтобы исключить возможность подсмотреть их или подделать.
Скрытые поля форм
С программной точки зрения скрытые поля генерируются серверным сценарием как часть HTML-разметки страницы ответа и позднее возвращаются клиентом вместе с другими данными, введенными в форму. Приведем еще один пример из следующей главы:
print(‘<form method=post action="%s/onViewSubmit.py">’ % urlroot) print(‘<input type=hidden name=mnum value="%s">’ % msgnum) print(‘<input type=hidden name=user value="%s">’ % user) print(‘<input type=hidden name=site value="%s">’ % site) print(‘<input type=hidden name=pswd value="%s">’ % pswd)
Подобно параметрам запроса скрытые поля форм могут также служить аналогами переменных в памяти, сохраняющими информацию о состоянии от страницы к странице. Кроме того, как и при использовании параметров запроса, такие своеобразные переменные встраиваются непосредственно в страницу, поэтому скрытые поля форм удобно использовать для сохранения информации между обращениями к страницам в пределах отдельного сеанса работы, но они непригодны для сохранения данных между сеансами.
И подобно параметрам запроса и cookies (рассматриваются далее) скрытые поля форм доступны пользователям — хотя они и не отображаются на страницах и в адресах URL, тем не менее их значения можно увидеть, отобразив исходную HTML-разметку страницы. Таким образом, скрытые поля форм не обеспечивают безопасность данных — в некоторых ситуациях также может потребоваться зашифровать встроенные данные, чтобы исключить возможность подсмотреть их на стороне клиента или подделать при отправке формы.
Cookies, расширение лежащего в основе модели Веб протокола HTTP, предоставляют возможность северным веб-приложениям напрямую управлять сохранением информации на компьютере клиента. Поскольку эта информация не встраивается в разметку HTML веб-страниц, она сохраняется дольше, чем длится сеанс работы. Благодаря этому прием на основе cookies идеально подходит для сохранения информации в перерывах между сеансами.
С функциональной точки зрения HTTP cookies являются строками информации, хранящимися на компьютере клиента и передаваемыми между клиентом и сервером в заголовках сообщений HTTP. В процессе вывода страницы ответа серверные сценарии генерируют заголовки HTTP, предлагающие клиенту сохранить cookies. Позднее веб-броузер клиента генерирует заголовки HTTP, в которых обратно отправляются все cookies, соответствующие серверу и запрашиваемой странице. В результате информация, хранящаяся в cookies, встраивается в потоки данных подобно параметрам запроса и полям форм, только содержится она не в разметке HTML страницы, а в заголовках HTTP. Кроме того, данные в cookies могут постоянно храниться на стороне клиента и использоваться для сохранения информации между сеансами и обращениями к страницам.
Для разработчиков веб-приложений в состав стандартной библиотеки Python включены инструменты, упрощающие передачу и прием: модуль http.cookiejar выполняет обработку HTTP cookies на стороне клиента, взаимодействующего с веб-серверами, а модуль http.cookies упрощает задачи создания и приема cookies серверными сценариями. Кроме того, модуль urllib.request, с которым мы познакомились ранее, поддерживает операцию открытия адресов URL с автоматической обработкой cookies.
Использованная литература:
Марк Лутц — Программирование на Python, 4-е издание, II том, 2011
