We have an internal error appearing for users occasionally (https://gitlab.cee.redhat.com/kernel-qe/sustaining-engineering/seqe/-/issues/15) which comes down to our auth code raising a `KeyError` looking for the `csrftoken`

```python
_dw_session.get(DW_OIDC_AUTH_URL,
auth=requests_gssapi.HTTPSPNEGOAuth(),
allow_redirects=True)

1. Fill in headers required for CSRF validation
   _dw_session.headers.update( { "Referer": DW_BASE_URL, "X-CSRFToken": _dw_session.cookies["csrftoken"], "User-Agent": "seqe", }

   )
   ```

I'm not defending that code - half the problem is the calling code around it doesn't handle that well, leading to confusing user responses.

But, despite the issues on my side of the code ... the `csrftoken` isn't set. The problem is it's a Heisenbug, you rerun things with debugging and it works. But I think I've managed to catch it in the act, because on one of my debugging runs I dumped the headers and they were

```

{'cache-control': 'no-store', 'content-encoding': 'gzip', 'content-type': 'text/html; charset=utf-8', 'set-cookie': 'techaro.lol-anubis-auth=; Path=/; Domain=datawarehouse.cki-project.org; Expires=Wed, 18 Feb 2026 01:20:45 GMT; Max-Age=0; Secure; SameSite=None, techaro.lol-anubis-cookie-verification=...; Path=/; Domain=datawarehouse.cki-project.org; Expires=Wed, 18 Feb 2026 01:51:45 GMT; Secure; SameSite=None, ...=...; path=/; HttpOnly; Secure; SameSite=None', 'date': 'Wed, 18 Feb 2026 01:21:45 GMT', 'transfer-encoding': 'chunked'}

```

This strongly makes me suspect anubis is involved. That this disappears after some retries also seems to fit the pattern. I don't really understand how anubis works at this level, I mean I know I see a page and get redirected when I use a browser. We have `allow_redirects` on the `get()` but perhaps it's using a `<meta>` tag or something that `requests` can't follow?

If that is the problem; at first I was going to suggest the login endpoints shouldn't be protected by anubis, but then I wonder if that just moves the problem to the next API call. Unless anubis knows to get out of the way of authenticated sessions, which it might? Otherwise, is there something I should do to reliably "pre-authenticate" these calls as not originating from a soul-sucking Tessier-Ashpool AI farm?

Jira: CKI-6521