2 votes

Nate avatar

Erreur HTTP 500 à partir d'une requête POST vers django vai WSGI et apache

Demandé el 17 de Janvier, 2010
Quand la question a-t-elle été
5977 affichage
Nombre de visites la question a
1 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

J'ai une application web Django configurée avec mod_wsgi et apache2 sur ubuntu 9.10.

J'utilise le code suivant pour authentifier un utilisateur via un post HTTP pour une autre partie de mon site. Tout ce que je demande en retour est un HTTP 200.

from django.contrib.auth import authenticate
from django.http import HttpResponse

def post_authentication_api(request):
    if request.method == 'POST':
        print request
        user = authenticate(username=request.POST['user'], password=request.POST['pass'])
        if user is not None:
            if user.is_active:
                print "correct"
                return HttpResponse("correct", mimetype="text/plain")
            else:
                print "disabled"
                return HttpResponse("disabled", mimetype="text/plain", status=401)
        else:
            print "incorrect"
            return HttpResponse("incorrect", mimetype="text/plain", status=401)

Tout cela fonctionne bien lorsque je l'exécute à l'aide de la commande Python manage.py runserver et l'autre application s'authentifie correctement. Cependant, lorsque je le charge dans Apache, j'obtiens une erreur interne 500. En fait, lorsque j'exécute le code Python suivant

import urllib
import urllib2

url = 'http://192.168.0.5/radiobusi/auth/post_authentication_api'
values = {'user' : 'Michael Foord',
          'pass' : 'Northampton',}

data = urllib.urlencode(values)
req = urllib2.Request(url, data)
response = urllib2.urlopen(req)
the_page = response.read()

Je reçois

Traceback (most recent call last):
  File "testURL.py", line 10, in <module>
    response = urllib2.urlopen(req)
  File "/usr/lib/python2.6/urllib2.py", line 124, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.6/urllib2.py", line 395, in open
    response = meth(req, response)
  File "/usr/lib/python2.6/urllib2.py", line 508, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.6/urllib2.py", line 433, in error
    return self._call_chain(*args)
  File "/usr/lib/python2.6/urllib2.py", line 367, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 516, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 500: INTERNAL SERVER ERROR

Voici mon fichier d'hôte virtuel

<VirtualHost *:80>
    #Basic setup
    ServerAdmin munderwo@iinet.net.au
    ServerName 192.168.0.5 
    ServerAlias 192.168.0.5

    <Directory /home/munderwo/public_html/radiobusi.com/RadioBusiSite/mysite/apache/>
        Order deny,allow
        Allow from all
    </Directory>

    Alias /radiobusi/media /home/munderwo/public_html/radiobusi.com/RadioBusiSite/mysite/media

    <Location /media>
      Order allow,deny
      Allow from all
    </Location>

    LogLevel debug
    ErrorLog  /home/munderwo/public_html/radiobusi.com/logs/apache_error.log
    CustomLog /home/munderwo/public_html/radiobusi.com/logs/apache_access.log combined

    WSGIDaemonProcess radiobusi.com user=www-data group=www-data threads=25
    WSGIProcessGroup radiobusi.com

    WSGIScriptAlias /radiobusi /home/munderwo/public_html/radiobusi.com/RadioBusiSite/mysite/apache/RadioBusi.wsgi
</VirtualHost>

et voici mon fichier wsgi

import os
import sys

apache_configuration= os.path.dirname(__file__)
project = os.path.dirname(apache_configuration)
workspace = os.path.dirname(project)
sys.path.append(workspace) 

sys.path.append('/usr/local/lib/python2.6/dist-packages/Django-1.1.1-py2.6.egg/django/')
sys.path.append('/home/munderwo/public_html/radiobusi.com/RadioBusiSite/mysite/')

os.environ['PYTHON_EGG_CACHE'] = '/home/munderwo/public_html/radiobusi.com/egg_cache'
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

J'ai déjà mis toutes les permissions à 777 sur ~/public_html/radiobusi.com/ et mis le loggin à debug sur apache et l'hôte virtuel. Quelqu'un a-t-il une autre idée de ce que cela pourrait être ?

