Hide users from public view

[demonpig]

• Gitea version (or commit ref): 1.2.3
• Git version: 2.15
• Operating system: CentOS
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

I think there should exist a config option to prevent the viewing of user accounts from public view. I have user accounts on my Gitea instance that I would not like others to see. This might be doable with templates but I am not sure at the moment.

[bkcsoft]

Define "viewing". Are you referring to listings like /explore/users? What about them commenting on public issues, do you want the comment hidden? Commiting to a public repo, should the commit not be shown?

(none of the two latter cases are doable in a sensible way by the way :) )

[lafriks]

I think this is meant for hiding from explore/users

[demonpig]

@bkcsoft Yes i am referring to /explore/users. To you the truth, I forgot all about this issue. I was able to resolve it by using a template.

To fully answer your question, I have the root user and other "read-only" users that I do not want shown on the /explore/users page. If they have no commits, then they are essentially hidden from public view. I want to prevent someone from logging in with the root or "read-only" users.

Note:

• By "read-only" I mean that I have accounts that have read-only access to repositories in my main Gitea account.

[techknowlogick]

@demonpig would you be able to post a gist of the custom template you are using?

[demonpig]

@techknowlogick Here you go.
The file is in: ${GITEA_HOME}/custom/templates/explore

{{template "base/head" .}}
<div class="explore users">
        {{template "explore/navbar" .}}
        <div class="ui container">
                Users not viewable.
        </div>
</div>
{{template "base/footer" .}}

[techknowlogick]

@demonpig thanks

[ruifung]

It would be nice to have, in addition to an option that hides all users from public view, to have an option to hide specific users from public view. Like the backup local accounts when you have ldap auth enabled =/.

[rmattes]

+1
I just encountered the same problem - the admin-only non-LDAP account is shown prominently on the landing page. This asks for "creative" login attempts ....

[OmarAssadi]

Yeah, this would be nice to have. For now, I've just had to 403 anyone who visits /explore/users via NGINX.

FWIW, looks like both the gitea and gogs community wants this.

gogs/gogs#5080
gogs/gogs#3248

[shuhaowu]

Denying access to /explore/users only doesn't solve the issue. Users still can be found via the API:

curl -X GET "http://gitea/api/v1/users/search" -H  "accept: application/json"

[OmarAssadi]

@shuhaowu Nice catch! Totally forgot to block access to that endpoint as well.

[ghost]

I'd love to see this so the admin user isn't so prominent.

[davidsiefert]

To clarify, is this issue with REQUIRE_SIGNIN_VIEW set to true or false?

[demonpig]

@davidsiefert I do not believe so. Basically, can there be a config option added that would prevent the root or all other user account from being shown from both the API and /explore/users endpoints? Maybe Gitea could be configured/developed in a way where it only shows users that have made commits?

[mcnesium]

…or those who opt-in to be published.

[Spenhouet]

This would be a important feature for us. Users should not be able to see other users.

[MasterDimmy]

+1 request for hiding users from others except admin (add rights flag)

[lafriks]

How would that be handled in API?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[MasterDimmy]

Still wanted...

[lion187chen]

It will be great that do not show users who have no public repo

[zeripath]

I see a lot of comments on here but no spec or proposals for how it is configured.

A sensible configuration that could keep the current system and offer the proposed restricted views would likely lead to implementation.

For example, a suggested configuration block:

[explore.users]
REQUIRE_SIGNED_IN=false ; set to true to only allow signed in users to see this page
ONLY_SHOW_USERS_WITH_PUBLIC_REPOS=false ; set to true to only show users with public repos
...

and so on.

Then it would simple to implement.

[martinum4]

@zeripath the approach laid out by you seem reasonably to me and should cover most cases of exposed information, if the implemented config changes affect the API-Access too.

[fluboi]

From our side we think this issue is a serious security issue.

Gitea leaks critical personals information: First Name, Last Name, login, email, creation date (when they joined our organization).

In our case, Gitea use LDAP authentication and basically leaks all our members information, without any way to limit/stop that leak.

