Restricted Users cannot see Public Repos/Orgs... #15032

@wxiaoguang commented on GitHub (Oct 17, 2025):

Usually "restricted user" is used with other options like "require sign-in".

If you don't need it, then don't set it.

@wxiaoguang commented on GitHub (Oct 17, 2025): Usually "restricted user" is used with other options like "require sign-in". If you don't need it, then don't set it.

GiteaMirror commented

@meln5674 commented on GitHub (Oct 17, 2025):

If you don't need it, then don't set it.

Yes, however, I do need to restrict some users, but public repos are intended to be just that: public. I could make same argument, i.e. "If you don't want restricted users to see your repo, make it limited".

@meln5674 commented on GitHub (Oct 17, 2025): > If you don't need it, then don't set it. Yes, however, I do need to restrict some users, but public repos are intended to be just that: public. I could make same argument, i.e. "If you don't want restricted users to see your repo, make it limited".

GiteaMirror commented

@wxiaoguang commented on GitHub (Oct 18, 2025):

If you don't need it, then don't set it.

Yes, however, I do need to restrict some users, but public repos are intended to be just that: public. I could make same argument, i.e. "If you don't want restricted users to see your repo, make it limited".

However, there are are a lot of "options" or "methods" to "restrict" users. I could also argue that "if you want to restrict some users, use a proper approach".

So, the question is: what's your requirement? How to "restrict" or "limit"?

@wxiaoguang commented on GitHub (Oct 18, 2025): > > If you don't need it, then don't set it. > > Yes, however, I do need to restrict some users, but public repos are intended to be just that: public. I could make same argument, i.e. "If you don't want restricted users to see your repo, make it limited". However, there are are a lot of "options" or "methods" to "restrict" users. I could also argue that "if you want to restrict some users, use a proper approach". So, the question is: what's your requirement? How to "restrict" or "limit"?

GiteaMirror commented

@meln5674 commented on GitHub (Oct 18, 2025):

I run a multi-tenant Gitea instance that is only accessible internally. There is a desire to host a second instance which is externally accessible, which hosts repos that are publicly accessible, as well as those that are private to both internal users and a limited handful external users. The desire is for there to be repos that are both publicly accessible, those which require explicitly adding users. The restricted user feature was desirable because it enabled us to create repos which explicitly require adding external users, while being globally accessible to internal users. Making external users restricted would also be defense-in-depth for a repo accidentally being marked as limited instead of private.

Obviously, I can just not use the feature, and use some other approach like requiring explicitly adding all users for private repos, and disallow limited repos, or maybe running a third instance for these special repos, or using other software entirely.

My point in opening this issue is that the behavior is surprising and unintuitive, and will provides additional headaches to users who we will then have to explain that the tool that we're using won't let them see certain content if they are logged in, which doesn't exactly reflect well on either us or Gitea for that matter, which doesn't feel great since I generally prefer to support and give exposure to well-maintained FOSS projects if I can.

If the restricted user feature is only sensible to be used when public repos are disallowed, I would expect it to only be usable when that's the case, or for there to at least be some sort of UI element in the user creation/configuration page that says "this doesn't do what you think it does, see this FAQ link" if public repos are enabled. Everyone I have shown this to (about a dozen people so far) within my org has said something to the effect of "Really? Is that a bug?"

@meln5674 commented on GitHub (Oct 18, 2025): I run a multi-tenant Gitea instance that is only accessible internally. There is a desire to host a second instance which is externally accessible, which hosts repos that are publicly accessible, as well as those that are private to both internal users and a limited handful external users. The desire is for there to be repos that are both publicly accessible, those which require explicitly adding users. The restricted user feature was desirable because it enabled us to create repos which explicitly require adding external users, while being globally accessible to internal users. Making external users restricted would also be defense-in-depth for a repo accidentally being marked as limited instead of private. Obviously, I can just not use the feature, and use some other approach like requiring explicitly adding all users for private repos, and disallow limited repos, or maybe running a third instance for these special repos, or using other software entirely. My point in opening this issue is that the behavior is surprising and unintuitive, and will provides additional headaches to users who we will then have to explain that the tool that we're using won't let them see certain content if they are logged in, which doesn't exactly reflect well on either us or Gitea for that matter, which doesn't feel great since I generally prefer to support and give exposure to well-maintained FOSS projects if I can. If the restricted user feature is only sensible to be used when public repos are disallowed, I would expect it to only be usable when that's the case, or for there to at least be some sort of UI element in the user creation/configuration page that says "this doesn't do what you think it does, see this FAQ link" if public repos are enabled. Everyone I have shown this to (about a dozen people so far) within my org has said something to the effect of "Really? Is that a bug?"

