Allow anonymous access to some but not all repositories?

[zwets]

Is my understanding correct that it is not currently possible to make certain repositories accessible to anonymous users, and others to logged-in users only?

I am aware of REQUIRE_SIGNIN_VIEW = true to disallow anonymous access, however this then applies to all repositories. My preferred model would be to have repositories visible to all logged-in users (by default, and can then be restricted by the owner), but not to anonymous users (by default, and can then be "opened up" by the owner).

My impression is that there is currently no way to do this in Gogs, but I may be overlooking something?

@unknwon thank you for such a brilliant product!

[unknwon]

Is my understanding correct that it is not currently possible to make certain repositories accessible to anonymous users, and others to logged-in users only?

You're correct that this is currently not possible.

[zwets]

Thanks @unknwon. Has any issue already been opened that requests this feature? I would be happy to contribute to the idea generation or design, or (with some effort, as go isn't my first language) to the coding.

Off the cuff, I'd imagine repos and orgs having an "allow access to ..." setting with three options: "anyone", "logged-in users", "restricted". The "restricted" option would then present a selectable list of users and groups. This permission grants read access to the contents of the repository. At the org level, the setting constrains the "maximum" access to any contained repository, i.e. the access list at the repo level is intersected with that at the org level to get the effective access list.

A separate setting "list for ..." would cater for "unlisted repositories" (as added in #6176). This setting would offer the same options and share the list of "restricted" users and groups with the read access setting. Its default value could be "anyone" (so anyone can find out which repos are available, even if they don't have access to their content). However the "list for" could be set either "wider" or "tighter" than the read access, so that a user could see a listed repo but have no access, or not see the repo but still clone it.

Write- and admin/owner-permissions are mostly a separate topic, though in principle simpler: they'll only have the explicitly selected list of users and groups who are granted the permission, and this selection must always be intersected with those who have read access (revoking read access implies revoking write access).

Finally, regarding users and groups, I've always been confused about the "People" and "Teams" on the organisation level: what are they for, and how do they relate to the "Collaborators" on the repo level? Why can't I select a Team as collaborators on a repo, or use teams across organisations?

My use case would be that (entirely independent from orgs and repos) I could define named groups of users ("Groups", or "Teams") and assign these, along with individual users, to specific permissions such as "read this repo" or "admin this org". This doesn't need to go all RBAC (no need for a configurable "roles" layer, we know the roles beforehand) but would give just the right flexibility.

I bet this has been thought about before ... where is it stuck? :-)

[unknwon]

I think this is the issue: #2308