REQUIRE_SIGNIN_VIEW is not usable as it breaks public repositories. Blocking /api/v1/users/search endpoint breaks the ability to add a user to a repository.

It would be really appreciated to have at least a way to limit the leak to authenticated users.

[6543]

@fluboi for now you could limit API access to authenticated users

EDIT: look's like there is no setting for API only :/

[zeripath]

It's beyond disappointing to see people repeatedly comment on this issue without offering a spec or proposed configuration, or commenting on the deficiencies or improvements to my proposed spec here: (#2908 (comment))

If there had been more response and consideration to my comment working together about what was necessary and what would work this would have been implementable months ago.

As it stands I've proposed a PR to close this but I don't know if it is sufficient.

[fluboi]

Thanks for your work @zeripath and sorry for my previous disappointing comment.
From what I understand your PR meets our needs.
Thanks again

[theAkito]

If there had been more response and consideration to my comment working together

I think the reason is not laziness or malicious intent, but rather the lack of understanding the backend and maybe even the language it is written in. As far as I have seen, most people here do not have any idea about Go, as they are just users of this server and not developers.
I cannot speak too much about all these people I don't know, but I can speak for myself:
I do not understand the Gitea backend and I do not want to get involved with Go, because I do not like the language and there are tons of Go programmers out there already, anyway, so no need to do another thing in life, unnecessarily. For example, if the backend were written in Nim I would be willing to happily contribute, maybe even fix this issue myself, as Nim is actually fun and pure enjoyment, while Go is pure chore and annoyance, to me personally. However, if that were the case, probably all of the current contributers would leave, because they rather stay with Go.

I also think, it does not make a lot of sense for people adding random ideas regarding the implementation, if they have no idea about the backend's structure and/or the language. It's probably best, if those most knowledgable decide on the implementation, especially regarding security-oriented features, that usually are important be to implemented correctly and not necessarily beautifully.

Of course, this is an open source project and you or any other contributer does not have any obligation to implement anything, except maybe for big sponsors, who only sponsor so much for these benefits. I think we all understand that.
However, people here chime in, explaining their issue, emphasizing the importance of it, in the hopes that Gitea leadership will address this issue ASAP, instead of so many other issues in this repository that are instead being addressed. So all the people here are asking for, is not to do more work, but just to change the focus of issues. Simply: throw away another issue and instead solve this one.

That's why I think it is valid to chime in here, emphasizing the importance of this issue, even if that person posting a comment has no time, interest or simply not the knowledge to help with the implementation. Most people here are just users, as I am too.

[pierre-alain-b]

I think the reason is not laziness or malicious intent, but rather the lack of understanding the backend and maybe even the language it is written in. As far as I have seen, most people here do not have any idea about Go, as they are just users of this server and not developers.

