Token management, programmatically - CSFR?

[murat (Murat Ozdemir)]

• which versions are you using SonarQube-enterprise 10.6.0
• how is SonarQube deployed: Docker
• what are you trying to achieve: Rotate tokens with admin rights - problem with revoking
• what have you tried so far to achieve this: I tried running calls to Web API [ api/user_tokens/revoke] with basic auth (admin, password) and with an admin USER_TOKEN, both cases silently fail and throw DEBUG web[f4a933f6-4f0a-4a63-80b5-fac3702e4811][auth.event] login failure [cause|Wrong CSFR in request][method|JWT][provider|LOCAL|local][IP|] with 401.

This makes programmatic management of tokens problematic.
Since SonarQube doesn’t provide OIDC-based short lived tokens to initiate scans per project, I was considering creating a PROJECT_ANALYSIS_TOKEN for each project and store them as repository secrets to be referenced in CI/CD, and apparently it would have been a costly mistake to clean up, since I won’t be able to revoke them with a script. This way, I have to trust my users to manage their tokens, or support them from UI, which is something I want to automate away.

If I don’t want to use a GLOBAL_ANALYSIS_TOKEN, what are my options from this point onwards?

[ganncamp (G Ann Campbell)]

Hi,

Are all APIs returning like this, or only this API? Wrong CSFR in request usually points to a reverse proxy mucking about with cookies.

Wrong CSFR in request

The issue you’re encountering is because the cookie XSRF-TOKEN has his attribute HttpOnly set to true, whereas it should be set to false. There’s probably something in your configuration that set all HttpOnly attributes to true. You need to update this in order to let this value to false for XSRF-TOKEN.

 
HTH,
Ann

[murat (Murat Ozdemir)]

Can confirm that the problem is still, strictly speaking, between the monitor and the chair.