$ _SERVER par rapport au paramètre environnement WSGI

Question

Je suis en train de concevoir un site. Il en est à un stade très précoce, et je dois prendre la décision d'utiliser ou non un service SingleSignOn fourni par le serveur. (C'est un site de campus, et de plus en plus de sites utilisent SSO ici, donc c'est généralement une bonne idée). La plateforme cible sera très probablement django via mod_wsgi. Cependant, toute documentation fournie avec ce service comporte du code php. Cette méthode repose fortement sur l'utilisation de variables personnalisées $_SERVER['HTTPsomething']. Malheureusement, en ce moment je n'ai pas accès à cet environnement.

(Comment) puis-je accéder à ces variables personnalisées dans django? Selon la documentation WSGI, la variable environnement doit contenir autant de variables que possible. Puis-je être sûr que je peux y accéder?

Answer 1

Dans Django, les variables d'environnement de serveur sont fournis en tant que membres du dictionnaire de l'attribut META sur l'objet request - donc à votre avis, vous pouvez toujours y accéder via request.META['foo'] où foo est le nom de la variable.

Un moyen facile de voir ce qui est disponible est de créer une vue contenant assert False pour déclencher une erreur. Tant que vous utilisez DEBUG=True, vous verrez une page d'erreur contenant de nombreuses informations sur l'état du serveur, y compris une liste complète de tous les attributs request.

Answer 2

Eh bien, $ _SERVER est PHP. Vous serez probablement capable d'accéder aux mêmes variables via WSGI, mais pour être sûr que vous avez besoin de comprendre exactement comment la SSO fonctionne, vous savez donc ce qui crée ces variables (probablement Apache) et que vous pouvez y accéder.

Ou, vous pouvez vous y accéder et l'essayer. :)

Answer 3

Pour déterminer l'ensemble des variables passées dans l'environnement WSGI brut, avant que Django n'y fasse quoi que ce soit, placez le code suivant dans le fichier de script WSGI à la place de votre contenu Django.

import StringIO 

def application(environ, start_response): 
    headers = [] 
    headers.append(('Content-type', 'text/plain')) 

    start_response('200 OK', headers) 

    input = environ['wsgi.input'] 
    output = StringIO.StringIO() 

    keys = environ.keys() 
    keys.sort() 
    for key in keys: 
     print >> output, '%s: %s' % (key, repr(environ[key])) 
    print >> output 

    length = int(environ.get('CONTENT_LENGTH', '0')) 
    output.write(input.read(length)) 

    return [output.getvalue()] 

Il affichera au navigateur l'ensemble des paires clé/valeur.

Il est important de connaître le fonctionnement du mécanisme SSO. Si c'est le cas, vous trouverez peut-être qu'il définit les variables REMOTE_USER et éventuellement AUTH_TYPE. Si REMOTE_USER est défini, il indique que l'utilisateur nommé dans la variable a été authentifié par un mécanisme d'authentification de niveau supérieur dans Apache. Ces variables sont normalement définies pour l'authentification HTTP Basic et Digest, mais pour utiliser autant de systèmes que possible, un mécanisme SSO doit également les utiliser.

S'ils sont, alors il y a une fonction Django, décrit à:

http://docs.djangoproject.com/en/dev/howto/auth-remote-user/

qui peut ensuite être utilisé pour avoir Django accepter l'authentification fait à un niveau supérieur. Même si le mécanisme SSO n'utilise pas REMOTE_USER mais utilise des en-têtes personnalisés, vous pouvez utiliser un wrapper WSGI personnalisé autour de toute l'application Django pour traduire les en-têtes personnalisés en une valeur REMOTE_USER appropriée, que Django peut ensuite utiliser .