Cheers

Mark.

Mise à jour :

Voici le journal des hôtes virtuels, à la fois le journal des erreurs et le journal des accès.

[Mon Jan 18 19:54:27 2010] [info] mod_wsgi (pid=27874): Attach interpreter ''.
[Mon Jan 18 19:54:27 2010] [info] mod_wsgi (pid=27874): Enable deadlock thread in process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8668): mod_wsgi (pid=27874): Starting 25 threads in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 1 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [info] mod_wsgi (pid=27874): Enable monitor thread in process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8508): mod_wsgi (pid=27874): Deadlock timeout is 300.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8511): mod_wsgi (pid=27874): Inactivity timeout is 0.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 2 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 3 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 4 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 5 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 6 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 7 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 8 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 9 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 10 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 11 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 12 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 13 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 14 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 15 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 16 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 17 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 18 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 19 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 20 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 21 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 22 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 23 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 24 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8674): mod_wsgi (pid=27874): Starting thread 25 in daemon process 'radiobusi.com'.
[Mon Jan 18 19:54:47 2010] [info] mod_wsgi (pid=27874): Create interpreter '192.168.0.5|/radiobusi'.
[Mon Jan 18 19:54:47 2010] [info] [client 192.168.0.5] mod_wsgi (pid=27874, process='radiobusi.com', application='192.168.0.5|/radiobusi'): Loading WSGI script '/home/munderwo/public_html/radiobusi.com/RadioBusiSite/mysite/apache/RadioBusi.wsgi'.
munderwo@bertha:~/public_html/radiobusi.com/logs$ cat apache_access.log 
192.168.0.5 - - [18/Jan/2010:19:54:47 +0800] "POST /radiobusi/auth/post_authentication_api HTTP/1.1" 500 42213 "-" "Icecast 2.3.2"
192.168.0.5 - - [18/Jan/2010:19:55:04 +0800] "POST /radiobusi/auth/post_authentication_api HTTP/1.1" 500 42213 "-" "Icecast 2.3.2"

Pour obtenir ces résultats, j'ai arrêté apache, supprimé les journaux, les ai touchés à nouveau, puis redémarré apache et essayé la requête POST deux fois.

Ceci provient du fichier journal principal d'Apache dans /var/log/apache2/error.log. J'ai inclus le message d'arrêt de l'ordinateur pour pouvoir le suivre dans le temps.

   [Mon Jan 18 19:53:47 2010] [notice] caught SIGTERM, shutting down
    [Mon Jan 18 19:54:27 2010] [notice] mod_python: Creating 8 session mutexes based on 6 max processes and 25 max threads.
    [Mon Jan 18 19:54:27 2010] [notice] mod_python: using mutex_directory /tmp 
    [Mon Jan 18 19:54:27 2010] [warn] mod_wsgi: Compiled for Python/2.6.2.
    [Mon Jan 18 19:54:27 2010] [warn] mod_wsgi: Runtime using Python/2.6.4.
    [Mon Jan 18 19:54:27 2010] [warn] mod_wsgi: Python module path '/usr/lib/python2.6/:/usr/lib/python2.6/plat-linux2:/usr/lib/python2.6/lib-tk:/usr/lib/python2.6/lib-old:/usr/lib/python2.6/lib-dynload'.
    [Mon Jan 18 19:54:27 2010] [debug] mod_wsgi.c(8070): mod_wsgi (pid=27872): Socket for 'radiobusi.com' is '/var/run/apache2/wsgi.27872.0.1.sock'.
    [Mon Jan 18 19:54:27 2010] [info] mod_wsgi (pid=27874): Starting process 'radiobusi.com' with uid=33, gid=33 and threads=25.
    [Mon Jan 18 19:54:27 2010] [notice] Apache/2.2.12 (Ubuntu) DAV/2 SVN/1.6.5 mod_python/3.3.1 Python/2.6.4 mod_wsgi/2.5 configured -- resuming normal operations
    [Mon Jan 18 19:54:27 2010] [info] Server built: Nov 12 2009 22:50:52
    [Mon Jan 18 19:54:27 2010] [debug] worker.c(1740): AcceptMutex: sysvsem (default: sysvsem)
    [Mon Jan 18 19:54:27 2010] [info] mod_wsgi (pid=27877): Attach interpreter ''.
    [Mon Jan 18 19:54:27 2010] [info] mod_wsgi (pid=27878): Attach interpreter ''.

De plus, dans mon testURL.py, je crois que je suis en train d'imprimer la réponse, du moins j'essaie.

response = urllib2.urlopen(req)
the_page = response.read()

Y a-t-il une meilleure façon de procéder ?

Mise à jour : Ajouté urls.py comme demandé dans les commentaires

from django.conf.urls.defaults import *
from django.contrib import admin
from django.contrib.auth import forms

admin.autodiscover()

urlpatterns = patterns('',
    (r'^admin/(.*)', admin.site.root),
    (r'^polls/', include('mysite.polls.urls')),
    (r'auth/post_authentication_api$', 'mysite.users.views.post_authentication_api'),
    (r'^site_media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': '/Users/munderwood/Documents/Aptana Studio Workspace/RadioBusiSite/mysite/media/'}),    
)

et pour autant que je puisse dire, mon apache2.conf n'a pas de configuration ErrorDocument. Il est commenté.

ok J'ai réussi à obtenir une page d'erreur Django. Plutôt bizarre.

Environment:

Request Method: POST
Request URL: http://bertha.homeunix.org:3000/radiobusi/auth/post_authentication_api
Django Version: 1.1.1
Python Version: 2.6.4
Installed Applications:
['django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.admin',
 'django.contrib.flatpages',
 'mysite.polls',
 'mysite.RadioBusi',
 'mysite.Support',
 'mysite.users']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware')

Traceback:
File "/usr/local/lib/python2.6/dist-packages/Django-1.1.1-py2.6.egg/django/core/handlers/base.py" in get_response
  92.                 response = callback(request, *callback_args, **callback_kwargs)

Exception Type: TypeError at /auth/post_authentication_api
Exception Value: post_authentication_api() takes exactly 2 arguments (1 given)

POST
Variable    Value
user    u'e_username'
pass        u'e_password'

Les éléments sous POST sont les variables du poste. J'espère que cela vous aidera. C'est évidemment quelque chose à faire avec mon installation. C'est juste bizarre que lorsque j'exécute le même code dans le serveur de test de Django, il fonctionne, alors que dès que je le place sur le serveur Web d'Apache, il fait ceci ?

Merci encore pour votre aide !

Cheers

Mark

Demandé el 17 de Janvier, 2010 par Nate

Réponse

Trop de publicités?

1voto

Nate avatar
Nate Points 656

Ok, donc une fois de plus nous en arrivons à l'erreur de l'utilisateur. A un moment donné, le problème a changé parce que j'ai modifié une partie du code ci-dessus, de telle sorte que

def post_authentication_api(request):

est devenu

def post_authentication_api(self, request):

cela ne fonctionne pas parce que, comme l'a dit Graham à la liste de diffusion django

"Si vous ... avez un premier argument 'self' pour une fonction qui... qui n'est pas une méthode d'une classe, il est évident que vous allez obtenir :"

Exception Type: TypeError at /auth/post_authentication_api 
  Exception Value: post_authentication_api() takes exactly 2 arguments 
(1 given)

Après avoir corrigé cela, j'ai trouvé la racine du problème (pour autant que je puisse dire) qui était que wsgi bloquait sys.stdout. ce qui me semble juste, et j'avais quelques déclarations d'impression dans mon code et c'est pourquoi il ne fonctionnait pas. Un problème très simple qui, pour une raison quelconque, est devenu très compliqué.

En tout cas, un grand merci à Graham qui m'a aidé la semaine dernière sur ce sujet. Il a été infatigable et très accommodant pour quelqu'un qui est assez embarrassé par le résultat final. Il recevra des votes pour les commentaires et je le remercie également.

Merci encore.

Mark

Répondu el 25 de Janvier, 2010 par Nate (656 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X