GetJobTokensJob should not include the private token in the request headers

[finkandreas]

In a nutshell, with the header one gets {"message":"404 Job Not Found"}
Reproducer: Get a valid job token, and test with curl

curl "https://gitlab.com/api/v4/job?job_token=MY_JOB_TOKEN" # works fine
curl -H 'Private-Token: MY_GITLAB_TOKEN' "https://gitlab.com/api/v4/job?job_token=MY_JOB_TOKEN" # fails with 404

Interestingly MY_GITLAB_TOKEN would have access to the job that it wants to access, but apparently Gitlab does not like to mix the two tokens.

Would it be possible to discard the header Private-Token for this specific request?

[finkandreas]

As a workaround I can do

func remove_private_token(r *retryablehttp.Request) error {
    r.Header.Add("Private-Token", "")
    return nil
}

c, err := gitlab.NewClient("my_token")
jobTokenOptions := gitlab.GetJobTokensJobOptions{JobToken: gitlab.String(job_token)}
job, _, err := c.Jobs.GetJobTokensJob(&jobTokenOptions, remove_private_token)

But this heavily relies on the implementation detail that in client.Do there is a check whether the header "Private-Token" is already set, and on the fact, that gitlab.com apparently ignores an empty value for Private-Token. Both are not guaranteed to work in future versions of this library / gitlab.

[theoriginalstove]

I think you want to use NewJobClient instead of NewClient. That sets the auth type to JobToken instead of PrivateToken. You should then be able to call GetJobTokensJob as usual:

c, err := gitlab.NewJobClient("")
if err {
    //do what you want
}
opt := &gitlab.GetJobTokensJobOptions{JobToken: gitlab.String("job_token")}
job, resp, err := c.Jobs.GetJobTokensJob(opt)
...

And I think you can even do this (I might be wrong though):

c, err := gitlab.NewJobClient("the_token_youre_looking_for")
...
job, resp, err := c.Jobs.GetJobTokensJob(nil)

Since Do adds a header of JOB-TOKEN: <your-job-token> and according to the examples in the docs, that should work as well.

[finkandreas]

What is the cost of generating a new job client for every such job-token? It feels a bit overhead to create a client for a single request and then dump it again, but if client creation is a cheap operation that could be an option too.
I would still suggest to document it, that this endpoint should only be called with a JobClient.

[theoriginalstove]

@finkandreas I haven't tried it, but maybe initialize the NewJobClient with an empty token. Then query that way with using GetJobTokenJobOptions for each token? This way you don't need to reinitialize the client every time. I'm wondering/thinking the Gitlab API might ignore an empty job token in the header like it does for personal tokens.

[svanharmelen]

Creating a new client isn't super expensive, but is also isn't cheap as it creates and allocates a new struct for every (currently 108) service.

We could potentially add a SetJobToken method on the client that checks if the auth type is JobToken and if so updates the used token on the client if the use case you described is and expected/common workflow.

[finkandreas]

@theoriginalstove You are right, I can create a NewJobClient("") which has an empty token, and then reuse this client for different job tokens.

@svanharmelen I think the expected behaviour is that any type of client "just works", as long as it is not documented otherwise.

[svanharmelen]

Yeah, well I guess that is quite dependent on what is documented by GitLab and by what actually works with the GitLab API (which isn't always that obvious). Feel free to open a PR if you think some additional comments on the different clients would be beneficial...

[finkandreas]

For now I opened a ticket with gitlab, let's see what they have to say: https://gitlab.com/gitlab-org/gitlab/-/issues/391924