I cannot agree more. I am a developer but not in Go and I have not taken the time to familiarize with the base code and the way the application works so it would certainly be counterproductive to comment on the implementation and then I only relayed my user need!
But I REALLY appreciate the work done (maintaining other open source projects, I know it is not an easy task and users' feedback is not always the one you would expect!).

[lafriks]

Please keep to the topic, if you do not have anything to add about specific issue please do not comment.

Just a side note and let's hope end of this off-topic discussion: none of Gitea contributors get paid for developing new features or fixing bugs, we all do that in our spare time, so unless someone is willing to sponsor specific feature or development, everyone including Gitea contributors are free to develop whatever they like and Gitea "leadership" does not have say on what other contributors need to do when they are devoting their free time for this project developing features they need or have fun doing.

[DuckDuckWhale]

Continuing the discussion on the proposed configuration:

For example, a suggested configuration block:

[explore.users]
REQUIRE_SIGNED_IN=false ; set to true to only allow signed in users to see this page
ONLY_SHOW_USERS_WITH_PUBLIC_REPOS=false ; set to true to only show users with public repos
...

Does the configuration proposed here hide the user in the API as well as the explore users page (considering that it is a [explore.users] config block)? What happens if they type in the link to the user profile page manually, should they be assessed as normal, return a 404 not found, a 401 unauthorized, or a 403 forbidden? Should Gitea ignore this configuration and show users without public repos to other users who are logged in?

For comments in public repos by users without public repos, I think it would be a good idea to leave them be, for that hiding comments in discussions on public repos would break up the context and confuse late comers. This is justified because users are making the conscious decision to make that comment public when they comment on a public repo, and were a private repo went public they still have the ability to delete comments that they prefer not to be seen.

If there are no obvious answers for the other questions I think adding configuration options for them would be a good idea, i.e. something along the lines of:

[privacy]
HIDE_USERS_WITHOUT_PUBLIC_REPOS_FROM = none/visitors/users
HIDE_USERS_WITHOUT_PUBLIC_REPOS_IN = api, profile

Where if users is set nobody will see them except admins, if visitors is set only non-users (visitors who are not logged in) won't see them, if api is set they will be hidden in API calls to users if users is set, to visitors if visitors or users is set, except public activities on public repos and if caller is an admin, and if profile is set their profile page will be hidden accordingly as well. (This is a very rough idea though and might need adjusting.)

[DuckDuckWhale]

After giving it some more thought the HIDE_USERS_WITHOUT_PUBLIC_REPOS_IN might not be necessary. Hiding them in API should be consistent with the Explore page (Otherwise what's the point?) and always exposing the profile page wouldn't hurt that much. There could be a user setting called Hide profile for those who want to hide if their accounts exists at all though. That setting could hide the profile of a user as long as they don't have any public repos.

[Mar-Veloz]

It seems to me that the intractability of this issue comes in large part from the fact that hiding a user is fundamentally at odds with the inherently social nature of commenting, forking/merging, sharing repos, etc. So there end up being a lot of edge cases and interactions that need to be accounted for. From that point of view, the lack of progress on the issue is to be expected, since we've been demanding a square peg to plug this round hole.

I propose it might be better to sidestep the issue entirely by adding the ability to define some sort of admin-only login that can access the admin panel but isn't an actually existing user as far as having a profile, repos, ability to make comments, etc is concerned. This wouldn't address every single situation where someone might want to hide a user, but would address the most glaring security flaw and the situation that's been mentioned most often in this thread: having an admin user that is unnecessarily exposed for all the world to see.

[theAkito]

It seems to me that the intractability of this issue comes in large part from the fact that hiding a user is fundamentally at odds with the inherently social nature of commenting, forking/merging, sharing repos, etc. So there end up being a lot of edge cases and interactions that need to be accounted for. From that point of view, the lack of progress on the issue is to be expected, since we've been demanding a square peg to plug this round hole.

Does not sound like a good argument. You could argue precisely the same way about private repositories. Nobody can contribute to or even see them, without having been given explicit permission by the owner. Yet, private repositories are one of the most normal Git things in the world.
A hidden user is in this context nothing much different, than a private repository. It exists, but you cannot see or interact with it. Nothing is new about that and nothing should disrupt the inherently social nature of how Git is most of the time used.

I propose it might be better to sidestep the issue entirely by adding the ability to define some sort of admin-only login that can access the admin panel but isn't an actually existing user as far as having a profile, repos, ability to make comments, etc is concerned. This wouldn't address every single situation where someone might want to hide a user, but would address the most glaring security flaw and the situation that's been mentioned most often in this thread: having an admin user that is unnecessarily exposed for all the world to see.

This is just one specific approach to make a tiny minimal feature that coincidentally features a type of user hiding. For example, this feature would not solve any of my problems and would be utterly useless on my setup.

Due to the aforementioned reasons, I cannot agree, at all.

[Mar-Veloz]

A hidden user is in this context nothing much different, than a private repository. It exists, but you cannot see or interact with it.

The difference is a repository is passive, whereas a user is active. A user can not only be interacted with, but can also itself interact with others. For example: what happens if a hidden user pushes to, submits a bug report for, or comments on an issue in a public repository? Should the contribution be shown to everyone? Only to users who have permission to see the hidden user? Something else? These questions are nontrivial to answer, and even less trivial to implement an answer for. My idea is simply that the easiest solution is to just not allow hidden users to actively interact with others at all.

This is just one specific approach to make a tiny minimal feature that coincidentally features a type of user hiding.

In retrospect, I agree that the idea of an admin-only login was overly limited. A hidden user could, for example, still want to have repos of their own, or not necessarily have to be an admin. My point is more that (at least, the way I see it) the easiest solution to the question of hidden users interacting with non-hidden users is to simply not allow hidden users to interact with other users (though it should still be fine, in theory, to allow hidden users to be interacted with).

[theAkito]

For example: what happens if a hidden user pushes to, submits a bug report for, or comments on an issue in a public repository? Should the contribution be shown to everyone? Only to users who have permission to see the hidden user? Something else

Very good points!

My idea is simply that the easiest solution is to just not allow hidden users to actively interact with others at all.

the easiest solution to the question of hidden users interacting with non-hidden users is to simply not allow hidden users to interact with other users (though it should still be fine, in theory, to allow hidden users to be interacted with)

I think that would be a good workaround (solution?).

A hidden user could, for example, still want to have repos of their own, or not necessarily have to be an admin.

Indeed, this is for example the scenario in my case. I have a couple of shadow accounts, that are only used for very specific purposes. Unfortunately, they make the "Explore" landscape on the platform uglier.

[art-ist]

Denying access to /explore/users only doesn't solve the issue. Users still can be found via the API:

curl -X GET "http://gitea/api/v1/users/search" -H  "accept: application/json"

… and

curl -X GET "http://gitea/api/v1/users/joe" -H  "accept: application/json"

was our first guess. So restricting http://gitea/api/v1/users would be required. What else?

[zeripath]

That will break other things and is pointless because you can simply go to /joe

---

Actually I miswrote it looks like I'm incorrect and this API is not used in the UI (I'm not certain why I didn't include it originally - perhaps it was previously(?))

It's still a little pointless as you can simply go to /joe but I will add it.

[mvdkleijn]

If I might offer an alternative proposal...? Assumption: the purpose of any "hidden user" feature of this kind is for the sole purpose of having "administrative" users that can be used to admin a Gitea instance or perform backups, etc...

Option 1

• Any user with the "is admin" flag set will be excluded from any API results and from any lists in the UI
• Only other users with the "is admin" flag can see those kinds of users through UI or API

Option 2

• Similar to option 1 except:
• User has a "allow listing" flag that can only be set by an admin
• User is not show to anyone except admins

[noerw]

Please note that there are two proposed implementations for this ready: #13687 #14094
It'd be more helpful to discuss these than proposing even more possibilities ;)

---

I'll make a start: I think #14094 is a very good first fix, as the behaviour will be strict enough to make most people happy.
However, the proposed settings are not very flexible in giving single users control, which could be added in a followup PR.

To do that, I'd change the DISABLE_USERS_PAGE bool flag to a USERS_PAGE setting allowing for more states, initially 2:

• OPT_OUT: default, essentially the current behaviour. opt-out functionality for single users would be added in the future.
• DISABLED: the same as the proposed DISABLE_USERS_PAGE = true

.. and in a later PR the following could be added for more flexibility:

• OPT_IN: newly created users would set the (newly created) explore_listing per-user setting to false, and thus not show up

Opt-in is gives users more control than ONLY_SHOW_USERS_WITH_PUBLIC_REPOS and still allows for the similar usecases.
[ui.explore] USERS_PAGE would still be in addition to [ui.explore] REQUIRE_SIGNIN_VIEW, though that's not necessary for USERS_PAGE to be useful

[theAkito]

@zeripath

I think the PR is a good beginning but I am convinced it is not enough to close this issue.

To close this issue, we need something more advanced. See above discussion.

Actually, I read the OP of this issue and apparently the closing is justified. Perhaps it is best to create a new issue for more advanced permission features.

Nonetheless, I think we all owe you a big thank you for your PR.