GiteaMirror commented

@wxiaoguang commented on GitHub (Oct 18, 2025):

Not quite sure how many repos you need "external users" to access.

Maybe the new feature like Public Access could work better for your case?

https://github.com/go-gitea/gitea/pull/34057#issuecomment-2763257315

And yes, I agree that there are design problems in the "restricted" user feature, there are still other discussions about it (for example: https://github.com/go-gitea/gitea/pull/35550#issuecomment-3357082925)

So as "open-source" and "crowd-contributed", many features were written without careful design. And I am not the author of "restricted user" feature, so I have no knowledge about its history.

Since I am maintaining the code, I think I need to figure out all use cases before making changes to it, to avoid introduce more design problems.

Thank you very much for the details!

@wxiaoguang commented on GitHub (Oct 18, 2025): Not quite sure how many repos you need "external users" to access. Maybe the new feature like Public Access could work better for your case? * https://github.com/go-gitea/gitea/pull/34057#issuecomment-2763257315 ----- And yes, I agree that there are design problems in the "restricted" user feature, there are still other discussions about it (for example: https://github.com/go-gitea/gitea/pull/35550#issuecomment-3357082925) So as "open-source" and "crowd-contributed", many features were written without careful design. And I am not the author of "restricted user" feature, so I have no knowledge about its history. Since I am maintaining the code, I think I need to figure out all use cases before making changes to it, to avoid introduce more design problems. Thank you very much for the details!

GiteaMirror commented

@wxiaoguang commented on GitHub (Oct 18, 2025):

The "restricted user" feature is from #6274 (also cc @mnsh @lafriks @6543), maybe the authors and reviewers can have more thoughts about it, and let's see how to improve it.

@wxiaoguang commented on GitHub (Oct 18, 2025): The "restricted user" feature is from #6274 (also cc @mnsh @lafriks @6543), maybe the authors and reviewers can have more thoughts about it, and let's see how to improve it. <img width="1880" height="742" alt="Image" src="https://github.com/user-attachments/assets/75096fcc-427f-4999-a285-e7c7b207dd20" />

GiteaMirror commented

@wxiaoguang commented on GitHub (Oct 18, 2025):

Although I haven't got enough background knowledge, I think if we'd like to break the legacy behavior, maybe we can do this:

Make restricted users can access public repositories #35693

Reviewing & testing are welcome.

If you can build your own binary/instance, feel free to try and report problems if there is any. Thank you.

@wxiaoguang commented on GitHub (Oct 18, 2025): Although I haven't got enough background knowledge, I think if we'd like to break the legacy behavior, maybe we can do this: Make restricted users can access public repositories #35693 Reviewing & testing are welcome. If you can build your own binary/instance, feel free to try and report problems if there is any. Thank you.

GiteaMirror commented

@wxiaoguang commented on GitHub (Oct 18, 2025):

If the restricted user feature is only sensible to be used when public repos are disallowed, I would expect it to only be usable when that's the case, or for there to at least be some sort of UI element in the user creation/configuration page that says "this doesn't do what you think it does, see this FAQ link" if public repos are enabled. Everyone I have shown this to (about a dozen people so far) within my org has said something to the effect of "Really? Is that a bug?"

After reading more code and documents .... I found that it is a designed behavior , also included in document, and tests https://docs.gitea.com/help/faq?_highlight=restric#restricted-users

TBH, I am not sure whether we should change the behavior, although the new behavior (restricted users can see public repos) also look better to me .

So in the end, I think either:

Add more messages on the Admin UI
Change the behavior and change the documents (also add some messages on the UI)

@wxiaoguang commented on GitHub (Oct 18, 2025): > If the restricted user feature is only sensible to be used when public repos are disallowed, I would expect it to only be usable when that's the case, or for there to at least be some sort of UI element in the user creation/configuration page that says "this doesn't do what you think it does, see this FAQ link" if public repos are enabled. Everyone I have shown this to (about a dozen people so far) within my org has said something to the effect of "Really? Is that a bug?" After reading more code and documents .... I found that it is a designed behavior , also included in document, and tests https://docs.gitea.com/help/faq?_highlight=restric#restricted-users <details> <img width="1036" height="230" alt="Image" src="https://github.com/user-attachments/assets/d2124df8-b9b0-4c0c-9a92-36b798755c11" /> <img width="1782" height="604" alt="Image" src="https://github.com/user-attachments/assets/85534195-5345-4a23-aee4-9d52cede747c" /> </details> TBH, I am not sure whether we should change the behavior, although the new behavior (restricted users can see public repos) also look better to me . So in the end, I think either: * Add more messages on the Admin UI * Change the behavior and change the documents (also add some messages on the UI)

GiteaMirror commented

@lunny commented on GitHub (Oct 18, 2025):

Public repositories in login required mode could be think as some kind of internal repositories. So that, maybe the restrict's definition is different between login required and no login required modes. That means restricted user can visit public repos in non login required mode but cannot visit public repositories in login required mode. Then I think it will be more compatible as the previous behavior.

@lunny commented on GitHub (Oct 18, 2025): Public repositories in login required mode could be think as some kind of internal repositories. So that, maybe the restrict's definition is different between login required and no login required modes. That means restricted user can visit public repos in non login required mode but cannot visit public repositories in login required mode. Then I think it will be more compatible as the previous behavior.

GiteaMirror commented

@wxiaoguang commented on GitHub (Oct 18, 2025):

That's also my worry https://github.com/go-gitea/gitea/issues/35690#issuecomment-3416523177

Maybe it's even better to disable the "restricted user" option when require-sign-in=false, or make these two work together for various different cases.

At the moment, these two options just cause unclear edge cases.

@wxiaoguang commented on GitHub (Oct 18, 2025): That's also my worry https://github.com/go-gitea/gitea/issues/35690#issuecomment-3416523177 Maybe it's even better to disable the "restricted user" option when require-sign-in=false, or make these two work together for various different cases. At the moment, these two options just cause unclear edge cases.

GiteaMirror commented

@meln5674 commented on GitHub (Oct 18, 2025):

I don't think public repositories even make sense when sign-in is required. The point of a public repository is that you can see it without logging in, would it not make more sense to just have a feature to disallow public repos for that case? I think the current levels of public/limited/private cover the spectrum of use cases well, but maybe admins should be able to enable them selectively. Who knows, maybe there's a valid use case for disabling private repos? Restricted users then become a special case of user where limited actually means private, which is useful for third-parties, which is exactly the use case outlined in the FAQ.

@meln5674 commented on GitHub (Oct 18, 2025): I don't think public repositories even make sense when sign-in is required. The point of a public repository is that you can see it without logging in, would it not make more sense to just have a feature to disallow public repos for that case? I think the current levels of public/limited/private cover the spectrum of use cases well, but maybe admins should be able to enable them selectively. Who knows, maybe there's a valid use case for disabling private repos? Restricted users then become a special case of user where limited actually means private, which is useful for third-parties, which is exactly the use case [outlined in the FAQ](https://docs.gitea.com/help/faq?_highlight=restricte#restricted-users).

GiteaMirror commented

@wxiaoguang commented on GitHub (Oct 18, 2025):

At the moment, I can see 2 cases:

Your case: REQUIRE_SIGNIN_VIEW=false, need to allow restricted users to see public repositories.
PR 6274's case: REQUIRE_SIGNIN_VIEW=true, then there are some public repositories for internal use. Need to limit the restricted users only to see their own ones but not the "internal public ones"

I think my PR #35693 should have addressed these two use cases, and "make these two work together for various different cases" properly.

@wxiaoguang commented on GitHub (Oct 18, 2025): At the moment, I can see 2 cases: * Your case: REQUIRE_SIGNIN_VIEW=false, need to allow restricted users to see public repositories. * PR 6274's case: REQUIRE_SIGNIN_VIEW=true, then there are some public repositories for internal use. Need to limit the restricted users only to see their own ones but not the "internal public ones" I think my PR #35693 should have addressed these two use cases, and "make these two work together for various different cases" properly.

GiteaMirror commented