Login rejects every correct password (total auth outage)

Nobody can log in. Every owner, with every correct password, gets a 401 invalid_credentials. This is a total outage of the only authenticated role this service has -- no owner can create forms, view submissions, download attachments, export CSVs, or view analytics. The public submission endpoint (unauthenticated) still works, so the outage is invisible from the outside until an owner actually tries to log in -- meaning it is likely to be discovered by a confused customer rather than a monitoring alert, generating a flood of "I know my password is right, your login is broken" support tickets, each of which looks at first like a user error rather than a system bug.

login() checks the submitted password against the stored hash using werkzeug's check_password_hash, but passes the two arguments in the wrong order. check_password_hash's real signature is check_password_hash(pwhash, password) -- a hash first, the raw candidate password second. The call site here passes the raw password first and the hash second.

cd flask/feedback_service export FLASK_ENV=testing .venv/bin/python -c " from app import create_app from app.extensions import db

app = create_app('testing') with app.app_context(): db.create_all() client = app.test_client()

client.post('/api/auth/register', json={'email': 'a@example.com', 'password': 'supersecret123'}) resp = client.post('/api/auth/login', json={'email': 'a@example.com', 'password': 'supersecret123'}) print(resp.status_code, resp.get_json()) "

Expected: 200 with an access_token. Actual: 401, {'error': 'invalid_credentials'}

werkzeug.security.check_password_hash(pwhash, password) tries to parse its first argument as a structured hash string (method, salt, digest) and compare the second argument's hash against it. Handed a raw password string as the "hash" to parse, it simply can never match -- it does not raise, it just always returns False. That is what makes this particular argument-order mistake so easy to ship unnoticed in a rushed manual test: it fails closed (safe-looking, no stack trace, a normal 401 response) rather than crashing loudly, so a quick "does it 500?" smoke test will not catch it. Only actually trying to log in with a real, correct password reveals the outage.

Look up werkzeug's check_password_hash signature (or its sibling, generate_password_hash, used two lines above it in register() for comparison) and check the order of arguments passed at the call site in login() against it, not just that both arguments are present.