Restricted Users cannot see Public Repos/Orgs...

[meln5674]

Description

...unless they use a super obscure cyber intrusion technique: Logging out.

This is tremendously silly. This feels like a "unstoppable force vs immovable object" problem, these two concepts are mutually contradictory.

Gitea Version

1.24.6

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

N/A

Database

None

[wxiaoguang]

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

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

[meln5674]

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".

[wxiaoguang]

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"?

[meln5674]

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?"

[wxiaoguang]

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?

• Add descriptions for private repo public access settings and improve the UI #34057 (comment)

---

And yes, I agree that there are design problems in the "restricted" user feature, there are still other discussions about it (for example: #35550 (comment))

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]

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]

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]

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)

[lunny]

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.

[wxiaoguang]

That's also my worry #35690 (comment)

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.

[meln5674]

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.

[wxiaoguang]

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.

[lafriks]

So yes, I blocked because in mode when loggin required mode is set to true limited/guest users should not see public repos, only ones that they have added rights to access