<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=29214) </details> <!--IssueSummary end--> ## Summary From a brief discussion about how `/api/v4/internal/allowed` is being used and possibly be cleaned up: https://gitlab.com/gitlab-org/gitaly/merge_requests/1263#note_176631269 The said endpoint is being used by both gitlab-shell for SSH authentication and pre-receive hook checks. Those are 2 different things and can possibly be cleaned up by having a separate endpoint for one of each responsibilities. That way, it's easier to extend or modify it without making it dirtier or worry about changes that may affect a responsibility inadvertently. ## Improvements When responsibilities of the endpoint are decoupled, it'll be easier to modify each endpoint without worrying about changing one will affect the other. ## Risks Could break older clients that will be accessing the current `/api/v4/internal/allowed` endpoint. I think this can be mitigated by instead of changing the existing endpoint, introduce 2 new endpoints and update the clients to use them instead. ## Involved components - gitlab-rails - gitlab-shell - pre-receive hook (in Gitaly)