Logging in with the correct password fails

POST /api/auth/login/ is the only way an existing user gets back into the app once their original registration token is gone (expired client storage, a new device, a cleared browser). Right now, every single login attempt with completely correct credentials fails with "Unable to log in with the provided credentials." That is a full authentication outage for the returning-user flow -- new signups still work (registration hands back a token directly), but anyone who already has an account and needs to log back in cannot get past this endpoint. This is the kind of bug that generates a support ticket flood and an on-call page within minutes of shipping, because it doesn't fail for one edge case -- it fails for 100% of real login attempts.

LoginSerializer.validate() calls Django's authenticate() with the username and password keyword arguments swapped -- authenticate(username=attrs["password"], password=attrs["username"]). authenticate() checks the value passed as username= against the user table's username field and the value passed as password= against the stored password hash, so with the arguments swapped it only ever matches by coincidence (a user whose username literally equals their password).

python manage.py shell -c " from django.contrib.auth import get_user_model get_user_model().objects.create_user(username='dana', password='a-strong-password-123') " python manage.py runserver & curl -s -X POST http://127.0.0.1:8000/api/auth/login/
-H 'Content-Type: application/json'
-d '{"username":"dana","password":"a-strong-password-123"}'

-> {"non_field_errors":["Unable to log in with the provided credentials."]}

even though "dana" / "a-strong-password-123" is exactly correct.

This isn't a validation-logic bug (the "if user is None: raise ..." check right below it is correct) -- it's a call-site argument-order mistake. It's easy to miss in review because the line still reads like a normal authenticate(username=..., password=...) call; you have to actually check which attrs[...] key lands in which keyword slot.

Look at LoginSerializer.validate() in accounts/serializers.py line by line against what django.contrib.auth.authenticate() expects for its username= and password= keyword arguments, and compare to how RegisterSerializer (same file) and accounts/tests.py construct their payloads.