- The following logging namespaces are now used, to make it easier to
filter only log lines related to the logged application message:
- `platypush:events`
- `platypush:requests`
- `platypush:responses`
- Those messages are always logged as JSON, with no prefixes nor
suffixes.
- Requests are always logged when executed - no more delegation to the
upstream backend.
- Responses are always logged when fully populated (including `id`,
`origin`, `target` etc.), instead of being logged when still partially
populated. This makes it particularly easy to link request/response
IDs directly from the logs.
Optional top-level imports in Tornado route declarations will trigger
`ImportError`. While this will just mean that those routes will be
skipped, it will also generate a lot of noise on the logs.
It was just too painful to find a combination of versions of gunicorn,
gevent, eventlet, pyuwsgi etc. that could work on all of my systems.
On the other hand, Tornado works out of the box with no headaches.
Also in this commit:
- Updated a bunch of outdated/required integration dependencies.
- Black'd and LINTed a couple of old plugins.
The websocket service is no longer provided by a different service,
controlled by a different thread running on another port.
Instead, it's now exposed directly over Flask routes, using
WSGI+eventlet+simple_websocket.
Also, the SSL context options have been removed from `backend.http`, for
sake of simplicity. If you want to enable SSL, you can serve Platypush
through a reverse proxy like nginx.
- Don't return a redirect to the login page if an authentication failed
over a JSON endpoint - instead, return a JSON payload with the error.
- Added support for additional fonts.
- Re-designed the login/registration page.
- Updated caniuse database.
A `WebhookEvent` hook can now return a tuple in the format `(data,
http_code, headers)` in order to customize the HTTP status code and the
headers of a response.
When a client triggers a `WebhookEvent` by calling a configured webhook
over `/hook/<hook_name>`, the server will now wait for the configured
`@hook` function to complete and it will return the returned response
back to the client.
This makes webhooks much more powerful, as they can be used to proxy
HTTP calls or other services, and in general return something to the
client instead of just executing actions.