v0.3.0 — optional read-only authentication

Lets you optionally give the server a DSpace account, so it can also read material that is not public: embargoed items, restricted collections and closed files.

Without an account nothing changes — the same nine tools, the same requests, byte-for-byte the same tool schemas as 0.2.0. Logging in is never required, and it never grants the ability to modify anything.

Read-only, still by construction

Every request that carries data is a GET. The only other request in the entire codebase is the login POST, to one hard-coded path, in a method with no path parameter. Two tests hold this in place: one asserts that the only non-GET request goes to exactly <base-url>/api/authn/login (equality, not endswith — so https://evil.test/authn/login cannot pass), the other reads the package source and requires exactly one .post( and zero put/patch/delete/request.

The login request runs with follow_redirects=False: httpx replays 307/308 with the request body, so a redirect could otherwise hand your password to another host.

New

• Optional login via DSPACE_USERNAME / DSPACE_PASSWORD (or --username / --password). In the .mcpb bundle the password is stored in your operating system's keychain.
• compare_access — answers "the user says files are missing". Asks as your account and anonymously, through separate connections with separate cookie jars, and returns only the difference: which files the public cannot reach.
• continue_anonymously — reachable only after a failed login.
• get_repository_info now reports whether the server is querying anonymously or as an account.

Both new tools are registered only if an account is configured, so an anonymous install pays nothing for them.

If the login fails, the server stops and asks

It does not quietly fall back to anonymous access. That would make the assistant report "no such record" for material you can plainly see. Instead every tool returns a question, and the assistant puts the choice to you: fix the credentials and restart, or explicitly continue with public data only.

Only password login is supported. Repositories authenticating solely through ORCID or Shibboleth need a browser; the server detects this from the instance itself and says so rather than failing obscurely.

Notes for repository owners

The configured account is an ordinary DSpace account with ordinary permissions — an administrator account gives the assistant an administrator's view. Use the least-privileged account that covers what you need. It cannot modify anything either way.

Under the hood

Three measurements against a live instance shaped this release:

• An invalid token does not produce a 401 on public endpoints — DSpace silently answers 200 with anonymous data. Waiting for a 401 to refresh would therefore never trigger, and after ~30 minutes searches would quietly start losing restricted records. Tokens are refreshed proactively, from the exp claim, with a margin.
• The DSPACE-XSRF-TOKEN header is sent only when a new token is issued; afterwards the value lives in the cookie alone. Reading only the header worked exactly once, so the second login returned 403.
• A floor between logins prevents a skewed clock, or an instance answering 401 instead of 403, from turning the server into a login machine and earning an IP ban.

447 offline tests plus 12 contract tests against demo.dspace.org.