Allow full access to Gitlab API (subject to user permission limits)

may need to eventually allow the GraphQL API in order for Gitlab itself to function.

Looking at the developer tools in the browser it appears this may already be the case. Previously we had #3117965: GitLab browsing is not working (GraphQL endpoint redirecting) → which required opening up the GraphQL endpoint at least partially.

Visiting just a project page (on GitLab) creates a number of GraphQL requests, some that based on the query and the results appears to be using using authentication as it returns results that are specific to the logged in user (what level of permissions the user has, and what other forks the users has access to.)

To me it appears the GraphQL API is already opened at some level for authenticated requests, PAT's are just a different form of authentication leading to the same endpoints.

we may need to eventually allow the GraphQL API in order for Gitlab itself to function.

Looking at my browsers network requests, it appears this may already be the case. I notice numerous GraphQL targeted queries when visiting various parts of GitLab. There is also #3117965: GitLab browsing is not working (GraphQL endpoint redirecting) → which indicates that GraphQL is essential. Some of these requests could in theory be handled unauthenticated, others can not.

As an example visiting https://git.drupalcode.org/project/$project_nameperforms at least two authentication sensitive queries, the first requesting what the user level permissions for the visitor are, and the second (when logged in with developer permissions) requesting what forks are writable.

If the load balancer doesn't allow filtering out these requests (as previously stated by an infrastructure team member) than it appears like the API may already open for those authenticating with JWT and project modification may already be possible. PAT based access just provides another method of access that is more compatible with traditional GitLab tooling.

I wanted to respond here - first to say that I understand and appreciate the instinct to use the tool as fully as we can, but also to help explain why our approach here has been cautious.

At this time, there is not enough granularity in the user permissions provided by GitLab to exclusively rely on that permission scheme to avoid destructive operations, whether that's user deletion, project deletion/renaming, or some other unknown feature. Furthermore, we don't have much advance notice of whether a future release will open a radical change in the API that could result in destructive operations. Adopting a principle of least privilege in API access seems prudent, especially in a transitional period before we've finished moving all of our collaboration features into GitLab (such as issues).

Further, because release management still happens on Drupal.org, among other things, we do need to care about the coupling of GitLab to Drupal.org. We do have quite a bit of infrastructure(including automated integrity checks) that help alert us to changes in the GitLab DB schema, catch API requests that have gotten lost, and other things of that nature.

From the 'gaming the credit system' perspective we also want to be cautious about enabling tools that might result in mass MRs being posted at an even greater rate than we can manage today. It's unfortunate, but we have to think not only about the feature, but the moderation of it.

Did this mean that it took an extra week or so from initial opening of PATs to resolving the API issues? Yes. Do we feel that's a reasonable delay in the circumstances? Also yes. We're erring on the side of conservative, and we understand the speed of that is somewhat frustrating, but we feel the caution is warranted.

All that said, our goal is to(gradually and carefully) open this up to be as maximally permissive as we feel is safe. I know it's tough to be patient when you witness these things take longer than planned as we're pulled into other directions, but in the meantime we do appreciate you reporting to us any unexpected failures or broken features as we open more things up - so we can fix them.

It is my understanding from posts by @drumm that the GraphQL point can not be filtered, it allows full access to GitLab (subject to account permission limits) so long as one has access to it.

We currently appear to have the GraphQL endpoint open for Session based users because it is required for GitLab to function as noted in #2

All the concerns raised in #4 appear to already be possible through the GraphQL endpoint.

This issue is essentially requesting that: The REST API be given the same restrictions as the GraphQL for Session based users, and that PAT users be given the same level of restrictions as Session users.

Most of the issues I've heard raised on Slack and here so far appear to be solvable. Users deleting themselves can probably be solved through SSO adding them each time they log in if they don't exist or worse case a re-create button on D.O., Projects on D.O. can sync to GitLab using ProjectID's instead of Project Names (and alert if a project does rename itself sending an email to the project maintainers), Deleting Projects is already prevented due to no user having the Owner permissions, etc.

Our biggest issue I suspect is the Credit Gaming, and I doubt we can make that much easier as it appears that is often done with Automation. We already provide enough API for this on D.O. that Gitlab will likely make minimal impact in my opinion. It doesn't matter how hard it is for a computer to do once its automated its done. Were much better off fighting this at the organization levels (as we have started doing with recent changes in D.O. policy) by making it a cost negative process to be credit farming.

Adding a tag to track requests related to the GitLab API

The GraphQL endpoint has been open for cookie login for over a year now.

Have we had any confirmed incidents of abuse? If not do our arguments above for not allowing access still hold validity?

I noted in SLACK I’ve seen some niche Gitlab apps use Cookie login (it’s rare because why bother) and I’ve seen browser plugins. Inherently all of the above is already accessible. At this point we are just punishing those developers who want to be dedicated to their projects and are early adopter of tools.