Shields: support for private github repos?

[pablote]

Is there a way for me to create badges for private repos? I'm mostly interested in github related badges like this one: https://img.shields.io/github/tag/strongloop/express.svg

I went through the shields.io page, this repo, and I haven't found any information on how to achieve this, if possible at at.

thanks for the help

[espadrine]

You may be able to do so by setting up your own instance of a shields server with the correct tokens in secret.json (see more here).

I would not accept a PR that requires you to include your secret token in the URL for the badge, for security reasons, so it's not as easy to do as it is for public repos.

[nexocentric]

Would either of you know if any progress has been made on this issue?

[fcpauldiaz]

What's the progress on this issue?

[paulmelnikow]

Thaddée's comment above says it all:

You may be able to do so by setting up your own instance of a shields server with the correct tokens in secret.json (see more here).

I would not accept a PR that requires you to include your secret token in the URL for the badge, for security reasons, so it's not as easy to do as it is for public repos.

[eneko]

@espadrine Seems like there are a bunch of shields that require (or support) passing a token in the URL. How are those services different than passing an access token for GitHub private repos?

Example:

https://img.shields.io/circleci/token/YOURTOKEN/project/github/RedSparr0w/node-csgo-parser/master.svg

Travis CI supports badges for private repos too, which is very cool. It would be great to be able to access release information, etc. In a secure way, of course.

[monokrome]

The important thing, I think, is that the token is only given access to status information. Only people who already have access to that information can read the data in that repo unless the contents of the repo are exposed elsewhere. At the point that they are exposed, what exactly are you protecting against now?

[dreamyguy]

I understand the concerns about security when information is behind tokens, in general terms.

But is build status such a big deal? Perhaps a subjective question out of a GitHub issue's scope, but I suppose those interested in showing the badge would be well aware of the "risk" they would be taking, in this case.

A statement like "we can't handle the load caused by opening up for private repos" would be quite fair and easier to accept. Peace. 🙂

[calebcartwright]

A statement like "we can't handle the load caused by opening up for private repos" would be quite fair and easier to accept. Peace.

The rationale for the decision is articulated above, and it has absolutely nothing to do with load.

Seems like there are a bunch of shields that require (or support) passing a token in the URL. How are those services different than passing an access token for GitHub private repos?

AFAIK there's only two badges that accept a token in a route/url param (codeceov and circleci). If we could we'd remove them, but they still exist because we can't remove/break existing badges.

I understand why folks want badges for their private repos/projects, and that the fact that codecov and circle bages accept tokens is frustrating. However, we don't want to make the problem worse by adding _more_ instances where Shields has to deal with url-provided private tokens.

There's two viable options for folks that want to use Shields to get badges for private repos:

1. Use a self-hosted Shields instance with appropriate GH auth in your configuration -https://github.com/badges/shields/blob/master/doc/server-secrets.md#github
2. Use Shields.io and the Endpoint badge with your own custom endpoint that provides the data needed for Shields.io to create and provide the badge - https://shields.io/endpoint

I hope that helps, though fully realize some folks will still be unhappy with the decision.

I'm going to lock this one as well given all of the above and the age of the issue.