 |
|
|
|
Внутренний веб-сервер
Внутренний веб-сервер Что админу хорошо, то пользователю – смерть.
Народная мудрость Очень часто системному администратору, работающему в небольшой фирме, попутно приходится разрабатывать программы для внутренних нужд компании. Требования к подобному ПО, как правило, невысоки, но это с лихвой компенсируется очень сжатыми сроками, отводимыми на разработку. Освоить Delphi для того, чтобы на предприятии появилась программа-каталог пользователей Интернета или программа, формирующая материальные отчеты, было бы просто замечательно. Но времени на подобные вещи, как обычно, не хватает. И потому приходится идти другим путём. В данной статье я хочу рассказать о своем опыте использования веб-сервера для решения подобных задач. Почему был выбран столь экзотический способ? Во-первых, Perl я знаю несколько лучше, чем Delphi или C++ Builder. Во-вторых, такой подход без лишних усилий позволяет создавать клиент-серверные приложения, с которыми одновременно могут работать сотни пользователей, не заботясь о разработке клиентских программ – с этой ролью отлично справится любой браузер. В-третьих, налицо независимость от конкретных платформ и операционных систем – для сервера достаточно, чтобы на нем мог работать Apache + Perl (вы можете использовать и другую связку), от клиентов требуется лишь поддержка какого-нибудь графического обозревателя. И наконец, времени на разработку и сопровождение ПО в данном случае затрачивается заметно меньше, чем при «традиционных» способах. Для наглядности рассмотрим в общих чертах процесс разработки незатейливого приложения: каталога пользователей ADSL, в который будут заноситься сведения об абонентах (фамилия, адрес, номер телефона), параметры конфигурации (IP-адреса, интерфейсы, номера PVC), параметры линии (длина, диаметр жилы, сопротивление шлейфа) и т. д. В целях экономии места будет рассмотрена только первая функция (работа со сведениями об абонентах). Очень многие детали придется опустить. Так, не будут рассмотрены особенности Perl-модулей, подключаемых к нашим сценариям, способы работы с базой данных и т. д. Читателю понадобятся, по крайней мере, базовые знания Perl, HTML, PostgreSQL (или какой-нибудь другой СУБД). Если материал статьи окажется вам интересен, я постараюсь разложить все по полочкам в следующих статьях, оставляйте ваши отзывы на форуме журнала «Системный администратор». Подготовительные мероприятия Итак, прежде всего нам нужно собрать сервер. Я остановил свой выбор (поскольку все это уже есть и работает) на следующем ПО (правда, кое-что из этого списка уже пора бы обновить):
Рассматривать установку и конфигурирование всего этого я не буду – все довольно подробно описано и на страницах журнала, и на бескрайних просторах Интернета. Выбор именно этого ПО – вопрос, скорее, личных предпочтений, поскольку по каждому из пунктов можно привести массу как положительных, так и отрицательных доводов. В конце концов с тем же успехом (с поправкой на более высокие требования к ресурсам и вопросам безопасности) можно использовать и связку «Windows2003 – IIS – ASP – MSSQL». Структура базы данных и доступ к СУБД Начнем разработку с определения структуры БД. Нужно заметить, что это итерационный процесс, то есть обычно при разработке сценариев выясняется, что база данных должна быть несколько иной, потом корректировки вновь вносятся в код сценариев, снова исправляется БД и так до тех пор, пока разработчик не осознает, что эффект от дальнейшего улучшения уже не окупает затрат на исправления. Но мы остановимся на первой итерации, тем более что наша задача – показать сам принцип. Итак, создадим БД с именем adsl, владельцем которой будет пользователь adsluser с паролем password. В ней нам потребуются следующие таблицы:
И еще одна таблица для хранения служебной информации:
В данном случае мы минимально задействуем расширенные возможности PostgreSQL, что позволит почти ничего не менять при использовании, например, MySQL. Шаблон сайта – модульный подход Поскольку переписывать все сначала при необходимости расширить функциональность нашего приложения – занятие не очень интересное, применим модульный подход. Пусть основной сценарий отвечает только за предоставление доступа к имеющимся функциям, а каждая функция будет реализована отдельным скриптом. Кроме того, часто используемые операции будем выносить в наш модуль My::Insite. Выглядеть базовый сценарий будет примерно так: #!/usr/bin/perl –w #-------------------------------------------- adsl.cgi use My::Insite; # Подключаемся к БД и создаем объект CGI для работы с HTTP $dbh = My::Insite->DBConnect("adsl", "adsluser", "password"); $cgi = My::Insite->CGIStart(); # Считываем значение HTTP-параметра «action» ($action = $cgi->param("action")) or $action = ""; # Выполняем процедуру выхода if($action eq "logoff") { &doLogoff; } # Процедура авторизации if($action eq "logon") { $savedLogin = $cgi->param("login"); $savedPassword = $cgi->param("password"); # ищем сессию для заявленного логина ($sSessId, $sPassword) = $dbh->selectrow_array(" SELECT id, password FROM sessions WHERE login=? ", undef, $savedLogin); # если не нашли – повторный запрос авторизации if(!$sSessId) { &doLogon("Failed"); } # если сессия есть, но пароль не соответствует введенному, повторный запрос авторизации if($sPassword ne $savedPassword) { &doLogon("Wrong"); } # Если все нормально – сохраняем идентификатор сессии в cookie $cookie = $cgi->cookie(-name => "sessid", -value => $sSessId); print $cgi->header(-cookie => $cookie); print "Авторизация выполнена успешно."; print " <A href="adsl.cgi">Продолжить...</A>"; exit; } # action не имеет значения, пытаемся извлечь из cookie идентификатор сессии $sessId = $cgi->cookie("sessid"); # Если безуспешно – уходим на авторизацию if(!$sessId) { &doLogon("First"); } # Если sessId есть, пытаемся получить пользователя этой сессии ($sLogin) = $dbh->selectrow_array(" SELECT login FROM sessions WHERE id=?; ", undef, $sessId); # Если удачно – открываем сессию, иначе – на авторизацию if($sLogin) { $session = My::Insite->SessOpen($dbh, $sessId); } else { &doLogon("Fialed"); } # Выбираем из БД и выводим на экран список модулей print $cgi->header; $sth = $dbh->prepare("SELECT * FROM st_modules ORDER BY orderby;"); $sth->execute; print "<P align="right">Вы вошли под именем $sLogin | "; print " <A href="?action=logoff">Выход</A></P>"; while($rhash = $sth->fetchrow_hashref) { # Печатать будем только те модули, для которых в поле allow есть имя вошедшего пользователя if($$rhash{allow} =~ m($sLogin)) { print "<DT><A href="$$rhash{link}"> $$rhash{name}</A>"; print "<DD>$$rhash{description}<BR>"; } } # Все закрываем (в принципе это не обязательно – все и так закроется) My::Insite->SessClose($session); My::Insite->DBDisconnect($dbh); exit; #-------------------------------------------- подпрограммы sub doLogon { # подпрограмма авторизации $status = shift @_; if($status eq "Wrong") { $status = Неправильный логин или пароль."; } elsif($status eq "Failed") { $status = Ошибка подключения данного пользователя."; } else { $status = Введите логин и пароль:"; } print $cgi->header(); print <<__HTML__; <CENTER><H3>$status</H3><FORM method="POST"> <TABLE border="1"><TR><TD><TABLE> <INPUT type="hidden" name="action" value="logon"> <TR><TD>Login:<TD><INPUT type="text" name="login" value=""> <TR><TD>Password: <TD><INPUT type="password" name="password" value=""> <TR><TD colspan="2" align="center"> <INPUT type="submit" value="Войти"> </TABLE></TABLE></FORM></CENTER> __HTML__ exit; } sub doLogoff { # подпрограмма закрытия сеанса # Записываем cookie с истекшим «сроком годности» (отрицательное значение параметра expire), что уничтожит cookie в памяти $cookie = $cgi->cookie(-name => "sessid", -value => "", -expires => "-1d"); print $cgi->header(-cookie => $cookie); print "<HEADER>"; print "<META http-equiv="refresh" content="1;url=adsl.cgi">"; print "</HEADER>"; print "До новых встреч!"; exit; } Задача данного сценария – выполнить авторизацию пользователя и предоставить ему список доступных для работы модулей. Управление поведением сценария осуществляется с помощью переменной «action», которая может иметь одно из следующих значений: logoff (закрыть сеанс), logon (выполнить процедуру авторизации, в ходе которой проверяется правильность пароля и открывается сессия, соответствующая данному пользователю, о чем делается запись в файлах cookie). Пустое значение данной переменной позволит вывести на экран перечень доступных модулей. Список модулей хранится в БД, в таблице st_modules, откуда он выбирается и выводится на экран, причем отображаются только те модули, для которых в поле allow содержится имя текущего пользователя. Больше ничего от главного сценария не требуется. Для подключения к приложению очередного модуля достаточно поместить в папку cgi-bin реализующий его сценарий и добавить запись в таблицу st_modules. То есть в этой таблице будет что-то похожее: adsl=> select link, name, allow from st_modules order by orderby;
Результат работы сценария adsl.cgi представлен на рисунках 1 и 2.
Рисунок 1
Рисунок 2 Модуль My::Insite в моем случае будет размещаться по такому адресу: /usr/local/lib/perl5/site_perl/5.6.1/My/Insite.pm. Узнать пути, по которым Perl ищет подключаемые модули, позволяет специальная переменная @INC: #!/usr/bin/perl #-------------------- testpath.pl
$, = " "; print @INC; exit; На моей машине результат был получен следующий: $ ./testpath.pl
Код модуля My::Insite представлен ниже: package My::Insite; use CGI; use DBI; use Apache::Session::Postgres; sub CGIStart { return CGI->new; } sub DBConnect { my($obj, $dbName, $dbUser, $dbPwd) = @_; return DBI->connect("dbi:Pg:dbname=".$dbName, $dbUser, $dbPwd); } sub DBDisconnect { my($obj, $dbh) = @_; $dbh->disconnect; return(1); } sub SessOpen { my($obj, $dbh, $sessId) = @_; tie %session, "Apache::Session::Postgres", $sessId, {Handle => $dbh, LockHandle => $dbh}; return(bless(\%session, $obj)); } sub SessClose { my($obj, $session) = @_; untie(%$session); return(1); } return(1); Как видите, сюда вынесены функции подключения к БД, работы с сессиями и т. д. Может показаться, что в некоторых функциях нет смысла. Например, зачем создавать CGIStart, которая только и делает, что вызывает функцию new() модуля CGI? Не проще ли вызывать эту функцию самому и не захламлять модуль? А теперь представьте, что вы решили вместо модуля CGI перейти на более функциональный. Что проще – переписывать все имеющиеся сценарии или изменить одну функцию в My::Insite? Думаю, в этом модуле все понятно без комментариев. Если что непонятно – всегда под рукой man DBI, man CGI, man Apache::Session. Доступ на сайт и Apache::Session Если вы доверяете всем сотрудникам или собираетесь ограничивать доступ к сайту «низкоуровневыми» средствами вроде брандмауэра для ограниченного круга лиц с равными правами, то этот пункт можно пропустить. В общем же случае желательно организовать проверку «подлинности» пользователя и соответствующим образом ограничивать его права в нашей программе. В серьезных случаях можно дополнительно организовать SSL-шифрование, но сейчас обойдемся без этого, чтобы не отвлекаться от основной цели. Пароли для простоты хранить и передавать будем в явном виде, признак правильного входа в приложение, а заодно и некоторые персональные настройки будем хранить, используя механизм сессий. В Perl это выглядит несколько сложнее, чем в PHP, зато проще сделать именно то, что нужно. Для работы понадобится модуль Apache::Session. Если на вашей системе такого нет, для FreeBSD его, как и большинство других модулей, можно установить из коллекции портов: # cd /usr/ports/www/p5-Apache-Session # make install Более универсальный путь, пригодный практически для всех систем – использование архива CPAN. Этот метод описан на страницах руководства man perlmodinstall. Так как база данных у нас есть, целесообразно для хранения сессионной информации использовать именно ее. Поэтому будем использовать подмодуль Apache::Session:: Postgres. Поскольку число пользователей нашего приложения ограничено и все они известны, то имеет смысл для каждого из них заранее создать сессию, в которой будут храниться все пользовательские данные, и при авторизации подключать именно ее. Такой подход позволит не беспокоиться об удалении старых сессий и о хранении идентификатора сессии между сеансами. Вручную создавать новую сессию не очень удобно, поэтому будем использовать такой небольшой сценарий: #!/usr/bin/perl –w #------------------------------------------ adsl-adduser.pl use DBI; use Apache::Session::Postgres; $login = $ARGV[0]; # первый аргумент – имя $password = $ARGV[1]; # второй – пароль # Запрашиваем все, что не передано в аргументах if(!$login) { print "Enter login: "; chomp($login = <>); } if(!$password) { print "Enter password: "; chomp($password = <>); } # Создаем новую сессию и сразу закрываем $dbh = DBI->connect("dbi:Pg:dbname=adsl", "adsluser", "password"); tie %session, "Apache::Session::Postgres", undef, {Handle => $dbh, LockHandle => $dbh}; untie %session; # В запись в таблице sessions, соответствующей нашему сеансу, добавляем имя пользователя и пароль, введенные выше $pre = $dbh->prepare(" update sessions set login = ?, password = ? where login is null; "); $pre->execute($login, $password); $dbh->disconnect; exit; При желании этот модуль можно сделать CGI-скриптом и организовать доступ к нему через модуль администрирования, подключаемый к нашему приложению, как и все остальные. Ну и раз информация сессий будет необходима нам в каждом модуле, то процедуры работы с ней вынесены в наш модуль My::Insite. Как все это будет работать – смотрите в листингах, приведенных в статье. Взаимодействие с БД Для работы с базой данных будем использовать Perl-модуль DBI с драйвером DBD::Pg. Данный модуль и нужный драйвер можно установить как из портов, так и из CPAN. Функции открытия и закрытия соединения вынесены в модуль My::Insite, остальное смотрите в коде конкретных модулей. Модуль обработки информации об абоненте Вот мы и добрались до первого «рабочего» модуля. В его рамках нам нужно решить следующие задачи: вывод на экран списка абонентов, ввод нового абонента, удаление абонента, изменение данных. Код модуля следующий: #!/usr/bin/perl –w #------------------------------------ adsl-users.cgi use My::Insite; $dbh = My::Insite->DBConnect('adsl', 'adsluser', 'password'); $cgi = My::Insite->CGIStart(); $action = $cgi->param('action'); # Пытаемся считать из cookie идентификатор сессии, если безуспешно – отправляем на авторизацию $sessId = $cgi->cookie('sessid'); if(!$sessId) { &toLogon; } # Открываем сессию, или на авторизацию в случае ошибки ($sLogin) = $dbh->selectrow_array(' SELECT login FROM sessions WHERE id=?; ', undef, $sessId); if($sLogin) { $session = My::Insite->SessOpen($dbh, $sessId); } else { &toLogon; } # Проверяем, можно ли данному пользователю работать с этим модулем ($allow) = $dbh->selectrow_array(' SELECT allow FROM st_modules WHERE link=?;', undef, 'adsl-users.cgi'); if($allow !~ m($sLogin)) { &toLogon; } print $cgi->header; # Разбираем возможные действия if ($action eq '' ) { &showUsers; } elsif($action eq 'user' ) { &userForm; } elsif($action eq 'changeuser') { &changeUser; } else { print 'Не могу выполнить: '.$action; } My::Insite->SessClose($session); My::Insite->DBDisconnect($dbh); exit; #------------------------------------- subroutines sub showUsers { # подпрограмма вывода списка абонентов $sth = $dbh->prepare('SELECT uid, name, address, phone FROM users ORDER BY name;'); $sth->execute; print '<TABLE><TR><TD><H3>Абоненты</H3>'; print '<TD align="right"><A href="adsl.cgi">Главная</A>'; print '<TR><TD colspan="2">'; print '<TABLE><TR><TD align="right">'; print '[ <A href="?action=user&type=add"> Добавить нового абонента</A> ]'; print '<TR><TD><TABLE border=1><TR bgcolor=#AAAAFF> <TH>Абонент <TH>Адрес <TH>Телефон <TH>Действие; while(@res = $sth->fetchrow_array) { $oper = ($res[6] eq 'I'?'inlager':'outlager'); print "<TR><TD>$res[1]<TD>$res[2]<TD>$res[3]<TD> [ <A href='?action=user&type=update&uid=$res[0] '>Изменить</A> ] :: [ <A href='?action=user&type=delete&uid=$res[0] '>Удалить</A> ]"; } print '</TABLE><TR><TD align="right">'; print '[ <A href="?action=user&type=add">Добавить нового абонента</A> ]'; print '</TABLE></TABLE>'; return; } sub userForm { # выводит форму для манипуляций с данными $uid = $cgi->param('uid'); $type = $cgi->param('type'); if($type eq 'add') { $submitName = 'Добавить'; } elsif($type eq 'delete') { $submitName = 'Удалить'; } elsif($type eq 'update') { $submitName = 'Изменить'; } else { print 'Ошибка операции: '.$type; exit; } $header = $submitName.' абонента:'; if($type ne 'add') { ($name, $address, $phone) = $dbh->selectrow_array(' SELECT name, address, phone FROM users WHERE uid = ?; ', undef, $uid); } else { $name = $address = $phone = ''; } if($type eq 'delete') { $in1 = "<B>$name</B>"; $in2 = "<B>$address</B>"; $in3 = "<B>$phone</B>"; } else { $in1 = "<INPUT type='text' name='name' value='$name' size='35'>"; $in2 = "<INPUT type='text' name='address' value='$address' size='35'>"; $in3 = "<INPUT type='text' name='phone' value='$phone' size='7'>"; } print <<__HTML__; <CENTER><H3>$header</H3> <FORM method="GET"> <TABLE border="1"><TR><TD><TABLE> <INPUT type="hidden" name="action" value="changeuser"> <INPUT type="hidden" name="type" value="$type"> <INPUT type="hidden" name="uid" value="$uid"> <TR><TD>Абонент: <TD>$in1 <TR><TD>Адрес: <TD>$in2 <TR><TD>Телефон: <TD>$in3 <TR><TD colspan="2"><HR> <TR><TD>[ <A href="adsl-users.cgi?action=">Отмена</A> ] <TD align="right"><INPUT type="submit" value="$submitName"> </TABLE></TABLE></FORM></CENTER> __HTML__ exit; } sub changeUser { # запись изменений в БД $type = $cgi->param('type'); $uid = $cgi->param('uid'); $name = $cgi->param('name'); $address = $cgi->param('address'); $phone = $cgi->param('phone'); if($type eq 'add') { $res = $dbh->do(' INSERT INTO users(name, address, phone) VALUES(?, ?, ?);', undef, $name, $address, $phone); } elsif($type eq 'delete') { $res = $dbh->do('DELETE FROM users WHERE uid=?;', undef, $uid); } elsif($type eq 'update') { $res = $dbh->do(' UPDATE users SET name=?, address=?, phone=? WHERE uid=?; ', undef, $name, $address, $phone, $uid); } else { print 'Ошибка операции: '.$type; } if($res) { print 'Операция выполнена успешно. '}; print '<BR><A href="?action=">Продолжить...</A>'; exit; } sub toLogon { print $cgi->header; print '<META http-equiv="refresh" content="1;url=adsl.cgi?account=logon">'; print 'Ошибка входа. Перенаправление...'; exit; } В данном случае для управления поведением сценария используется еще одна переменная – type. Если action определяет, на какую подпрограмму следует передавать управление, то type содержит информацию о том, что именно следует делать в данной подпрограмме. Сгенерированный приложением список абонентов имеет вид, представленный на рисунке 3. Рисунок 4 демонстрирует форму для изменения данных.
Рисунок 3
Рисунок 4 Прочие модули Поскольку другие модули ничего нового и интересного в себе не содержат, отличаясь от приведенного лишь именами и количеством полей, а также некоторыми интерфейсными особенностями, то и тратить время на их рассмотрение не будем. Добавив соответствующую запись в таблицу st_modules, вы сделаете новый модуль доступным для работы. Что можно изменить? Как известно, нет предела совершенству. Рассмотренный здесь пример был очень сильно урезан и упрощен, чтобы за деталями не потерялась суть и чтобы уложиться в рамки журнальной статьи. Однако, разрабатывая реальное приложение, имеет смысл сделать некоторые улучшения. Например, «шаблонность» нашего приложения оставляет желать лучшего. Каждый добавляемый модуль в принципе имеет очень схожую структуру и функциональность. То есть можно разработать один модуль-шаблон и настраивать его под конкретные таблицы и поля автоматически в процессе обращения к конкретной функции. Можно сделать более гибкой систему разграничения доступа, помимо пользователей введя понятие групп пользователей, а также разграничивая права пользователей в пределах одного модуля (полный доступ, только чтение). Механизм сессий используется очень слабо. Например, его можно использовать для передачи таких параметров как идентификатор пользователя (uid), вместо того чтобы делать это с помощью скрытых полей формы. Не совсем удобной выглядит необходимость в каждом модуле задавать логин и пароль для подключения к БД. Выносить это в модуль My::Insite неправильно (иначе будут сложности с использованием данного модуля в других приложениях для подключения к другим базам), а вот сделать что-то типа конфигурационного файла и брать нужные данные оттуда было бы намного лучше, поскольку в случае смены имени или пароля корректировка потребуется только в одном месте. В существенном улучшении нуждается проверка корректности вводимых данных, контроль ошибок, и т. д. В реальной жизни этим, конечно же, пренебрегать нельзя. И вообще, можно сделать более удобный и красивый дизайн, добавить страничкам «динамизм» с помощью JavaScript (например, всплывающие подсказки, предупреждения и т. п.) и много еще чего хорошего и полезного. Заключение Ну что ж. Надеюсь, полученный результат хотя бы частично соответствует нашим ожиданиям, несмотря на множество недоработок, оставленных «за бортом». Мы получили гибкое, легко модифицируемое приложение, соответствующее большинству наших требований. В будущем его без труда можно расширить, добавив, например, модуль для работы с жалобами абонентов, для сбора статистики по потребленному трафику и оплатам и т. д. Единственное, чего мне в данный момент не хватает, это красивых отчетов, которые не стыдно было бы распечатать, сохранить в файл, отправить по электронной почте. Эта задача тоже решается довольно просто. Но об этом – в следующей статье. |
СЕРГЕЙ СУПРУНОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
