Re: Jenkins API token behaviour change (no longer valid with new Jenkins images after Jenkins restart?)

2019-02-07 Thread Daniel Beck



> On 1. Feb 2019, at 14:59, adamrobertsah...@gmail.com wrote:
> 
> we've noticed a problem when upgrading the base Jenkins image beyond 2.153 
> however

To clarify, the problem occurs from 2.154 on? If you only tried a later 
release, could you try to determine the release that broke it?

-- 
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/C7106BE3-D411-40EF-B36A-487BC13AF2A3%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.


Jenkins API token behaviour change (no longer valid with new Jenkins images after Jenkins restart?)

2019-02-01 Thread adamrobertsahyes
Hi all, seeing strange behaviour with newer Jenkins image versions, API 
tokens, and Jenkins on Kubernetes.
 
We're using the Jenkins helm chart and API tokens so that our own 
microservice can talk to it - we've noticed a problem when upgrading the 
base Jenkins image beyond 2.153 however. It seems our tokens are 
invalidated after the Jenkins pod terminates.
 
Any version before this and our API tokens are fine (so we can do a wget 
from our pod to the jenkins service for example) but with newer versions 
it's always reporting an invalid password. I'd really like to up the 
Jenkins base version as I see lots of bug fixes and CVE fixes at the 
Jenkins changelog. Unfortunately jenkins/jenkins:lts has the same problem 
for us.

I know the API token behaviour changed many releases ago and so I'm 
wondering if any other internals have changed that could be causing this? I 
know If I create a new API token using the UI, I can use that completely 
fine, but we want to reuse the same token inbetween Jenkins restarts.
 
Has anybody seen this also?
 
Our requests were previously working with the following code, an example 
being
wget http://admin:atokenhere@my-jenkins:8080/user/admin/configure 

Constructed with the pattern (in our Go code):
 
url := strings.Split(jenkinsURL, "://")[0] + "://" + jenkinsUser + ":" + 
seedAPIToken + "@" + strings.Split(jenkinsURL, "://")[1] +
"/user/admin/descriptorByName/jenkins.security.ApiTokenProperty/generateNewToken?newTokenName=temporary"
req, err := http.NewRequest("POST", url, nil)
I know of 
 
curl -X POST -s -u admin:$PASS -H `curl -s -u admin:$PASS 
$URL'crumbIssuer/api/xml?xpath=concat(//crumbRequestField,":",//crumb)'` 
$URL'me/descriptorByName/jenkins.security.ApiTokenProperty/generateNewToken' 
| jq -r .data.tokenValue via https://github.com/jenkins-x/jx/pull/2459 so 
I'm going to give this a try as well.
 
Would be great to figure out what exactly has changed and if the above is 
considered best practice, thanks!

-- 
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/503be664-33a3-40d9-aad6-f0b85d608fd3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.