SUMMARY
The test suite messy and inefficient in every imaginable way. It
creates a DB connection pool for every unit test and Postgres failed
with the following error:
code: "53300", message: "sorry, too many clients already
This hotfix runs tests via scripts/tests.sh, which executes one test
at a time.
Ideally, the connection pool must be shared across the whole test
suite but this requires a major refactor of the test suite and even
the app code. A refactor towards this is in progress in the
`db-abstract` branch, which I hope to complete within this week.
fixes#22
When user tries to visit this view without an easy configuration
available, i.e, user had created the CAPTCHA using advance view and no
TrafficPattern is available in database, the user will be automatically
redirected to the advance edit page.
But the default edit link everywhere is to the easy edit view.
```
$ 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.
