ru.perl

 
 - RU.PERL ----------------------------------------------------------------------
 From : Sly Golovanov                        2:5020/794.13  10 Jul 2000  05:00:01
 To : All
 Subject : FAQ 2/3
 -------------------------------------------------------------------------------- 
 

 
 >  Apache-специфика
 
 ------------------------------------------------------------------------------
 Q: А как бы мне сделать, чтобы вывод моего скрипта обрабатывался SSI?
 A: Честно -  никак. Почему - см.  документацию на Apache. Однако, раз уж у нас
 есть  Perl, нам,  видимо (честно  говоря, сам  не пробовал),  поможет CGI::SSI
 (если это CGI) или Apache::SSI (если mod_perl).
 
 Q: А как бы мне ограничить доступ к скрипту или директории только для умных и
 местных (способных взломать веб-сервер или знающих пароль)?
 A:  В  принципе, возможно множество  различных  решений. Стандартное  делается
 средствами авторизационного механизма веб-сервера. Читайте документацию Apache
 на предмет директив  Auth* и require, а также на  предмет параметра AuthConfig
 директивы  AllowOverride,  а то  будете  потом  удивляться, почему  совершенно
 правильный  .htaccess  не  работает.  mod_perl  позволяет  вклиниться  в  фазы
 контроля доступа,  аутентификации и авторизации, и  написать свои обработчики.
 Для  аутентификации  и  авторизации  по базам  данных  существуют  модули  для
 mod_perl   AuthenDBI   и   AuthzDBI  (в свежих версиях они объединились в один
 модуль, Apache::AuthDBI),  а простейший  пример  файловой  авторизации:
 
 <Files "myscipt.cgi">
 AuthType Basic
 AuthName My.Script.Very.Secure
 AuthFile /home/vasia/.htpasswd
 require valid-user
 </Files>
 
 Файл  /home/vasia/.htpasswd  может  лежать  (и  это  рекомендуется)  в  месте,
 недоступном для укачивания.  Если положить его в такое  место невозможно, надо
 защитить его от укачивания посредством
 
 <Files ".htpasswd">
 deny from all
 </Files>
 
 или как минимум всё  тем же паролем, только уже с require  vasia. Его формат -
 имя:пароль, пароль зашифрован стандартным юниксовым  crypt(), так что если нет
 доступа к команде  htpasswd (например, нет шелла), то  можно сгенерировать его
 перловым скриптом. Я, собственно, поначалу так и делал, пока не сообразил, что
 должна быть специальная программа...
 
 Ко всему этому рекомендуется помнить,  что пароли Basic авторизации передаются
 по сети в  незащищённом виде (base64-кодирование строки  "имя:пароль"), а поля
 форм <input type=password> показываются звёздочками только в браузере, по сети
 же передаются  как есть (вернее,  опять же  закодированными, но уже  как URL).
 Поэтому,  если вы  не пользуетесь  защищённым  каналом (SSL),  работать так  с
 действительно конфиденциальными данными нельзя.
 ------------------------------------------------------------------------------
   mod_perl
 ------------------------------------------------------------------------------
 Q: Что такое mod+perl и зачем он нужен?
 
 >A: Hа пальцах - модуль к серверу Apache, который предназначен в первую очередь
 
 для  ускорения  запуска  скриптов.  Вместо  того, чтобы каждый раз при запуске
 скрипта  запускался  perl,  компилировал  скрипт и выполнял его, этот perl все
 время запущен, и висит в памяти. В памяти же находятся и уже откомпилированные
 до  состояния  исполняемого кода скрипты. Кроме этого он позволяет вмешиваться
 почти   во   все   стадии работы  сервера,  от  конфигурирования  до различных
 стадий  обработки   запроса;  он   избавляет от  накладных расходов  на запуск
 Perl  и   компиляцию   вашего  скрипта   при  каждом   обращении   к нему;  он
 позволяет получать от Апача все данные о нём самом и о запросе, которые у того
 есть.
 
 Q: Что означает ругань "Value of $x will not stay shared at - line 5" и
 "Constant subroutine XXX redefined ..." при попытке запустить скрипт при
 помощи mod_perl? 
 A:  Это  следствие различий  между  работой  честного CGI-скрипта,  когда  для
 выполнения скрипта порождается новый процесс,  а по завершении скрипта процесс
 завершается,  и работой  под  управлением Apache::Registry  - модуля  эмуляции
 окружения  CGI  под  mod_perl.  Скрипт,  исполняющийся  под  Apache::Registry,
 выполняется как функция  в том же процессе, что и  сам веб-сервер, и результат
 его компиляции кэшируется mod_perl'ом  до обновления скрипта. Второе сообщение
 не страшно - оно всего лишь  предупреждает, что определённая в скрипте функция
 была перекомпилирована  при повторном  выполнении (или при  перекомпиляции? не
 помню)  скрипта. А  вот первое  чревато  неприятностями, и  означает оно,  что
 определённая  в  скрипте (теперь  -  функции  где-то внутри  Apache::Registry)
 функция  пользуется определённой  в  нём же  лексической  (my) переменной,  не
 получая её среди аргументов. Такая функция называется closure (вернее, closure
 называется такая  же, но анонимная  функция), и смысл  её в том,  что значение
 этой  переменной  на  момент  определения  функции  сохраняется  в  ней,  и  в
 дальнейшем  при  обращении  к  ней она  будет  пользоваться  этим  сохранённым
 значением (в нашем случае - тем, которое приняла переменная при первом запросе
 к данному  скрипту в данном экземпляре  Апача), а не новым.  Лечится это двумя
 различными способами: если этот скрипт  уже более-менее отлажен и используется
 часто, полезно перенести определения функций  из него в отдельный модуль; если
 же он пока отлаживается, то см. следующий вопрос.
 
 Q: Hаписание скриптов под mod_perl чем нибудь отличается от написания
 обычных CGI скриптов?
 
 >A: Вообще говоря, да. 
 
 Во-первых, существует куча более других способов писания под mod_perl -
 Perl-SSI, Perl*Handlers, логика работы которых сильно отличается от CGI.
 Если же мы говорим о тех скриптах, которые выполняются через
 Apache::Registry, то есть следующие различия:
 
 1. Hельзя использовать my-переменные уровня файла. То есть использовать
 можно,  но результат будет ну очень странный. Дело в том, что с точки
 зрения перла, mod_perl-овый скрипт это не файл, а тело процедуры.
 Поэтому использование в нем my переменных, которые потом пользуются из
 вложенных процедур, приводит к возникновению closure и всему, что из
 этого следует.
 
 Я лично исполюзую следующую технику:
 
 use CGI;
 use DBI;
 use strict;
 use что-там-еще-надо
 
 &main;
 
 sub main {
    my $cgi=new CGI;
 
    ....
 
 }
 
 sub some_more_sub {
   ...
 }
 
 При таким образом написанном скрипте я уверен что lexical scoring будет
 вести себя одинаково и в CGI и в mod_perl.
 
 2. Скрипты живут долго. Поэтому мусор за собой надо чистить аккуратно.
 
 3. Тебе доступен объект Apache::Request, который содержит уйму интересной
 информации; в частности, из него можно вытащить пароль при basic
 authentication.
 
 4. Теоретически, у тебя есть куда больше способов повлиять на поведение
 Apache в процессе обработки твоего запроса, чем из CGI.
 
 5.  Если  ты  используешь самописные модули, то при их редактировании придется
 апач   перестартовывать   (apachectl  graceful)  - поскольку   крайне   сложно
 (и  долго)     проверять     все     зависимости,  Apache::Registry  проверяет
 только  момент    изменения   самого  исполняемого   им  скрипта,   а  модули,
 используемые  в   качестве    Perl*Handler,   не  проверяются вообще. Если   в
 конфигурации   Апача    сказано   PerlFreshRestart  On,  то достаточно его  об
 этом  попросить  вежливо  (SIGUSR1  AKA  apachectl  graceful   или SIGHUP  AKA
 apachectl  restart),  но  за   отработкой  этой директивы  при наличии сложных
 модулей    замечены  проблемы.  Если она  Off, то придётся  положить и поднять
 (apachectl       stop;        apachectl     start).      Существует     модуль
 Apache:StatINC,  который  следит  за   изменениями модулей и перегружает их по
 мере   изменения.  Hо   есть подозрение, что  он не  надёжнее PerlFresRestart.
 
 При   изменении   модулей  остерегайтесь  эффекта  частичного  срабатывания  -
 некоторые  запросы обрабатываются еще старой версией модуля, а некоторые - уже
 новой. Это происходит оттого, что модуль грузится  отдельно каждым экземпляром
 Apache,  скорее  всего,  только   при  первом  обращении  к  использующему его
 скрипту,  а   потому  часть   экземпляров  "запомнила"  старый, а  к остальным
 попал уже "новый".
 
 ---
  * Origin:  (2:5020/794.13)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор