PayPAL-IPN-request doesn't call the view

56 views
Skip to first unread message

Max_

unread,
Sep 9, 2010, 2:47:16 AM9/9/10
to Django users
Hello,
I created a website, using the IPN-Function.
Everything worked fine at first - the notification view was called and
the signal was sent.
But now (without any changes on the code), the IPN-Request from PayPAL
doesn't call the IPN-view anymore. The Request is logged in the apache
access-log but with an internal server error (500) response.
(216.113.191.33 - - [08/Sep/2010:14:25:43 +0200] "POST /payPalNotify/
HTTP/1.0" 500 25992 "-" "-").
Same problem if I set another view (even an empty view) as notifiy-
url. It works (the request is logged with a HTTP200 response), if I
let PayPAL respond to a php-File. It seems like the wsgi-handler can't
handle the PayPAL-Request. The error.log somtimes logs:
[Wed Sep 08 16:19:20 2010] [error] [client 216.113.191.33] mod_wsgi
(pid=2699): Exception occurred processing WSGI script '/usr/local/
django/binner/apache/django.wsgi'.
[Wed Sep 08 16:19:20 2010] [error] [client 216.113.191.33] IOError:
failed to write data
The website is running on a Ubuntu 10.4LTS-Server/Django 1.2.1/wsgi
Has anyone else experienced this problem? Any Ideas?

WSGI-Handler:
import os
import sys
import django.core.handlers.wsgi

os.environ['DJANGO_SETTINGS_MODULE'] = 'binner.settings'

sys.path.append('/usr/local/django')
sys.path.append('/usr/local/django/binner')
sys.path.append('/usr/local/django/binner/templates')

application = django.core.handlers.wsgi.WSGIHandler()

Preston Holmes

unread,
Sep 9, 2010, 9:19:15 AM9/9/10
to Django users
you don't say whether you've tried just loading the notification view
in your browser (simulate PayPals response)

-P

daq...@gmx.de

unread,
Sep 9, 2010, 10:26:31 AM9/9/10
to django...@googlegroups.com
ok thanks; I should have mentioned that.
the view is called when loaded from a browser.
even with GET or POST method.
But it is obviously that the error occurs in the wsgi handler
This is really strange

-P

--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to
django-users...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.

Bill Freeman

unread,
Sep 10, 2010, 1:01:18 PM9/10/10
to django...@googlegroups.com
When I did this I dummied up a static page on the filesystem
of my desktop with a suitable post (I got the fields to expect
by running the server IPN was pointed at - needs to be a
routeable IP - with pdb and a break point at the start of the
view).

Then when we wen't live, it bombed. I had been checking for
the test mode indicater, and it just wasn't there, rather than
set to false, when not in test mode, and I didn't adequately
guard my code when accessing the parameters. And, of
course, you don't get to see the server error because it's
not you posting to the view.

My advice is to protect everything with try or by using get,
log your progress (we had a logging model, but you can
also append to a file, wrapping everything in a try-finally
that closes the filehandle to be sure things get flushed
out), and when you get something you haven't provided
for, log the contents of request.POST. It will be something
simple, such as there's some field they no longer provide
or don't always provide.

Bill

Brian Neal

unread,
Sep 10, 2010, 8:04:30 PM9/10/10
to Django users
On Sep 10, 12:01 pm, Bill Freeman <ke1g...@gmail.com> wrote:
>
> My advice is to protect everything with try or by using get,
> log your progress (we had a logging model, but you can
> also append to a file, wrapping everything in a try-finally
> that closes the filehandle to be sure things get flushed
> out), and when you get something you haven't provided
> for, log the contents of request.POST.  It will be something
> simple, such as there's some field they no longer provide
> or don't always provide.

I have to echo Bill's advice here. Use the Python logger generously in
your IPN view handling code. Paypal has a habit of subtly changing
their API or their POST parameters periodically. Anyway, unless you
are getting hundreds of IPN's a day, I'd log all kinds of stuff to a
file and study it to see where it is going wrong. Good luck,

BN

daq...@gmx.de

unread,
Sep 11, 2010, 2:28:24 AM9/11/10
to django...@googlegroups.com
Thank you, guys.
I found out what the problem was, now.
It was a stupid error in my middleware, which couldn’t handle
the empty referstring from paypal...
now everything is working fine again

-----Ursprüngliche Nachricht-----
Von: django...@googlegroups.com [mailto:django...@googlegroups.com] Im
Auftrag von Brian Neal
Gesendet: Samstag, 11. September 2010 02:05
An: Django users
Betreff: Re: PayPAL-IPN-request doesn't call the view

BN

--

Reply all
Reply to author
Forward
0 new messages