Пусть Python CGI вызывает Perl CGI, передавая оригинальную информацию (чтобы ограничить поиск в частных архивах Mailman зарегистрированными пользователями)

Question

Мне нужно, чтобы скрипт Python CGI делал некоторые вещи (небольшая проверка безопасности), а затем заканчивал тем, что вызывал скрипт Perl CGI, передавая все, что он получил (например, информацию POST), в скрипт Perl.

Для справки, моя причина в том, что я пытаюсь интегрировать поиск Swish с архивами списков Mailman.

Для поиска в Swish используется swish.cgi, Perl-скрипт, но поскольку это частные архивы списков, я не могу просто позволить людям вызывать swish.cgi напрямую, как рекомендуется на этой странице: http://wpkg.org/Integrating_Mailman_with_a_Swish-e_search_engine#Mailman_configuration

Я считаю, что мне нужно сделать, чтобы "приватный" файл cgi-bin Mailman (написанный на Python) выполнял свою обычную проверку безопасности (которая вызывает несколько модулей Mailman / python) и затем вызывал swish.cgi поиск (после проверки того, что пользователь находится в списке рассылки).

По сути, я считаю, что самым простым решением было бы просто защитить доступ к Perl-скрипту swish.cgi с помощью варианта стандартного сценария Python mailman cgi-bin / private.

(Я подумал, что люди могут искать с незащищенным swish.cgi, и люди не смогут просматривать полные результаты, потому что эти сообщения уже защищены паролем по умолчанию при установке Mailman ... но проблема в том, что даже показ выдержек из сообщения на языке Swish в результатах поиска может раскрыть конфиденциальную информацию, поэтому я должен ограничить доступ даже для самого поиска только подписчиками.)

Если у кого-то есть лучшее представление о том, как решить общую проблему, не используя Python-CGI-Call-Perl-CGI, я буду рад считать, что это «ответ».

Просто знайте, что моя цель - внести небольшие (в идеале нет) изменения в стандартную установку Mailman. Скопировать «приватный» скрипт cgi-bin (источник которого mailman-2.1.12 / Mailman / Cgi / private.py) и внести изменения в call swish.cgi - это круто, но модифицировать существующий приватный скрипт cgi-bin не удастся действительно будь крут.

---

Вот что я сделал, чтобы проверить ответ (используя os.execv для замены скрипта python на скрипт perl, чтобы скрипт perl унаследовал среду скрипта python):

Я создал pythontest скрипт с:

import os
os.environ['FOO'] = 'BAR'
mydir = os.path.dirname(os.environ.get('SCRIPT_FILENAME'))
childprog = mydir + '/perltest'
childargs = []
os.execv(childprog, childargs)

Затем скрипт perltest с:

print "Content-type: text/html\n\n";
while (($key,$value) = each %ENV) {
  print "<p>$key=$value</p>\n";
}

Затем я позвонил http://myserver.com/cgi-bin/pythontest и увидел, что в распечатку среды включена пользовательская переменная FOO, поэтому дочерний процесс perltest успешно унаследовал все переменные среды.

Answer 1

Я просто собираюсь изложить очевидное здесь, потому что у меня нет подробных знаний о вашей конкретной среде.

Если ваш скрипт на python является подлинным CGI, а не скриптом mod_python или чем-то подобным, то это просто обычный процесс, созданный для обработки одного запроса. Вы можете использовать os.execv для его замены другим процессом (например, CGI perl), и новый процесс унаследует среду текущего процесса, stdin, stdout и stderr. Это предполагает, что вам не нужно читать stdin для проверки безопасности. Это также может зависеть от того, работает ли ваш CGI в ограниченной среде. execv потенциально опасен и может быть заблокирован в такой среде.

Если вы работаете в среде mod_python или вам нужно посмотреть опубликованные данные (т.е. stdin), то подход execv вам недоступен. У вас есть две основные альтернативы.

Вы можете запустить Perl CGI напрямую (например, посмотреть на модуль subprocess), передать ему правильную среду и передать правильные данные в stdin. Вы можете буферизовать возвращенные данные из их stdout необработанных (или приготовленных при необходимости) непосредственно обратно на веб-сервер.

В противном случае вы могли бы сделать локальный веб-запрос для запуска CGI. Это, вероятно, потребует немного меньше знаний о настройке сервера, но немного больше работы в Python CGI для создания и обработки HTTP-запроса.