```
$ cargo test
<--- snip --->
thread panicked while panicking. aborting.
Running unittests (target/debug/deps/tests_migrate-7d90f83f506b1b25)
```
gdb revealed that demo::demo_account_works receives a SIGKILL due to a
failed test. No idea why it didn't fail the usual way. The part where
the test fails hits an endpoint with the wrong datatype payload, it
should have failed with a 404 when the status was asserted but it
didn't. Fixing that fixed#8.
Additionally, all demo user functionality was restructured to include an
abort functionality, which can be used to kill the loop that deletes and
creates demo user throughout the runtime of the app.
broke_my_site_traffic
The above metrics are sourced from the user and are stored in the
database to reuse at a later point in time when the mCaptcha instance's
admin changes suggested configuration.
I'm not sure if I want to recompute configuration every time the admin
updates suggested configurations or give the user an option to recompute
based on latest trends. If we recompute on every update, then should the
admin choose very high difficulty_factors then it would hold back the
user's visitors, which is not nice. But there should also be an option
to rerun estimates when older configuration no longer works properly.
suggested difficulty factors for use in CAPTCHA configurations
estimates
The current CAPTCHA configuration panel requires the user to provide
difficulty factor <--> visitor threshold mapping, which can be tedious
if the user isn't familiar with those parameters. Also, it could lead to
ineffective limiting from mCaptcha's side, should it be configured
improperly.
So an estimate computed from well known statistics like peak, avg and
broke-my-site traffic could go a long way.
release:
Routes 404'd when scope contained trailing slash like so:
let scope = "/api/v1/pow/";
web::scope(scope)//
So had to rm trailing slash in scope
