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 :) )

I think this is meant for hiding from explore/users

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

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

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

@demonpig thanks

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 =/.

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

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.

https://github.com/gogits/gogs/issues/5080
https://github.com/gogits/gogs/issues/3248

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"

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

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

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

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

…or those who opt-in to be published.

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

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

+1

How would that be handled in API?

+1

+1

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.

Still wanted...

Yes. Definitely still wanted.

temp solution (just hides the options from views) for those in a hurry here: https://github.com/gogs/gogs/issues/5080#issuecomment-482657310

for those in a hurry here: gogs/gogs#5080

@miqmago how it prevents from manually type "/explore/users" in the browser?
I guess that patching of routes.go (around https://github.com/go-gitea/gitea/blob/master/routers/routes/routes.go#L247 ) is mandatory, isn't it?

Also, the #6530 was resolved as duplicate.
But I would like to stress, that having private organization feature released, but with possibility to expose every users even from any private organization should be treated as a security hole :wink:

Is it possible to escalate this issue into 1.8.1 branch?

Not a security hole, as the acceptance criteria was never to hide users that are a part of hidden orgs. That’s what this ticket is for.

Not a security hole

Ok :)

But could the criteria to hide users from one private organization to other orgs be added? May be optionally.
Or at least optional blocking of "/explore/users" route and accordant template...
I'd happy to see it in 1.8.x. Sorry, my current skills in Go are not enough to contribute some PR :(

@igsol you're right, I've updated the thread so now it's only accessible by admin users right now.

In my point of view, that should be something configurable at user admin dashboard. I also think this is quite complex and I'm not aware of all the proposed solutions. For sure there are multiple scenarios: permission to see all users from an organization the user belongs to, to see all users, to only see themselves, public users...

@techknowlogick don't know if this is the right place to discuss it and where can I find more info about it, but I've read that this is a gogs fork mantained by community. Not sure about the differences with gogs, how integrates new features developed on gogs and why should I migrate to gitea or stick to gogs, pros and cons. Maybe you could point me somewhere to get more info. Also to say that I'm not an experienced programmer on go, but I could somehow contribute too, i.e. I'm working on catalan translations.

@miqmago Here is a helpful comparison on what Gitea vs Gogs offers: https://docs.gitea.io/en-us/comparison/ as well as the launch blog post explaining about the differences in governance of the projects: https://blog.gitea.io/2016/12/welcome-to-gitea/

@igsol this ticket won't make it into a 1.8.x release due to the project only backporting bug fixes, we are currently working on getting 1.9.x out.

currently working on getting 1.9.x out.

@techknowlogick Ok, I see, NP.

So far I helped myself by making local private build applying my quite brutal patch (something like @miqmago mentioned, but simpler). The main thing is to implement this ticket at the end :)

Anyway thanks to all the team for brilliant Gitea.

1.9.0 is released. Is there a chance to draw attention to this ticket?

@igsol
This is my wish, as well.

Would this help?

https://github.com/go-gitea/gitea/pull/8340

Would this help?

8340

Wouldn't this hide all users from public view?

Only if REQUIRE_SIGNIN_VIEW is true and you are not logged in.

Only if REQUIRE_SIGNIN_VIEW is true and you are not logged in.

If REQUIRE_SIGNIN_VIEW is true, it is hidden anyway. Secondly, it would still hide all users, which is not the point of the request. Especially, since some users only want to hide a single user and I think it would be a little overkill if you would hide ALL users ever created just because of 1 system account.

Okay, Sorry.

So can we please update the Issue.

What is wanted?

a new config: ALLOW_VIEW_USERS ?

What is wanted?

Ideally from my personal point of view, I would wish for a setting that each user can set like this:

...
Hide account from public view [ ]
...

Which would be inbetween other settings like _Hide e-mail address_.

It would also be fine to include it into admin settings, though I think making everyone able to decide is the best solution.

If this is to be implemented, all repositories from that user should become private, which is a non-trivial change IMHO. For example, forked repositories are required to be public if the source repository is public, so the user's existence will be exposed eventually.

If this is to be implemented, all repositories from that user should become private, which is a non-trivial change IMHO. For example, forked repositories are required to be public if the source repository is public, so the user's existence will be exposed eventually.

Ideally, this way should be optional. I see use cases where you just want to _unlist_ (like _unlisted_ videos on YouTube) a user, which means you don't want this user to be displayed prominently as if he were the king of your Gitea but you wouldn't have an issue if he was hidden somewhere in the jungle of your Gitea. This example is true for my instance.

Ideally, this way should be optional. I see use cases where you just want to _unlist_ (like _unlisted_ videos on YouTube) a user, which means you don't want this user to be displayed prominently as if he were the king of your Gitea but you wouldn't have an issue if he was hidden somewhere in the jungle of your Gitea. This example is true for my instance.

But then this issue should be titled "Unlist some users in Gitea". 😁

Ideally, this way should be optional. I see use cases where you just want to _unlist_ (like _unlisted_ videos on YouTube) a user, which means you don't want this user to be displayed prominently as if he were the king of your Gitea but you wouldn't have an issue if he was hidden somewhere in the jungle of your Gitea. This example is true for my instance.

But then this issue should be titled "Unlist some users in Gitea". 😁

I think the most accurate title would be "Hide or Unlist users". Providing both options would be a great solution.

These features should also be available for organizations, of course.

+1 for hide (all) users when i'm not login, explorer + API, but, when i'am login, i want see (all) users.

I use MariaDB.
With users.tmpl i can't apply what i want, because, when i'am logging i can't see the users too.
The API can always list all users.

I need display user from public view, but, not all user.

cd /etc/gitea
nano app.ini
REQUIRE_SIGNIN_VIEW: true
Work very well ! But, this option was extrem !
The security aspect is now respected, but we would prefer to be able to choose whether to be visible or not, as a public or private user.

+1, we need to hide ExplorerUser tab OR choosing which user (local or ldap) should be listed in ExplorerUser list ... it's easy to retrieve user login then bruteforce them ... or anything else
Thank you for this wonderful tool., gitea

REQUIRE_SIGNIN_VIEW = true

Seems to do the trick.

@Braqoon You did not read the conversation. It does not "do the trick".

Would be great if this could be implemented.
I want to expose some of my (public) repos to peeps who are not registered to my gitea instance, but I do not want to show them all of my registered users (including admin). As @theAkito mentioned, simply REQUIRE_SIGNIN_VIEW = true does not fix the problem.

Edit:
Even worse, I just checked the API-Call curl -X GET "http://gitea/api/v1/users/search" -H "accept: application/json" as mentioned by @shuhaowu. Even non registered Users can easily figure out critical information such as is_admin or last_login. Security-wise, this is an absolute no-go.

I totally agree it would be very useful to possibly hide users that have no public repo. Let's say I add some users to comment on issues on private projects, it would be perfect if they could be made invisible in the explore list!

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

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.

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

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.

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

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

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: (https://github.com/go-gitea/gitea/issues/2908#issuecomment-670616617)

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.

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

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.

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!).

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.