I'm using django-paypal as a payment solution inside my django application. I'm trying to implement a IPN handler.
What happens when I receive an IPN message at my IPN-handling URL the django server crashes:
Traceback (most recent call last):
File "/usr/local/lib/python2.6/dist-packages/django/core/servers/basehttp.py", line 281, in run
self.finish_response()
File "/usr/local/lib/python2.6/dist-packages/django/core/servers/basehttp.py", line 321, in finish_response
self.write(data)
File "/usr/local/lib/python2.6/dist-packages/django/core/servers/basehttp.py", line 417, in write
self._write(data)
File "/usr/lib/python2.6/socket.py", line 300, in write
self.flush()
File "/usr/lib/python2.6/socket.py", line 286, in flush
self._sock.sendall(buffer)
error: [Errno 104] Connection reset by peer
My payments applications urls.py looks like this:
urlpatterns = patterns('mysite.payment.views',
(r'^thank_you/', 'thank_you'),
(r'^canceled/', 'canceled'),
(r'^paypal-ipn/', include('paypal.standard.ipn.urls'))
)
To me the error message is pretty useless. Would be great if someone could help me.
I admit I'm an idiot :)
You don't need ssl for this. But what you need is to do a syncdb before you are able to use it,...
God sometimes it is so easy that you just don't see it.
Can you monitor precisely the packet that paypal is sending your server using tcpdump or wireshark? It looks like they may be terminating the connection early, but it's hard to tell much without a longer traceback and/or a packet dump.
Edit:
I had forgotten about the https messages. Paypal probably requires HTTPS for those callbacks. The dev server won't support that, so unfortunately you will probably need to flesh out your server configuration before you can test that functionality.
Related
Good day,
I've an app that is uses Cherrypy to server a simple website. From time to time I get DECRYPTION_FAILED_OR_BAD_RECORD_MAC error. I've never seen an issue my self while testing, this only obvious in logs.
[26/Nov/2021:02:50:39] ENGINE Error in HTTPServer.serve
Traceback (most recent call last):
File "/home/user/app/venv/lib/python3.8/site-packages/cheroot/server.py", line 1810, in serve
self._connections.run(self.expiration_interval)
File "/home/user/app/venv/lib/python3.8/site-packages/cheroot/connections.py", line 201, in run
self._run(expiration_interval)
File "/home/user/app/venv/lib/python3.8/site-packages/cheroot/connections.py", line 218, in _run
new_conn = self._from_server_socket(self.server.socket)
File "/home/user/app/venv/lib/python3.8/site-packages/cheroot/connections.py", line 272, in _from_server_socket
s, ssl_env = self.server.ssl_adapter.wrap(s)
File "/home/user/app/venv/lib/python3.8/site-packages/cheroot/ssl/builtin.py", line 277, in wrap
s = self.context.wrap_socket(
File "/usr/lib/python3.8/ssl.py", line 500, in wrap_socket
return self.sslsocket_class._create(
File "/usr/lib/python3.8/ssl.py", line 1040, in _create
self.do_handshake()
File "/usr/lib/python3.8/ssl.py", line 1309, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1131)
Is there a simple way for Cherrypy to log this as one line error in logs or is there a way to fix it?
I encountered the same (and also SSLV3_ALERT_BAD_CERTIFICATE). My setup: CherryPy 18.5.0; Python 3.7
I use Self-signed certificate (I think this is the key info for the issue)
Due to the not trusted certificate, browsers indicate that it is not a properly secured connection. Users need to click confirm that they still want to browse the pages.
Access attempts from Edge or Chrome do not trigger this CherryPy error. Firefox seems to send something to the server even before it made sure that the request is to go ahead (i.e. even before confirm).
IMHO, CherryPy should handle the SSL errors (catch the exceptions) and let the users handle them.
Since I cannot control users' browser selection, nor can I catch the SSL exception, my "solution" was to get the users install the self-signed certificate. From that point on, they can browse the pages without warning and no such CherryPy error pops up in the logs anymore.
I know this is a pretty weak solution, but nobody answered, so I thought I'd share this, as it might help someone.
I know just enough devops to be dangerous. I've successfully deployed a VERY simple python flask app to App Engine that basically publishes received post data as a message to PubSub. It is almost identical to Google's sample code to do so. Only difference is it uses a service account I push with the app repository to access PubSub to circumvent this issue.
Works very well so far, but I've started seeing a very small number of errors around starting a new thread in threading.py:
1)
Traceback (most recent call last):
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 33, in grpc._cython.cygrpc._spawn_callback_async
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 24, in grpc._cython.cygrpc._spawn_callback_in_thread
File "/usr/lib/python2.7/threading.py", line 736, in start
_start_new_thread(self.__bootstrap, ())
thread.error: can't start new thread
2)
Traceback (most recent call last):
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 33, in grpc._cython.cygrpc._spawn_callback_async
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 24, in grpc._cython.cygrpc._spawn_callback_in_thread
3)
Traceback (most recent call last):
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 33, in grpc._cython.cygrpc._spawn_callback_async
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 33, in grpc._cython.cygrpc._spawn_callback_async
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 24, in grpc._cython.cygrpc._spawn_callback_in_thread
File "src/python/grpcio/grpc/_cython/_cygrpc/credentials.pyx.pxi", line 24, in grpc._cython.cygrpc._spawn_callback_in_thread
File "/usr/lib/python2.7/threading.py", line 736, in start
File "/usr/lib/python2.7/threading.py", line 736, in start
I have 2 questions, in order of importance:
This is an app that basically needs 100% uptime in order to not lose data (not confident the clients attempt retries if there is an error on my server side). Are these errors internal to how App Engine is managing my app's resources, and not resulting in errors handling actual requests? How can I determine if I ever responded with an HTTP error/didn't successfully handle a request? I don't see any errors in my nginx logs...is that the place I need to look to see if anything failed?
Is there a way I can fix this error?
https://github.com/GoogleCloudPlatform/google-cloud-python/blob/master/pubsub/google/cloud/pubsub_v1/publisher/client.py#L143
it looks like publisher.publish(topic_path, data=data) is an async operation, returning a concurrent.futures.Future object
Have you trying calling the Future's result()? https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Future.result
This will block until the future object is successful, fails, or timesout.
You could then forward that result as your HTTP response.
Hopefully, the result object will give you more information about the error.
Ended up changing the methodology a bit. Instead of posting a pubsub message then having dataflow ingest through GCS to BigQuery I decided to stream directly into BQ using the BigQuery python client. Updated dependencies for the python flask app to:
Flask==1.0.2
google-cloud-pubsub==0.39.1
gunicorn==19.9.0
google-cloud-bigquery==1.11.2
and I am no longer seeing any of those exceptions. It's worth noting that I'm still using a service account .json credentials file in the same directory as the app source, and I'm creating the BigQuery client with
bq_client = bigquery.Client.from_service_account_json(BQ_SVC_ACCT_FILE).
For anyone else with similar issues I'd recommend updating your dependencies (esp any Google Cloud client libraries) and create the Client you need from a local service account credentials file. I attempted to use the inherited Compute engine environment credentials (basically the default project compute engine service account) but that was less stable than pushing up an actual credential file and using that locally. However...assess your own security needs before doing the same.
I have a webservice running in python 2.7.10 / Tornado that uses SSL. This service throws an error when a non-SSL call comes through (http://...).
I don't want my service to be accessible when SSL is not used, but I'd like to handle it in a cleaner fashion.
Here is my main code that works great over SSL:
if __name__ == "__main__":
tornado.options.parse_command_line()
#does not work on 2.7.6
ssl_ctx = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
ssl_ctx.load_cert_chain("...crt.pem","...key.pem")
ssl_ctx.load_verify_locations("...CA.crt.pem")
http_server = tornado.httpserver.HTTPServer(application, ssl_options=ssl_ctx, decompress_request=True)
http_server.listen(options.port)
mainloop = tornado.ioloop.IOLoop.instance()
print("Main Server started on port XXXX")
mainloop.start()
and here is the error when I hit that server with http://... instead of https://...:
[E 151027 20:45:57 http1connection:700] Uncaught exception
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/tornado/http1connection.py", line 691, in _server_request_loop
ret = yield conn.read_response(request_delegate)
File "/usr/local/lib/python2.7/dist-packages/tornado/gen.py", line 807, in run
value = future.result()
File "/usr/local/lib/python2.7/dist-packages/tornado/concurrent.py", line 209, in result
raise_exc_info(self._exc_info)
File "/usr/local/lib/python2.7/dist-packages/tornado/gen.py", line 810, in run
yielded = self.gen.throw(*sys.exc_info())
File "/usr/local/lib/python2.7/dist-packages/tornado/http1connection.py", line 166, in _read_message
quiet_exceptions=iostream.StreamClosedError)
File "/usr/local/lib/python2.7/dist-packages/tornado/gen.py", line 807, in run
value = future.result()
File "/usr/local/lib/python2.7/dist-packages/tornado/concurrent.py", line 209, in result
raise_exc_info(self._exc_info)
File "<string>", line 3, in raise_exc_info
SSLError: [SSL: HTTP_REQUEST] http request (_ssl.c:590)
Any ideas how I should handle that exception?
And what the standard-conform return value would be when I catch a non-SSL call to an SSL-only API?
UPDATE
This API runs on a specific port e.g. https://example.com:1234/. I want to inform a user who is trying to connect without SSL, e.g. http://example.com:1234/ that what they are doing is incorrect by returning an error message or status code. As it is the uncaught exception returns a 500, which they could interpret as a programming error on my part. Any ideas?
There's an excelent discussion in this Tornado issue about that, where Tornado maintainer says:
If you have both HTTP and HTTPS in the same tornado process, you must be running two separate HTTPServers (of course such a feature should not be tied to whether SSL is handled at the tornado level, since you could be terminating SSL in a proxy, but since your question stipulated that SSL was enabled in tornado let's focus on this case first). You could simply give the HTTP server a different Application, one that just does this redirect.
So, the best solution it's to HTTPServer that listens on port 80 and doesn't has the ssl_options parameter setted.
UPDATE
A request to https://example.com/some/path will go to port 443, where you must have an HTTPServer configured to handle https traffic; while a request to http://example.com/some/path will go to port 80, where you must have another instance of HTTPServer without ssl options, and this is where you must return the custom response code you want. That shouldn't raise any error.
I've been using Django 1.3 with Python 2.6 on Ubuntu 10.10. I have 3 questions.
I recall having this problem on Windows 7 when I used Django a while ago. However, I also remember that when I first used Django this problem didn't occur.
When I access Django via 127.0.0.1:8000, after starting a brand new project, I can reach the site, but sometimes it takes a good 10-20 secs and sometimes more to reach it. Also, on a project I've barely worked on, I have the same problems and also get errors like:
Exception happened during processing of request from ('127.0.0.1', 47758)
Traceback (most recent call last):
File "/usr/lib/python2.6/SocketServer.py", line 283, in _handle_request_noblock
self.process_request(request, client_address)
File "/usr/lib/python2.6/SocketServer.py", line 309, in process_request
self.finish_request(request, client_address)
File "/usr/lib/python2.6/SocketServer.py", line 322, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/local/lib/python2.6/dist-packages/Django-1.3-py2.6.egg/django/core/servers/basehttp.py", line 570, in __init__
BaseHTTPRequestHandler.__init__(self, *args, **kwargs)
File "/usr/lib/python2.6/SocketServer.py", line 618, in __init__
self.finish()
File "/usr/lib/python2.6/SocketServer.py", line 661, in finish
self.wfile.flush()
File "/usr/lib/python2.6/socket.py", line 297, in flush
self._sock.sendall(buffer(data, write_offset, buffer_size))
error: [Errno 32] Broken pipe
Also, whenever I get an error I expect dcramer's django-sentry to log the error in the database, but when I go into MySQL and check the tables, there is nothing there. I followed the instructions on the site to install the app.
I placed this in my urls.py file:
url(r'^static/(?P<path>.*)$', 'django.views.static.serve', {'document_root': '/home/user/apache2/www/django/ecomstore/static',})
However, when I go to 127.0.0.1:8000/static/css.css I can't find the file I placed in the folder. What did I do wrong?
Thanks for all the help!
this issue is also discussed here Django + WebKit = Broken pipe
These errors are the client closing the connection before it has a chance to fully send all data (I believe).
There are certain areas of the stack, this being one of them, that Sentry currently can't log exceptions from. We're hoping to improve this in Sentry 2.0.
/Have you set STATIC_URL = '/static/' in your settings
I am running django 1.1.1 on python2.6.1, and did start the django web server like this
manage.py runserver 192.0.0.1:8000
then tried to connect to the django dev web server on http://192.0.0.1:8000/
keep getting this message on the remote computer
Traceback (most recent call last):
File "C:\Python26\Lib\site-packages\django\core\servers\basehttp.py", line 279, in run
self.result = application(self.environ, self.start_response)
File "C:\Python26\Lib\site-packages\django\core\servers\basehttp.py", line 651, in __call__
return self.application(environ, start_response)
File "C:\Python26\lib\site-packages\django\core\handlers\wsgi.py", line 241, in __call__
response = self.get_response(request)
File "C:\Python26\lib\site-packages\django\core\handlers\base.py", line 115, in get_response
return debug.technical_404_response(request, e)
File "C:\Python26\Lib\site-packages\django\views\debug.py", line 247, in technical_404_response
tried = exception.args[0]['tried']
KeyError: 'tried'
what i am doing wrong ?
it seen to work ok if i run http://192.0.0.1:8000/ on the computer that runs the Django web server and have that ip 192.0.0.1:8000
If you look at the revision logs of that file you'll see that django has recently started catching the KeyError that is raised in that try block.
The log message reads "Ensured generating debug 404 page won't raise a key error. Thanks pigletto."
See the ticket http://code.djangoproject.com/ticket/12083 and the changeset http://code.djangoproject.com/changeset/12679
So, I would check if you're raising a debug 404 page, or if any of the other comments in the ticket jump out of you.
Hope that helps!
Update: After looking at the code a little bit closer, I'd take a good look at your urls.py file for any mistakes in the url resolving regex. Are you doing url('') instead of ('^$') for the root/homepage?