fetch the api key for the current user?

93 views
Skip to first unread message

Brian J. Murrell

unread,
Jan 30, 2016, 1:11:11 PM1/30/16
to jenkins...@googlegroups.com
I am looking for a REST API handle to get the API key of the user that
ran a job.

That is, within the build steps of a job, I want to get the API key of
the user running the job to use to authenticate to jenkins to carry out
other activities within the job.  In particular I want to use it to
fetch artifacts from another job, but the fetch should be done as, and
authenticated as the user running the job.

Is there a way, within a job to (a) determine the userid of the user
that started the job and/or (b) get that (or just the current) user's
API token?

Cheers,
b.
signature.asc

Daniel Beck

unread,
Jan 31, 2016, 5:46:02 PM1/31/16
to jenkins...@googlegroups.com

On 30.01.2016, at 19:10, Brian J. Murrell <br...@interlinx.bc.ca> wrote:

> I am looking for a REST API handle to get the API key of the user that
> ran a job.

I think any answer to this would likely be a security issue and should be reported as such, rather than posted here.

Thank you.

Brian J. Murrell

unread,
Feb 1, 2016, 10:38:49 AM2/1/16
to jenkins...@googlegroups.com
On Sun, 2016-01-31 at 23:45 +0100, Daniel Beck wrote:
> On 30.01.2016, at 19:10, Brian J. Murrell <brian-SquOHqY54CVWr29BmMi2
> c...@public.gmane.org> wrote:
>
> > I am looking for a REST API handle to get the API key of the user
> > that
> > ran a job.
>
> I think any answer to this would likely be a security issue and
> should be reported as such, rather than posted here.

How do you figure?  And what exactly are you proposing to report and to
whom?

This is nothing more than user Bob being able to ask the REST API,
(_when_he_is_already_logged_in_to_Jenkins_), "what is my API key?" and
more accurately the job that Bob run, (again when Bob has already
logged in using Bob's credentials) to initiate further API calls on his
behalf, because you know, Bob did ask to run the job.

b.
signature.asc

milki milk

unread,
Feb 1, 2016, 4:24:18 PM2/1/16
to Jenkins Users, br...@interlinx.bc.ca
On Monday, February 1, 2016 at 7:38:49 AM UTC-8, Brian J. Murrell wrote:
On Sun, 2016-01-31 at 23:45 +0100, Daniel Beck wrote:
> On 30.01.2016, at 19:10, Brian J. Murrell <brian-SquOHqY54CVWr29BmMi2
> c...@public.gmane.org> wrote:
> I think any answer to this would likely be a security issue and
> should be reported as such, rather than posted here.

How do you figure?  And what exactly are you proposing to report and to
whom?

The security part comes in when you fetch an arbitrary user's key which you generated as "the user running the job."

Fetching the current user's api key doesn't seem to have a REST API equivalent. Right now, I just scrape the user's configure page - /user/USERNAME/configure - and look for the pattern -- name="\_\.apiToken"[^>]+value="(\w+?)".

-milki

Brian J. Murrell

unread,
Feb 1, 2016, 4:45:18 PM2/1/16
to jenkins...@googlegroups.com
On Mon, 2016-02-01 at 13:24 -0800, milki milk wrote:

> The security part comes in when you fetch an arbitrary user's key

I never ever said fetch an *arbitrary* user's key.  I said a job run as
user Bob would fetch the key of the user (again, Bob) who ran it, who
has to be already logged into Jenkins (again, as Bob) to even run the
job.  So it's absolutely no different from you logging into Jenkins,
and going to your user/USERNAME/ page and fetching your key.

> Fetching the current user's api key doesn't seem to have a REST API 
> equivalent.

Yeah.  That was the conclusion I was coming to.

> Right now, I just scrape the user's configure page - 
> /user/USERNAME/configure - and look for the pattern -- 
> name="\_\.apiToken"[^>]+value="(\w+?)".

I guess that's one way.

Cheers,
b.
signature.asc

Daniel Beck

unread,
Feb 1, 2016, 5:55:48 PM2/1/16
to jenkins...@googlegroups.com

On 01.02.2016, at 22:44, Brian J. Murrell <br...@interlinx.bc.ca> wrote:

> So it's absolutely no different from you logging into Jenkins,
> and going to your user/USERNAME/ page and fetching your key.

Except in one case you're in the same authenticated browsing session, and in the other case, you're not. Arbitrary programs launched e.g. through shell scripts don't magically inherit your session cookies.

Reply all
Reply to author
Forward
0 new messages