2010-01-27 25 views
1

Je dois avoir un script Python CGI faire quelques trucs (un peu de vérification de sécurité), puis finit par appeler un script CGI Perl, en passant tout ce qu'il a reçu (par exemple, info POST) sur le script Perl. Pour l'arrière-plan, la raison pour laquelle je fais cela est que j'essaie d'intégrer la recherche Swish avec les archives de liste Mailman.Avoir un CGI Python appeler un CGI Perl, en passant l'information originale (pour limiter la recherche des archives Mailman privées aux utilisateurs connectés)

recherche Swish utilise swish.cgi, un script Perl, mais parce que ce sont des archives de liste privée Je ne peux pas permettre aux gens d'appeler directement swish.cgi comme recommandé sur cette page: http://wpkg.org/Integrating_Mailman_with_a_Swish-e_search_engine#Mailman_configuration

Je crois ce que je Il faut que le fichier cgi-bin de Mailman "private" (écrit en Python) fasse son contrôle de sécurité régulier (qui appelle quelques modules Mailman/python) et appelle ensuite swish.cgi pour faire la recherche (après avoir vérifié que l'utilisateur est sur la liste de diffusion). Essentiellement, je crois que la solution la plus simple consisterait simplement à protéger l'accès au script Perl swish.cgi avec une variante du script standard mailman cgi-bin/private Python.

(J'ai considéré l'idée que les gens pourraient rechercher avec un swish.cgi non protégé, et les gens ne pourraient pas voir les résultats complets parce que ces messages sont déjà protégés par mot de passe par défaut configuration de Mailman ... le problème est que même afficher les extraits de publication Swish dans les résultats de recherche pourrait exposer des informations confidentielles, donc je dois restreindre l'accès même à la recherche elle-même aux abonnés.)

Si quelqu'un a une meilleure idée de la façon de résoudre l'ensemble problème sans faire le Python-CGI-appels-Perl-CGI Je serai heureux de considérer que la "réponse". Sachez que mon but est d'apporter peu (idéalement non) de modifications à l'installation Mailman standard. Copier le script cgi-bin "privé" (dont la source est mailman-2.1.12/Mailman/Cgi/private.py) et apporter des modifications à l'appel de swish.cgi est cool, mais modifier le script cgi-bin privé existant ne serait pas vraiment cool.


Voici ce que je l'ai fait pour tester la réponse (à l'aide os.execv pour remplacer le script python avec le script perl, de sorte que le script perl héritera de l'environnement du script python):

J'ai créé un pythontest script avec:

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

Ensuite, un script perltest avec:

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

Puis j'ai appelé http://myserver.com/cgi-bin/pythontest et j'ai vu que l'impression de l'environnement incluait la variable FOO personnalisée afin que le processus perltest de l'enfant ait hérité avec succès de toutes les variables d'environnement.

+1

Pourquoi ne pas simplement utiliser une interface Python pour Swish? http://pypi.python.org/pypi/Swish-E/0.5 – friedo

+0

C'est une excellente deuxième option. Aller à essayer simplement d'abord appeler swish.cgi parce que cela nécessite moins de codage personnalisé. swish.cgi est livré avec Swish et génère l'interface de recherche (boîte de requête et options). Si j'utilisais l'interface Python vers Swish, je crois que je devrais ré-implémenter tout ça. De plus, si nous améliorons Swish à l'avenir, nous aurons automatiquement des améliorations à swish.cgi. Mais merci - si cela (Python CGI appelle swish.cgi Perl CGI) ne fonctionne pas, c'est un excellent plan de sauvegarde! – Chirael

Répondre

1

Je vais juste dire l'évidence ici parce que je n'ai aucune connaissance détaillée de votre environnement spécifique. Si votre script python est un véritable script CGI et non un script mod_python ou similaire, il s'agit simplement d'un processus standard généré pour gérer la requête unique. Vous pouvez utiliser os.execv pour le remplacer par un autre processus (par ex.le CGI perl) et le nouveau processus héritera de l'environnement du processus en cours, stdin, stdout et stderr. Cela suppose que vous n'avez pas besoin de lire stdin pour vos contrôles de sécurité. Cela peut également dépendre de l'exécution de votre CGI dans un environnement restreint. execv est potentiellement dangereux et pourrait être bloqué dans un tel environnement.

Si vous exécutez depuis un environnement mod_python ou si vous avez besoin de consulter les données publiées (par exemple, stdin), l'approche execv n'est pas disponible. Vous avez deux alternatives principales.

Vous pouvez exécuter le CGI perl directement (par exemple, regardez le module subprocess) en lui donnant un environnement correct et en lui fournissant les données correctes à stdin. Vous pouvez spool les données retournées à partir de son stdout brut (ou cuit si nécessaire) directement sur le serveur Web. Dans le cas contraire, vous pouvez effectuer une requête Web locale pour exécuter le CGI. Cela nécessitera probablement un peu moins de connaissances sur la configuration du serveur, mais un peu plus de travail dans le CGI python pour créer et gérer la requête HTTP.

+0

Non, je crois que les vérifications de sécurité utilisent les données de cookie qui apparaissent dans l'environnement comme HTTP_COOKIE et qui sont donc transmises - donc stdin n'est pas un problème. Votre solution semble fonctionner - Je vais poster un suivi pour fournir plus d'informations au cas où quelqu'un d'autre a une question similaire à l'avenir, alors je vais accepter votre réponse. Merci! :) – Chirael