No valid crumb - scm trigger doesn't work since 2.222 - pull 4509
Stölzer Sven
Hi Jenkins-Team,
it seems that since version 2.222 the scm trigger doesn’t work.
The requested Crumb form jenkins server was correctly included in the post commit hook see attachment.
But the Jenkins throws an: “HTTP ERROR 403 No valid crumb was included in the request”.
Where is the error location? The generated subversion wget command or security handling into the Jenkins?
---
Wget cmd: /usr/bin/wget --auth-no-challenge --header "Jenkins-Crumb:9a6dc1d616085659d48e4d26f1509ab6fbf78b2a6d732852b9d758dc46a54e71" --post-data "U branches/BRANCH_sves/BRANCH_2_9_3_systech/scripts/linux/build_deb.sh" --output-document "-" --timeout=1 --dns-timeout=30 --tries=3 http://172.20.5.73:44444/subversion/f33a5e67-b273-c240-b8af-d48613201abc/notifyCommit?rev=25557
---
Jenkins Configuration: CSRF Protection -> Crumb Issuer -> Standard-Crumb-Generator
---
In my opinion the Jenkins changelog version 2.222: “Remove the ability to have CSRF protection disabled. Instances upgrading from older versions of Jenkins will have CSRF protection enabled and the default issuer set if they currently have it disabled. (pull 4509)“ is the problem.
Did you have any ideas?
Best regards
Svestl
Geschäftsführer: Dr. Albert Schmidt · Dr. Oliver Vietze
Sitz der Gesellschaft: Radeberg
Amtsgericht Dresden: HRB 15379
Ust. ID: DE 189714583
Slide
--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/0E03711F7CAA144B915279ECD2B6EED902B2B1B741%40srvchfra018.baumernet.org.
Daniel Beck
> On 9. Mar 2020, at 13:06, Stölzer Sven <SSto...@baumer.com> wrote:
>
> it seems that since version 2.222 the scm trigger doesn’t work.
> The requested Crumb form jenkins server was correctly included in the post commit hook see attachment.
If Jenkins was already configured to require CSRF crumbs before the update, then nothing should have changed.
If that wasn't the case however, but the script already submitted CSRF crumbs, those should have been unnecessary in the past…? So why did it do that? Who or what generated that command?
If you recently adapted your script to submit CSRF crumbs after the update, you didn't do it quite right. Why, and how to solve it, is explained at https://jenkins.io/doc/upgrade-guide/2.176/#SECURITY-626