LXF83:Python
|
|
|
Содержание |
Работа с базами данных и web-программирование
ЧАСТЬ 3 Что может быть мощнее связки «база данных + интернет»? А если к этому добавить еще и Python... Чтобы почувствовать все это на практике, погрузимся сегодня в пучины SQL-запросов и HTTP-ответов вместе с Сергеем Супруновым.
Мы уже видели, что Python прекрасно подходит для работы с текстом. А что такое интернет-страницы, которые миллионы серверов Apache ежедневно миллиардами отдают на растерзание нашим браузерам? По сути, тот же текст, только немножко «гипер»... А значит, если нам нужно будет формировать html-страницу динамически, то Python прекрасно с этим справится. И никаких препятствий для разработки на нем CGI-сценариев не существует – web-серверу, по большому счету, безразлично, как именно выполняется скрипт и на каком языке он разработан: лишь бы он умел читать данные из потока ввода и переменных окружения да отдавать текст в стандартный выходной поток.
Впрочем, если вы жаждете скорости, то к вашим услугам mod_Python, да и в режиме FastCGI Python работать умеет. Но сейчас у нас разговор все же не о настройках CGI, а о Python, так что вернемся к тому, ради чего мы эту статью начали.
Постановка задачи
С любым вопросом лучше всего разбираться на практическом примере. Поэтому мы будем «плясать» вокруг несложного и, в общем-то, достаточно банального CGI-приложения: гостевой книги. Заодно разберемся с тем, как Python взаимодействует с базами данных, где представляется разумным хранить все наши сообщения.
Но прежде чем перейти к рассмотрению кода (вы найдете его целиком на нашем диске), полезно будет дать кое-какую вводную информацию.
Универсальное «междумордье» CGI
CGI (Common Gateway Interface, общий шлюзовой интерфейс) был разработан как средство взаимодействия HTTP-сервера с программами, которые могут запускаться в операционной системе. Если говорить упрощенно, то CGI, передавая управление такой программе (обычно их именуют cgi-сценариями, хотя это вполне может быть и двоичный файл, разработанный на C/C++), формирует для нее определенное окружение. В частности, параметры HTTP-запроса, полученного от клиента, могут помещаться в определенные переменные окружения или передаваться cgi-программе как аргументы или как входной поток (STDIN). В ответ HTTP-сервер ждет данные, которые cgi-программа должна выдать в стандартный выходной поток (STDOUT), и передает их клиенту.
Таким образом, все, что требуется от cgi-программы, это способность получать необходимую для работы информацию из формируемой HTTP-сервером среды и возвращать ответные данные, соответствующие протоколу HTTP, чтобы web-клиент знал, что с ними делать.
Учимся посылать
Начнем с формирования HTTP-ответа. Чтобы браузер клиента мог его правильно обработать, он должен состоять из заголовка и тела, разделенных пустой строкой. В заголовке передается необходимая служебная информация, например, тип содержимого, его кодировка, указание браузеру запросить другой ресурс (так называемое перенаправление), и т.д. Простейший cgi-сценарий на языке Python может выглядеть так:
#!/usr/bin/Python # -*- coding: utf-8 -*- print ‘Content-Type: text/html\n’ print ‘<H3>Если вы это видите, значит все работает</H3>’
Первым оператором print мы формируем минимально необходимый заголовок – браузер клиента обязательно должен знать, каков тип пересылаемых ему данных (в нашем случае это простой текст, соответствующий формату HTML). Не забывайте о дополнительном переводе строки \n, необходимом для отделения заголовка от тела ответа. Ну и далее вы можете передавать любой HTML-код.
Аналогично могут передаваться любые объекты, поддерживаемые клиентом: изображения, звуковые файлы, css-таблицы и т.д. Главное, чтобы значение поля Content-Type (именуемое также MIME-типом) соответствовало содержимому.
Здесь играть, здесь не играть...
Однако какой смысл поручать формирование статических, по сути, страниц cgi-сценарию, если сам HTTP-сервер справится с этим намного лучше? В общем-то никакого. Разве что для общего развития... А вот в чем CGI по-настоящему силен, так это в формировании динамических страниц, содержимое которых зависит от информации, переданной пользователем.
Протокол HTTP предусматривает несколько способов передачи информации от клиента на сервер, называемых методами. Наиболее популярные из них – GET, POST, PUT и HEAD.
Метод GET позволяет вставлять информацию в URL, то есть в строку адреса запрашиваемого ресурса. Когда «Яндекс» вернет вам список искомых страниц, посмотрите на адресную строку в браузере – вот так данные и передаются методом GET. Кстати, обратите внимание на то, как все это кодируется, особенно если вы искали какое-то русское слово.
Если на сервер требуется передать больший объем информации, или ее желательно скрыть от любопытных глаз, используется другой метод – POST. В данном случае в заголовке передается лишь размер пользовательских данных, а сами данные пересылаются в теле запроса.
Метод PUT предназначается для размещения ресурсов на сервере и по соображениям безопасности практически не используется. Ну и, наконец, метод HEAD очень похож на GET, за тем исключением, что сервер в ответ на такой запрос возвращает не весь ресурс, а лишь информацию о нем, такую как дата последнего изменения, помещаемую в заголовке. Обычно используется прокси-серверами для определения «свежести» имеющихся у них данных – стоит ли запрашивать ресурс повторно или можно вернуть клиенту то, что есть в кэше.
Определенная сложность для разработчика cgi-сценария заключается в том, что данные, отправленные различными методами, передаются в сценарий по-разному. Так, информация, поступившая с помощью POST, подается на стандартный вход сценария и может быть считана оттуда, например, с помощью sys.stdin.read(size) или даже функцией raw_input() (хотя во втором случае сложнее контролировать объем принимаемых данных). Количество байт, которые требуется считать, можно получить из переменной окружения CONTENT_LENGTH (например, так: size = os.environ[‘CONTENT_LENGTH’]).
Если клиент использует метод GET, то данные поступят в сценарий через переменную среды QUERY_STRING. Метод, которым данные переданы (нужно же как-то разобраться, где их искать) можно всегда получить из REQUEST_METHOD.
Есть еще один особый случай. Если данные передаются методом GET, но с использованием «индексного» формата, который формируется тегом <ISINDEX>, то в этом случае они кодируются не в виде «переменная=значение&переменная=значение&...», а как «значение+значение+...». И cgi-сценарию они будут переданы, помимо QUERY_STRING, через аргументы командной строки, как если бы сценарий вызывался такой командой:
script.cgi arg1 arg2 arg3
То есть, на этот раз пользовательские данные можно будет получить как sys.argv[1] и т.д.
Как видите, огромное число вариантов, предусмотренных CGI-интерфейсом, которые все должны быть учтены при разработке сценария, может вызвать нервный тик даже у опытных программистов, которые и во сне потихоньку набивают по подушке какой-то код. А если еще вспомнить, что данные передаются в закодированном виде (это англичанам хорошо – взял значение переменной и работай, а нам-то с вами это значение вернется в виде %EC%E4%E0), да еще и о проверке этих данных нужно позаботиться, чтобы какой-нибудь начинающий хакер не попытался заставить наш сервер работать по-своему... Нет, обо всем этом лучше и не вспоминать. Благо у нас есть модуль cgi, в котором все это уже сделано!
Но о нем – чуть позже. Сначала пару слов нужно сказать о HTML-формах.
Формируем формы
Чтобы вам было проще понять рассматриваемый сегодня пример, коротко скажу про то, как же клиент выполняет передачу данных нашему cgi-сценарию. Конечно, продвинутые пользователи могут набрать GET-запрос вручную в адресной строке браузера. Хотя что мелочиться – ведь можно же сформировать и POST-запрос, подключившись телнетом на 80-й порт! Впрочем, обычные пользователи предпочитают более понятные и «осязаемые» способы, например, формы.
Как они выглядят, думаю, каждый знает. Создаются они с помощью тега <FORM>, внутри которого добавляются такие элементы, как <INPUT> (поле ввода) или <TEXTAREA> (многострочный редактор). Этим элементам, если их данные должны быть переданы на сервер, присваиваются имена с помощью атрибута name. Начальное значение задается параметром value и в дальнейшем для «редактируемых» полей может быть изменено пользователем. Когда пользователь нажимает кнопку «Отправить» (надпись на ней, в принципе, можно изменить), то браузер объединяет все данные полей в пары name=value, разделяя их символом &. Затем полученная таким образом строка передается на сервер методом, указанным в атрибуте method тега <FORM>. Путь к сценарию, который будет заниматься ее обработкой, задается атрибутом action этого же тега. Если action не задан, то данные передаются файлу, сформировавшему текущую страничку.
Если что-то не совсем понятно, обратитесь к коду разрабатываемой гостевой книги, который приведен ниже.
Наш спаситель – модуль cgi
Возвращаемся к обработке всего этого добра, которое сотни пользователей уже готовы обрушить на наш бедный сценарий. Мы решили воспользоваться стандартными средствами Python, и здесь все действительно очень просто – импортируйте модуль cgi и, создав объект класса FieldStorage, вы получите через него доступ ко всем данным, переданным пользователем, независимо от используемого метода:
import cgi data = cgi.FieldStorage() for entry in data.keys(): print ‘Переменная %s имеет значение %s’ % (entry, data[entry].value)
Если вам нужно получить значение определенного поля, это делается так:
field = data[‘field’].value
Помимо пользовательских данных, объект класса FieldStorage содержит информацию и о полях заголовка (в нашем примере их можно получить из словаря data.headers). MIME-тип данных (передаваемый полем заголовка Content-Type) можно получить из атрибута data.type. Через этот же объект может быть выполнена и загрузка файла.
С помощью методов keys() и has_key() можно выполнять обработку полученных данных в цикле и проверять наличие той или иной переменной. Кстати говоря, проверять наличие переменной во входных данных, прежде чем приступать к их обработке, нужно непременно – ведь запрос формируется клиентом, а кто знает, что у него на уме?
Базируем данные
Итак, получать данные от клиента мы научились. Отправлять тоже умеем. Осталось придумать, как эти данные лучше всего хранить. Конечно, для несложной гостевой книги с небольшой нагрузкой вполне хватило бы и текстовых файлов. Правда, там есть свои сложности – если сразу пять человек захотят высказать свое мнение о вашей крутейшей домашней страничке, то сценарию придется каким-то образом регулировать доступ к файлу-хранилищу (как минимум, обрабатывать ситуацию, если файл уже открыт на запись другим экземпляром сценария). Но зачем нам все эти головные боли? Если мы так ловко отвертелись от необходимости вручную разбирать HTTP-запросы, то неужели не найдем что-то подходящее на этот раз?
Конечно, найдем! И это «что-то» называется системой управления базами данных (в просторечье – СУБД). Теперь наше дело – отправить запрос и получить ответ. Все остальное – уже не наша забота.
Для этого примера я выбрал в качестве «ответственного» за хранение данных сервер баз данных PostgreSQL. Поскольку мы пишем ну очень простую гостевую книгу, то и структура базы будет у нас элементарной – одна таблица с тремя полями: время публикации сообщения, имя автора и, собственно, само сообщение:
admin@toshiba:~$ psql Welcome to psql 8.1.4, the PostgreSQL interactive terminal. guestbook=# create user “www-data” nocreatedb nocreateuser; CREATE ROLE admin=# create database guestbook with owner “www-data”; CREATE DATABASE admin=# \connect guestbook Вы подсоединились к базе данных “guestbook”. guestbook=# create table guestbook ( guestbook(# datum timestamp, author varchar, message varchar); CREATE TABLE guestbook=# alter table guestbook owner to “www-data”; ALTER TABLE guestbook=# \q admin@toshiba:~$
Пожалуй, единственное, что здесь нужно пояснить, это почему базе и таблице мы назначили владельцем пользователя www-data. Просто к ним будет обращаться cgi-сценарий, работающий с правами HTTP-сервера Apache, который, в свою очередь, исполняется от имени данного пользователя [в вашем дистрибутиве он может назваться по-другому, – прим. ред.]. А PostgreSQL по умолчанию требует, чтобы имя пользователя в БД совпадало с его системным именем. Мне это кажется достаточно удобным, хотя вы, конечно, можете поступить по-своему.
DB API на страже унификации
Осталось разобраться, как же Python взаимодействует с базами данных. Для этого Python предоставляет DB API – специальный интерфейс, унифицирующий набор методов, которые будут одинаково работать независимо от того, с какой СУБД мы взаимодействуем. Для работы с PostgreSQL нам понадобится модуль PyPgSQL (в стандартной поставке его может не оказаться, но ваш менеджер пакетов наверняка будет в курсе, как его установить; кстати, это не единственный модуль – у вас, возможно, будет PyGreSQL, который работает ничуть ни хуже и с теми же самыми методами).
DB API определяет стандартные методы работы с базами данных, так что, какой бы модуль вы ни загрузили и с какой бы СУБД ни работали (будь то MySQL, PostgreSQL, SQLite или что-то еще), меняться будет только имя модуля. Главное, чтобы используемый модуль соответствовал DB API. Рассмотрим коротко основные методы:
conn = connect(dsn=’localhost’, user=’admin’, password=’superparol’, database=’mydb’)
Так осуществляется подключение к базе. В зависимости от ситуации, вам может потребоваться указать только нужные параметры (например, имя хоста ‘localhost’ подразумевается по умолчанию).
cur = conn.cursor()
Курсоры поддерживаются далеко не всеми СУБД, но для общности в DB API они введены и, в случае необходимости, должны эмулироваться модулями сопряжения искусственно. Так что не забывайте отправлять все ваши запросы через курсор.
cur.execute(‘’’SELECT * FROM mytable’’’)
Так выполняется SQL-запрос. Если в строке запроса используются знакоместа %s, то вторым параметром передается список переменных-значений, причем в SQL-запросе знакоместа не требуется окружать апострофами – модуль сделает это самостоятельно в зависимости от типа переменной.
cur.fetchall()
Возвращает двумерный список (строки – поля) полученных от СУБД данных. Существуют и другие методы, ознакомиться с которыми вы сможете в документации или с помощью знакомой вам функции dir() да пары-тройки несложных экспериментов.
Закрепляем на практике
Перейдем к рассмотрению нашего примера. Начнем стандартно – укажем кодировку, подключим нужные модули:
#!/usr/bin/Python # -*- coding: utf-8 -*- import PyPgSQL.PgSQL as pg import cgi
Далее, определим две функции. Первая будет отвечать за добавление нового сообщения в базу:
def addMessage(author, message): db = pg.connect(database=”guestbook”) c = db.cursor() c.execute(“””INSERT INTO guestbook (datum, author, message) VALUES (‘now’, %s, %s);”””, (author, message)) c.close() db.commit() db.close() print “Content-Type: text/html” print “Location: ?#form\n”
Как видите, все очень даже логично: устанавливаем соединение с БД (поскольку в нашем случае подключение выполняется с именем текущего системного пользователя, то достаточно указать только имя базы), создаем курсор (в PostgreSQL они не применяются, но они эмулируются каждым модулем, претендующим на соответствие DB API), выполняется запрос, закрывается курсор, фиксируются изменения (PostgreSQL использует транзакции, поэтому выполнение метода commit() обязательно, иначе ваши изменения не будут сохранены), и, наконец, закрываем само соединение с базой. В поле datum заносим значение встроенной переменной PostgreSQL – now, которая каждый раз заменяется текущим значением даты и времени.
Ну и печать заголовка «Location» выполняется для того, чтобы перенаправить пользователя на этот же сценарий, но уже без параметров – мы же должны показать клиенту, что он на самом деле ввел? (Якорь #form используется, чтобы автоматически прокрутить страничку на последнее сообщение).
Вторая функция будет отвечать за вывод на экран уже оставленныхв книге записей, а также за форму, с помощью которой можно будет добавить и свое высказывание:
def showGB(): db = pg.connect(database=”guestbook”) c = db.cursor() c.execute(“””SELECT datum, author, message FROM guestbook ORDER BY datum;”””) res = c.fetchall() c.close() db.close()
В этом фрагменте мы выбираем все строки из нашей таблицы данных, сортируя их по дате. Результат сохраняется в переменной res, с которой и будем работать. Теперь осталось лишь аккуратненько разложить наши данные по табличкам и вывести их на экран:
print “Content-Type: text/html\n”
print “<H1 style=’color:#7777FF’><U>Велькам к нам в гости!</U></H1>”
for item in res:
print “””<TABLE width=’90%%’>
<TR><TD><SMALL>Товарищ <B>%s</B> поведалнам следующее:</SMALL>
<TD align=’right’><SMALL>%s</SMALL>
<TR><TD style=’background-color:#DDDDFF’ colspan=’2’>%s
</TABLE>””” % (item[1], str(item[0])[:19], item[2])
print “<HR><A name=’form’><H3>Присоединяйтесь к дискуссии:</H3>”
print “””<FORM method=’GET’>
Ваше имя: <INPUT type=’text’ name=’author’><BR>
Что вы думаете по этому поводу:<BR>
<TEXTAREA name=’message’ rows=’5’ cols=’80’></TEXTAREA><BR>
<INPUT type=’submit’ value=’Отправить’>
</FORM>”””
Смысл конструкции str(item[0])[:19] заключается в том, чтобы в строке времени отсечь ненужные нам миллисекунды, которые сохраняются в поле типа timestamp. После всех опубликованных сообщений выводим форму добавления нового, чтобы каждый мог присоединиться к нашей дискуссии. Кстати, в теге <FORM> мы не указали параметр action, поскольку данные будут передаваться на обработку этому же сценарию (благодаря чему имя сценарию можно присвоить любое). Наконец, последний фрагмент:
form = cgi.FieldStorage() if form.has_key(“message”) and form.has_key(“author”): author = cgi.escape(form[“author”].value) message = cgi.escape(form[“message”].value) message = message.replace(“\n”, “<BR>”) addMessage(author, message) else: showGB()
Создаем FieldStorage-объект, и если в нем есть заполненные поля message и author (то есть запрос был сформирован из заполненной пользователем формы), то, немножко их обработав (функция cgi.escape() заменяет все «неблагонадежные» символы – например, < – их стандартными SGML-сущностями, в данном случае – <), передаем функции addMessage(). Обработка нужна для того, чтобы злоумышленник не мог ввести в поле сообщения или имени автора что-нибудь такое:
<SCRIPT>alert(‘Да пошли вы все!’);</SCRIPT>
К слову, пренебрегать проверкой введенных данных ни в коем случае нельзя. Зайдите как-нибудь на securitylab.ru и посмотрите, сколько уязвимостей типа «XSS» обнаруживается каждый месяц! Так что шутки шутками, но последствия могут быть очень серьезными.
Куда же нам теперь идти?
Итак, что-то вполне работоспособное у нас есть (см. рисунок). Но как вы может догадаться, наша гостевая очень далека от совершенства. Что еще можно сделать? Ну, например, разбить на страницы. Пока сооб- щений в ней будет не больше дюжины, сойдет и так. А когда их число дойдет до сотни, то редкий пользователь дождется окончания загрузки всех данных. Можно дать пользователям возможность использовать некоторые HTML-теги, чтобы их сообщения выглядели более красочно. Можно добавить смайликов... А можно даже сделать модуль админис- трирования, позволяющий редактировать или удалять сообщения, а также отвечать на них. Так что работы непочатый край. Дерзайте – не буду вам мешать. LXF
