The previous approach using a custom X-Custom header did work for the
client-side, but not for activation and deletion links. Now, you need
to add a `name = foo` option to the general section. `isso.dispatch`
then binds this configuration to /foo and can distinguish all API
calls without a special HTTP header.
Also add an option `direct-reply` to control the number of comments
on a thread without referencing a child (to avoid a simple while loop
that `curl -XPOST ...` the url).
Defaults to 3, that means a /24 (or /48 for IPv6) address can only post
3 direct responses on a thread at all.
Keep Isso modular, not monolithic. Make it easy to integrate a
web interface or add XMPP notifications.
This refactorization includes minor bugfixes and changes:
* CORS middleware did not work properly due to wrong unit tests
* more type checks on JSON input
* new detection for origin and public url, closes#28
* new activation and delete url (no redirect for old urls, but you can
convert the old urls: copy hash after `/activate/` (or delete) and
open `/id/<id of comment>/activate/<hash>`
* move crypto.py to utils/
With this commit, SMTP is no longer automatically configured: add
`notify = smtp` to the `[general]` section to use SMTP.
Markdown conversion is not the reason for 2s per 100 comments response,
the hash function is. When using the email/remote_addr from cache, the
response time is pretty fast.
* when uWSGI is available, use their caching framework
* for multi-threaded environment (the default), use a simple cache
shipped with werkzeug
* naive uWSGI fallback which spawns one thread per request and
one thread per mail notification
* uWSGI backend which utilize queues and spooling to handle
simultanous requests and mail notifications
This also fixes a bug where N concurrent POSTs on a new topic
failed for N-1 requests (db integrity error).
Martin Zimmermann