Ability to get the current logged in user's api token

[Joe Ferr]

We use the gradle/groovy dsl to create our jenkins jobs.

We have a need to have parameterized jenkins jobs which create job-sets+views to avoid various folks needing to run gradle scripts/pass parameters in order to create job sets.  For example a job set might retrieve source from a specific git task branch then build a bunch of components which get uploaded to Nexus.

I can use a specific users username/api token in the gradle script, but it would be much cleaner if the current logged in user's api token was somehow exposed (as an env var?)/ made available to my gradle script.

thanks,

Joe

[Daniel Beck]

> On 21.12.2015, at 23:00, Joe Ferr <jf...@iqnavigator.com> wrote:
>
> much cleaner if the current logged in user's api token was somehow exposed (as an env var?)/ made available to my gradle script.

And by "cleaner" you mean "enable your users to steal other users' API tokens just because they clicked 'Build Now' on some job"?

This looks like a job for a password parameter (because that's what it is), or maybe Credentials.

Alternatively, you can probably achieve this with some (Groovy) scripting, e.g. System groovy build steps from the Groovy plugin. Some familiarity with Jenkins internals is required.

[Joe Ferr]

I'd use the Mask Password plugin to hide the exposed token from the console output so I don't think there would be a way to steal others users API tokens.

A password parameter would work but it means that they need to login twice...Not really a big deal; they've already logged into Jenkins.  I suppose this will be the fall-back if I can't figure this out using a system groovy script

The Jenkins DSL plugin doesn't support credentials as far as I know.

Thanks,

Joe

[Victor Martinez]

Hi,

Jobddsl does support the credential plugin indeed.

https://github.com/jenkinsci/job-dsl-plugin/wiki/Handling-Credentials

Cheers

[Daniel Beck]

> On 21.12.2015, at 23:49, Joe Ferr <jf...@iqnavigator.com> wrote:
>
> I'd use the Mask Password plugin to hide the exposed token from the console output so I don't think there would be a way to steal others users API tokens.

That plugin can only hide build parameters and previously defined strings. Do you want to maintain a central list of all API tokens for all users so you can hide them from build output, or how would this work?

Also, my point was that any "magic" mechanism (not requiring user input) that adds the tokens to the environment for access by the build script could be used by users able to configure any _other_ job in a way that gives them the API tokens there. If they just write the API tokens to a file rather than echo them to stdout/stderr, Mask Passwords won't help either.