How to fix 'invalid crumb' warnings?

Hi

In our Jenkins System Log we see many instances of messages like these:

Jun 08, 2021 12:09:17 PM WARNING hudson.security.csrf.CrumbFilter doFilter
Found invalid crumb 3554fd3884df49f975319b4852c6caef3f8f0f96da8e2bfbcc493abf78cdc9d3. If you are calling this URL with a script, please use the API Token instead. More information: https://jenkins.io/redirect/crumb-cannot-be-used-for-script
Jun 08, 2021 12:09:17 PM WARNING hudson.security.csrf.CrumbFilter doFilter
No valid crumb was included in request for /jenkins/view/Matrix%20jobs/ajaxBuildQueue by <username>. Returning 403.

Should I try to fix them? If so, how?

Best Regards
David

It’s normally a result of an expired session, nothing you can do about it.

We probably shouldn’t log this by default, any thoughts @danielbeck @jglick ?

We’ve already adjusted logging here to not log when the associated session is anonymous. That’s the trivial “expired session” case. See [JENKINS-40344] Don't log warning for invalid crumb from anon by daniel-beck · Pull Request #3049 · jenkinsci/jenkins · GitHub

This now mostly happens with multiple tabs (some of which have pages loaded under the old session with a now invalid/expired crumb), or when you’re using some sort of bad automation that still assumes that crumbs for specific users never expire.

If we stop logging this, we also no longer help users understand why their old scripts stopped working.

We use multiple tabs so I guess that’s the cause. We don’t use automation.

I think if a warning is issued, it is reasonable to expect to find a way to fix the problem. How can that be done in the case of multiple tabs?

I think if a warning is issued, it is reasonable to expect to find a way to fix the problem. How can that be done in the case of multiple tabs?

Reload the page and you will get the new crumb

If we stop logging this, we also no longer help users understand why their old scripts stopped working.

API tokens have been around since ~2.89 isn’t it? How long do we ‘help’ them for?

I’m not saying we shouldn’t change this, just pointing out there’s a downside. If we want some folks to have a cleaner system log while no longer helping others to understand why their scripts start breaking after a long overdue update, we can easily change this.

The change that made existing scripts (using passwords and fixed crumbs) actively break went into 2.186/2.176.2: Upgrading to Jenkins LTS 2.176.x. The log improvement with a web page reference went into 2.220: Improve log after SECURITY-626 by Wadeck · Pull Request #4443 · jenkinsci/jenkins · GitHub

1 Like

Hello,
We start to configure the Jenkins Operator (latest version - Latest (v0.6.x):frowning:Latest (v0.6.x) | Jenkins Operator jenkins/jenkins:2.277.4-lts-alpine).
In some cases we get in jenkins UI the following error message:

HTTP ERROR 403 No valid crumb was included in the request

The CSRF protection is:

Should I try to fix them? If so, how?

Thanks,
Irina Rozalio

Hi Irina,

The original topic was about getting the error while doing api calls. That recommends you use api tokens so you don’t have the issue.

For UI issues though, thats usually misconfiguration, proxy not passing headers right. Your jenkins url in your config doesn’t match the url your accessing with it. http vs https, etc.

is is possible that the operator is doing something weird. Just in case we are going to ping @Sig00rd

Hello @Ira1 and @halkeye ,

Operator only runs a script to enable CSRF Protection with Default Crumb Issuer.

You can configure Operator not to set this (setting Jenkins CR’s spec.master.disableCSRFProtection to true) if you’re fine with less secure connection.

In general this problem doesn’t happen with standard Jenkins installations with Operator, and it probably requires some additional configuration to fix, eg. if in your case the requests to Jenkins API go through some load balancer.

1 Like