OAuth from CMS is requesting full read/write access to a users private and public repos #120

mofrim commented 2026年04月30日 12:02:25 +02:00

When logging in from https://diday.org/admin/ via forgejo the following message is shown to the user:

Authorize "diday.org CMS" to access your account?

If you grant access, it will be able to access and write to all your account information, including private repos and organizations.
This application was created by @DI-Day.

With scopes: repository.

This is needed at least one time if the websites repo has not yet been forked to the users forgejo-account.

There is a active and as it seems near to finished issue about this in forgejo repo: forgejo/forgejo#4052. The main problem is, that fine-grained access-control for OAuth-apps has not yet been implemented as it is for AccessTokens.

From the discussion in that issue and from https://forgejo.org/docs/next/user/token-scope/#public-only i get the impression that setting scopes in the OAuth request to forgejo is already implemented but lacks a UI.

For example replacing the scope parameter in the request from https://diday.org/admin/ which initially looks sth like this:

https://codeberg.org/login/oauth/authorize?client_id=...&redirect_uri=https%3A%2F%2Fdiday.org%2Fadmin%2F&response_type=code&scope=repository&state=%7B%22auth_type%22%3A%22pkce%22%2C%22nonce%22%3A%22...

to

https://codeberg.org/login/oauth/authorize?client_id=...scope=only-public...

also leads to a successful login. However, i am not sure if it really has the desired effect of at least only granting the CMS only access to public repos. But i guess if it is implemented it should 🙃?

I think we should monitor the progress in forgejo/forgejo#4052 or eventually get involved. But i haven't done anything in Go yet.

When logging in from https://diday.org/admin/ via forgejo the following message is shown to the user: > Authorize "diday.org CMS" to access your account? > If you grant access, it will be able to access and write to all your account information, including private repos and organizations. This application was created by @DI-Day. > With scopes: repository. This is needed at least one time if the websites repo has not yet been forked to the users forgejo-account. There is a active and as it seems near to finished issue about this in forgejo repo: https://codeberg.org/forgejo/forgejo/issues/4052. The main problem is, that fine-grained access-control for OAuth-apps has not yet been implemented as it is for AccessTokens. From the discussion in that issue and from https://forgejo.org/docs/next/user/token-scope/#public-only i get the impression that setting scopes in the OAuth request to forgejo is already implemented but lacks a UI. For example replacing the `scope` parameter in the request from https://diday.org/admin/ which initially looks sth like this: `https://codeberg.org/login/oauth/authorize?client_id=...&redirect_uri=https%3A%2F%2Fdiday.org%2Fadmin%2F&response_type=code&scope=repository&state=%7B%22auth_type%22%3A%22pkce%22%2C%22nonce%22%3A%22...` to `https://codeberg.org/login/oauth/authorize?client_id=...scope=only-public...` also leads to a successful login. However, i am not sure if it really has the desired effect of at least only granting the CMS only access to public repos. But i guess if it is implemented it should 🙃? I think we should monitor the progress in https://codeberg.org/forgejo/forgejo/issues/4052 or eventually get involved. But i haven't done anything in Go yet.

razze commented 2026年04月30日 12:11:05 +02:00

Getting the CMS we use to narrow down the scope to only public seems - unplausible. Ideally you want your CMS to also work with private repos, if you choose to? Can't we scope it to a specific repo?

We need https://forgejo.org/docs/next/user/token-scope/#specific-repositories

Getting the CMS we use to narrow down the scope to only public seems - unplausible. Ideally you want your CMS to also work with private repos, if you choose to? Can't we scope it to a specific repo? We need https://forgejo.org/docs/next/user/token-scope/#specific-repositories

nisrael commented 2026年05月16日 09:54:59 +02:00

@razze wrote in #120 (comment):

Getting the CMS we use to narrow down the scope to only public seems - unplausible. Ideally you want your CMS to also work with private repos, if you choose to? Can't we scope it to a specific repo?

Let's assume the specific repo scope would be available for OAuth2 (that seems at least possible for the future). That wouldn't help us because the repository the user needs to give access to doesn't exist at the time of the login. So for this to work the user has to create the fork manually.

Restricting the scope to public only would be an improvement, but the scope would still be too broad. And as you said it has the downside of not being able to change the fork visibility to private.

What about adding support for forgejo to https://github.com/netlify/git-gateway and codeberg as identity service with only read:user scope? The user content would then live in the main repo and we could work with protected branches to protect the main branch and the dev teams branches.

@razze wrote in https://codeberg.org/DI-Day/website/issues/120#issuecomment-14077490: > Getting the CMS we use to narrow down the scope to only public seems - unplausible. Ideally you want your CMS to also work with private repos, if you choose to? Can't we scope it to a specific repo? Let's assume the specific repo scope would be available for OAuth2 ([that seems at least possible for the future](https://codeberg.org/forgejo/forgejo/issues/4052#issuecomment-13787849)). That wouldn't help us because the repository the user needs to give access to doesn't exist at the time of the login. So for this to work the user has to create the fork manually. Restricting the scope to public only would be an improvement, but the scope would still be too broad. And as you said it has the downside of not being able to change the fork visibility to private. What about adding support for forgejo to https://github.com/netlify/git-gateway and codeberg as identity service with only read:user scope? The user content would then live in the main repo and we could work with protected branches to protect the main branch and the dev teams branches.

razze commented 2026年05月16日 18:01:55 +02:00

I think this should be talked through with the decapCMS people in a new issue. I would like to just set an additional scope and allow fork creation, but I can see other orgs, not wanting to do that and instead have decapCMS guide people through manual fork creation.

I think this should be talked through with the decapCMS people in a new issue. I would like to just set an additional scope and allow fork creation, but I can see other orgs, not wanting to do that and instead have decapCMS guide people through manual fork creation.