Self hosting without using GitHub Personal Access Token

[SayakMukhopadhyay]

Hi
I have been self hosting shields for a while and was trying to reduce the use of Personal Access Tokens (PAT) in our landscape. I see that I can create a GitHub App and use its client id and secret as a configuration but the images are not loading unless I also give the PAT.

Is using PATs mandatory to use shields with private github repos? If so, why also use a github app config?

[chris48s]

Hello. The GH_CLIENT_ID and GH_CLIENT_SECRET settings are only used by shields.io for configuring our GitHub OAuth app ( https://img.shields.io/github-auth ) which allows users to donate a token (with read-only access to public repos) and increase our rate limit. These settings are not generally used for self-hosted installs. See the docs at

https://github.com/badges/shields/blob/a0149a8f8f9f2be4f8286a6e267e12aab9d1e8ab/doc/server-secrets.md?plain=1#L143-L148C50

To access private repos from a self-hosted install, you will need to use a PAT. If you want to constrain the scope of that token as much as possible, I think you should be able to generate a fine-grained PAT which has read-only access to a subset of repos, although I have not tested it with a fine-grained PAT myself and I have not enumerated exactly which repo permissions would be needed for each badge.

Assuming you do go down that route, it would be great if you could post any learnings from that here as we have not updated the self-hosting docs since fine-grained PATs were introduced a few months back.

[SayakMukhopadhyay]

Oh, I totally misunderstood the docs for GH_CLIENT_ID and GH_CLIENT_SECRET then. Is there any plans or a roadmap to allow shields to use a GitHub app based authentication instead of a PAT?

[SayakMukhopadhyay]

As for fine grained PATs, I have opened an issue at #8792

[chris48s]

Is there any plans or a roadmap to allow shields to use a GitHub app based authentication instead of a PAT?

No. We looked into whether GitHub apps would be a good fit for shields.io (as in, the service hosted at https://shields.io/ ) but what we basically need is a high rate limit for read access to any repo that any user might request through us, including ones that don't exist yet. That isn't a use-case supported by GitHub apps so we have to stick with an OAuth app for shields.io.

When it comes to self-hosted installs: we basically develop what we need for shields.io and also let people run their own install of that code if they want. We don't usually implement features that would only be relevant to users who self-host but not to shields.io itself. Keeping on top of the reviews/maintenance for stuff we use ourselves is enough of a struggle without expanding the scope like that.