Query for a project returns null when trying to use project token
Query
query { project(fullPath: "projectName") { name }}
Expected
{ data: { project: { name: "projectName" }}}
Actual
{ data: { project: null }}
What works
REST API, no problems using a Private-Token header with a project token and my own personal token.
CURL, using personal token with cURL using an "Authentication: Bearer" header.
GraphQL, personal token, with the Private-Token OR Authorization header, I can fetch issues without problem.
What doesn't work
If I try to use a project token, with the Private-Token OR Authorization header, to fetch issues with cURL or a node http request, the return result is data {project: null}}
When testing, the only thing I did was replace the token. Otherwise, it was the same command.
Gitlab version: 13.2.1-ee (I know we are behind. I have no control over that though and I can't find a bug report on this issue, so if this is fixed in a newer version, my apologies)
I've re-created this. It looks like the user that the project token is attached to is a project bot (which makes sense), and so doesn't really have login privileges, and therefore our authentication check fails.
Not sure why the API would work. Still investigating...
I wanted to ask for your assistance on a question that one of my fellow developers is running into an issue with:
We're using a personal access token to work around this but obviously it's not ideal. It's affecting this one endpoint that we have with GraphQL that we would like to query.
Any chance we could +1 it and drive it a bit higher in priority? Or maybe do you have any idea behind the scenes about where this sits in the road map potentially?
When we do schedule this, it would be very helpful to discuss this with @gitlab-org/graphql-experts, since this will need to be designed in a way that work with the way we currently authorize all resources.
As noted above, GraphQL queries fail because current_user is nil. Perhaps we could add an additional check to authorize_access_api! to allow project tokens to make queries. I would definitely appreciate any input from @gitlab-org/graphql-experts :)
Without allowing access using project/group access tokens, the whole GraphQL interface can't be seriously used in CI/CD pipelines and it will always remain just a frontend toy.
This issue is currently blocking us because we can't use personal access tokens within pipelines for security and compliance reasons.
I submitted this ticket in September 2020 and it is still here with how to fix it being "decided upon." We would really love to see it implemented so we can use the API properly in CI/CD. From the standpoint of using Gitlab in a business/company (and we are an Enterprise paying customer), it doesn't make sense to NOT have this implemented unless GraphQL is not actually intended for use. Only being able to use a personal token with it is fragile since it relies on a single person to be able to run something. Not ideal for a group project.
Unfortunately, given how long it has been, I don't hold out much hope for it any time soon.
We managed to solve this problem by using a service account token. So we've created a separate service account and using a personal token from this account to read graphQL api. So it's not really true that is just a frontend toy - graphQL brings quite a lot of benefit even in CI/CD. One of examples: if you want to fetch upstream pipeline information from downstream - there is no API available for that - only via graphQL. Of course using project access tokens or may be even job tokens for graphql requests may be easier to use, but also it may be also quite limited.
Does that service account count as a licensed user? I am not sure my higher-ups would go for that as we pay another division for the licenses right now. But it is a pretty clever workaround.
I started this issue off because I was working with project tokens specifically, but I think you are correct there could be some limitations if you need to go up or down. I did just notice that an old ticket I made about Group tokens was closed (duplicated) and they were implemented in 14.7. I think that would be my ideal situation then: using a group token to be able to access the GraphQL api of projects and subprojects from the group level down.
I agree that there's huge potential in GraphQL - there are situations where you could retrieve necessary data with a single graphql query, instead of calling tens or hundreds of REST calls. For example, I needed to get information about the latest successful job (not just the last successful pipeline) for a given branch and given job name.
But passing a real user's access token to ci/cd config (or wasting license seat for service account) is a no-go.