Auth hardening: timing oracle, priority race, bot ownership, rate limiting

[t0kubetsu]

Summary

Fixes #143. Four auth and access-control gaps in the bot API.

Note: This PR touches apis.py which was also changed in PR #154 (payload hardening). Merge PR #154 first and rebase this branch before merging.

Changes

1. Timing oracle on key validation (apis.py)

validate_agent_key returned immediately without running check_password_hash when the key index was not found. Valid key prefixes were enumerable via response timing (scrypt/pbkdf2 is slow, so a found-but-wrong-password key takes measurably longer than an unknown prefix). Added a dummy hash comparison in the NoResultFound path to normalize timing.

2. Thread-safe priority scheduler (apis.py)

_select_weighted_priority read-modify-wrote db.app.config["priority_weighted_round_robin"] without a lock. Under multi-threaded WSGI, concurrent getjob requests could corrupt the fairness counters. Added threading.Lock() wrapping the full function body.

3. Bot ownership before idempotency (apis.py)

The idempotency return (200 for re-submitted completed jobs) fired before the ownership check. Any authenticated bot could probe finished job UIDs and receive 200, harvesting bot_id values from log output. Moved ownership check to fire first — non-owner gets 403.

4. Flask-Limiter wired up (__init__.py)

flask-Limiter was declared in requirements.txt but never instantiated. All bot API endpoints were unrate-limited. Added Limiter initialization with memory:// storage and 500/hour default. Per-endpoint limits for getjob/sndjob require a follow-up (Flask-AppBuilder class-based views need custom integration).

Test plan

• Key with valid 16-char prefix but wrong password — response time should be similar to unknown prefix
• Two concurrent getjob requests — verify priority counters are consistent
• Bot B submits completed job owned by Bot A — verify 403
• Rate limiter active — verify 429 after 500 requests/hour