v0.3.2 — log in to instances that issue the CSRF token late

Bugfix release, reported from a real deployment: logging in failed with 403 — the repository refused the login request (CSRF token rejected) even though the credentials were correct.

What was wrong

The client assumed the CSRF token can always be fetched in advance, from the header or cookie of GET /api/authn/status. On the reporting instance (DSpace 9.1) that endpoint returns no token at all — neither header nor cookie. The token is generated lazily and only arrives with the 403 that rejects the token-less login attempt.

So the client posted without X-XSRF-TOKEN, got a 403, and stopped with a message that sounded like a configuration problem — while the password was fine all along.

The fix

After a 403, check whether the response carried a token. If it did, retry the login exactly once with it. If it did not, the server still stops and asks, so no retry loop can form.

No branching on the reported DSpace version: the client reacts to what the instance actually answered, not to what it calls itself — the same rule that already governs search filters and facets.

Worth noting

The full test suite was green, and so were the contract tests. demo.dspace.org issues the token immediately, so the lazy path never ran there. This one could only surface against a real deployment. Fixtures captured from that instance are now in the repository, so it stays covered.

Verified against the reporting instance: with a deliberately wrong password the failure reason changed from CSRF token rejected to rejected that username or password, which is the correct answer and shows the CSRF hurdle is gone.