Masters of CGI.Perl
 Сайт клуба знатоков CGI.Perl 
FAQ · Статьи · Конференция · Ссылки · Скрипты

Часто задаваемые Вопросы.. F.A.Q.

Дайджест от 15.11.2000

Если Вы не нашли ответ на свой вопрос в этом дайджесте, то попробуйте найти его в основной базе:

Ключевые слова

Напоминаем, Вы можете получать FAQ на свой e-mail !!! Достаточно подписаться на нашу почтовую конференцию.
 

  Название : Apache специфика  

  1. Как заставить WWW сервер исполнять CGI-программы?
  2. Hаписание скриптов под mod_perl чем нибудь отличается от написания обычных CGI скриптов?
  3. Что означает ругань "Value of $x will not stay shared at - line 5" и "Constant subroutine XXX redefined ..." при попытке запустить скрипт при помощи mod_perl?
  4. Что такое mod_perl и зачем он нужен?
  5. А как бы мне ограничить доступ к скрипту или директории только для умных и местных (способных взломать веб-сервер или знающих пароль)?
  6. А как бы мне сделать, чтобы вывод моего скрипта обрабатывался SSI?

 

Как заставить WWW сервер исполнять CGI-программы?


Apache для Unix/Win32
Надо поравить конфигурационные файлы (я расчитываю, что у вас default конфиги apache)

Способ 1
srm.conf
Директива ScriptAlias
  ScriptAlias /cgi-bin/ /usr/local/apache/cgi-bin/
и в файле access.conf прописать
  <Directory /usr/local/apache/cgi-bin/>
Options ExecCGI
</directory>
(если приглядется, там нужно только раскоментировать опции)
Это позволит вам помещать программы в каталог /usr/local/apache/cgi-bin/ и они будут видны по URL http://you/cgi-bin/program_name

Способ 2
Добавить в srm.conf директиву
AddHandler cgi-script .cgi
и вы сможете вызывать cgi-программу из любого каталога. Но она должна иметь окончание .cgi и для этого каталога должно быть разрешено исполнение CGI (Options ExecCGI в access.conf, написано выше).
Оба способа можно без проблем использовать совместно.

Автор: Павел Аммосов

Дата добавления: 31.08.2000 Прислать свои комментарии  Наверх 

Hаписание скриптов под mod_perl чем нибудь отличается от написания обычных CGI скриптов?


Вообще говоря, да.
Во-первых, существует куча более других способов писания под 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 pachectl graceful или SIGHUP AKA apachectl restart), но за отработкой этой директивы при наличии сложных модулей замечены проблемы. Если она Off, то придётся положить и поднять (apachectl stop; apachectl start). Существует модуль Apache:StatINC, который следит за изменениями модулей и перегружает их по мере изменения. Hо есть подозрение, что он не надёжнее PerlFresRestart.
    При изменении модулей остерегайтесь эффекта частичного срабатывания - некоторые запросы обрабатываются еще старой версией модуля, а некоторые - уже новой. Это происходит оттого, что модуль грузится отдельно каждым экземпляром Apache, скорее всего, только при первом обращении к использующему его скрипту, а потому часть экземпляров "запомнила" старый, а к остальным попал уже "новый".

Источник: FIDO - RU.CGI.PERL (FAQ created by SLY Golovanov, 2:5020/794.13)

Дата добавления: 30.08.2000 Прислать свои комментарии  Наверх 

Что означает ругань "Value of $x will not stay shared at - line 5" и "Constant subroutine XXX redefined ..." при попытке запустить скрипт при помощи mod_perl?


Это следствие различий между работой честного CGI-скрипта, когда для выполнения скрипта порождается новый процесс, а по завершении скрипта процесс завершается, и работой под управлением Apache::Registry - модуля эмуляции окружения CGI под mod_perl. Скрипт, исполняющийся под Apache::Registry, выполняется как функция в том же процессе, что и сам веб-сервер, и результат его компиляции кэшируется mod_perl'ом до обновления скрипта. Второе сообщение не страшно - оно всего лишь предупреждает, что определённая в скрипте функция была перекомпилирована при повторном выполнении (или при перекомпиляции? не помню) скрипта. А вот первое чревато неприятностями, и означает оно, что определённая в скрипте (теперь - функции где-то внутри Apache::Registry) функция пользуется определённой в нём же лексической (my) переменной, не получая её среди аргументов. Такая функция называется closure (вернее, closure называется такая же, но анонимная функция), и смысл её в том, что значение этой переменной на момент определения функции сохраняется в ней, и в дальнейшем при обращении к ней она будет пользоваться этим сохранённым значением (в нашем случае - тем, которое приняла переменная при первом запросе к данному скрипту в данном экземпляре Апача), а не новым. Лечится это двумя различными способами: если этот скрипт уже более-менее отлажен и используется часто, полезно перенести определения функций из него в отдельный модуль; если же он пока отлаживается, то см. следующий вопрос.

Источник: FIDO - RU.CGI.PERL (FAQ created by SLY Golovanov, 2:5020/794.13)

Дата добавления: 30.08.2000 Прислать свои комментарии  Наверх 

Что такое mod_perl и зачем он нужен?


Hа пальцах - модуль к серверу Apache, который предназначен в первую очередь для ускорения запуска скриптов. Вместо того, чтобы каждый раз при запуске скрипта запускался perl, компилировал скрипт и выполнял его, этот perl все время запущен, и висит в памяти. В памяти же находятся и уже откомпилированные до состояния исполняемого кода скрипты. Кроме этого он позволяет вмешиваться почти во все стадии работы сервера, от конфигурирования до различных стадий обработки запроса; он избавляет от накладных расходов на запуск Perl и компиляцию вашего скрипта при каждом обращении к нему; он позволяет получать от Апача все данные о нём самом и о запросе, которые у того есть.

Источник: FIDO - RU.CGI.PERL (FAQ created by SLY Golovanov, 2:5020/794.13)

Дата добавления: 30.08.2000 Прислать свои комментарии  Наверх 

А как бы мне ограничить доступ к скрипту или директории только для умных и местных (способных взломать веб-сервер или знающих пароль)?


В принципе, возможно множество различных решений. Стандартное делается средствами авторизационного механизма веб-сервера. Читайте документацию 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), работать так с действительно конфиденциальными данными нельзя.

Источник: FIDO - RU.CGI.PERL (FAQ created by SLY Golovanov, 2:5020/794.13)

Дата добавления: 30.08.2000 Прислать свои комментарии  Наверх 

А как бы мне сделать, чтобы вывод моего скрипта обрабатывался SSI?


Честно - никак. Почему - см. документацию на Apache. Однако, раз уж у нас есть Perl, нам, видимо (честно говоря, сам не пробовал), поможет CGI::SSI (если это CGI) или Apache::SSI (если mod_perl).

Дата добавления: 30.08.2000 Прислать свои комментарии  Наверх 

Сайт клуба знатоков CGI.Perl - Masters of CGI.Perl
Designed by MoveR Studio © 2000  - | -  Вопросы? Предложения? пишите