定义“观看”。 你指的是像/explore/users吗？ 他们对公共问题发表评论怎么样，你想隐藏评论吗？ 提交到公共存储库，不应该显示提交吗？

（顺便说一句，后两种情况都不能以明智的方式可行:)）

我认为这是为了躲避explore/users

@bkcsoft是的，我指的是/explore/users 。 说实话，我忘记了这个问题。 我能够通过使用模板来解决它。

为了完全回答您的问题，我有不想在/explore/users页面上显示的 root 用户和其他“只读”用户。 如果他们没有提交，那么他们基本上是隐藏在公众视野之外的。 我想阻止某人以 root 或“只读”用户登录。

笔记：

• “只读”是指我的主要 Gitea 帐户中的帐户具有对存储库的只读访问权限。

@demonpig您能否发布您正在使用的自定义模板的要点？

@techknowlogick给你。
文件位于： ${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谢谢

除了在公共视图中隐藏所有用户的选项之外，如果有一个选项可以从公共视图中隐藏特定用户，那就太好了。 就像启用 ldap auth 时的备份本地帐户 =/。

+1
我刚刚遇到了同样的问题 - 仅限管理员的非 LDAP 帐户显示在登录页面的显着位置。 这要求“创造性的”登录尝试......

是的，有这个就好了。 现在，我只需要 403 任何通过 NGINX 访问/explore/users人。

FWIW，看起来 gitea 和 gogs 社区都想要这个。

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

仅拒绝访问 /explore/users 并不能解决问题。 仍然可以通过 API 找到用户：

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

@shuhaowu好收获！ 也完全忘记了阻止对该端点的访问。

我很想看到这个，这样管理员用户就不会那么突出了。

澄清一下，这个问题是REQUIRE_SIGNIN_VIEW设置为true还是false ？

@davidsiefert我不这么认为。 基本上，是否可以添加一个配置选项来阻止从 API 和/explore/users端点显示 root 或所有其他用户帐户？ 也许 Gitea 可以以仅显示已提交用户的方式进行配置/开发？

......或那些选择加入的人。

这对我们来说将是一个重要的功能。 用户应该无法看到其他用户。

+1 请求对除管理员以外的其他人隐藏用户（添加权限标志）

+1

这将如何在 API 中处理？

+1

+1

此问题已自动标记为陈旧，因为它最近没有活动。 如果在接下来的 2 周内没有进一步的活动，它将关闭。 感谢你的贡献。

还想要...

是的。 肯定还是要的。

临时解决方案（只是隐藏视图中的选项）对于那些赶时间的人： https :

对于那些赶时间的人：gogs/gogs#5080

@miqmago如何防止在浏览器中手动输入“/explore/users”？
我想对 routes.go 打补丁（在 https://github.com/go-gitea/gitea/blob/master/routers/routes/routes.go#L247 附近）是强制性的，不是吗？

此外，#6530 被解析为重复。
但我想强调的是，发布了私人组织功能，但有可能暴露来自任何私人组织的每个用户都应该被视为安全漏洞：wink：

是否可以将此问题升级到 1.8.1 分支？

不是安全漏洞，因为验收标准永远不会隐藏属于隐藏组织的用户。 这就是这张票的用途。

不是安全漏洞

行 ：）

但是，是否可以添加将用户从一个私人组织隐藏到其他组织的标准？ 可能是可选的。
或者至少可以选择阻止“/explore/users”路由和一致的模板......
我很高兴在 1.8.x 中看到它。 抱歉，我目前的围棋技能不足以贡献一些公关:(

@igsol你是对的，我已经更新了线程，所以现在它只能由管理员用户访问。

在我看来，这应该是可以在用户管理仪表板上配置的。 我也认为这很复杂，我不知道所有提出的解决方案。 肯定有多种场景：允许查看用户所属组织的所有用户、查看所有用户、仅查看自己、公共用户......

@techknowlogick不知道这是否是讨论它的正确地方，我在哪里可以找到有关它的更多信息，但我已经读到这是一个由社区维护的 gogs 叉。 不确定与 gogs 的区别，如何集成在 gogs 上开发的新功能以及为什么我应该迁移到 gitea 或坚持使用 gogs，优点和缺点。 也许你可以指点我去获取更多信息。 还要说的是，我不是一个有经验的程序员，但我也可以做出贡献，即我正在从事加泰罗尼亚语翻译。

@miqmago以下是对 Gitea 与 Gogs 提供的有用比较： https ://docs.gitea.io/en-us/comparison/ 以及解释项目治理差异的发布博客文章： https：/ /blog.gitea.io/2016/12/welcome-to-gitea/

@igsol由于该项目仅向后移植错误修复，

目前正在努力推出 1.9.x。

@techknowlogick好的，我明白了，NP。

到目前为止，我通过使用我相当残酷的补丁制作本地私有构建来帮助自己（类似于@miqmago提到的，但更简单）。 主要是在最后实现这张票:)

无论如何，感谢所有团队的出色Gitea。

1.9.0 发布。 有没有机会引起人们对这张票的关注？

@igsol
这也是我的愿望。

这会有帮助吗？

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

这会有帮助吗？

8340

这不会在公众视野中隐藏所有用户吗？

仅当 REQUIRE_SIGNIN_VIEW 为 true 且您未登录时。

仅当 REQUIRE_SIGNIN_VIEW 为 true 且您未登录时。

如果REQUIRE_SIGNIN_VIEW为真，则无论如何它都是隐藏的。 其次，它仍然会隐藏所有用户，这不是请求的重点。 特别是，由于某些用户只想隐藏单个用户，我认为如果您隐藏仅因为 1 个系统帐户而创建的所有用户，那就有点矫枉过正了。

哦抱歉。

所以我们可以更新这个问题吗？

想要什么？

一个新的配置： ALLOW_VIEW_USERS ？

想要什么？

理想情况下，从我个人的角度来看，我希望每个用户都可以这样设置：

...
在公众视野中隐藏帐户 [ ]
...

这将介于其他设置之间，例如_隐藏电子邮件地址_。

将它包含在管理设置中也很好，但我认为让每个人都能够决定是最好的解决方案。

如果要实现这一点，则该用户的所有存储库都应该成为私有的，恕我直言，这是一个重要的更改。 例如，如果源存储库是公开的，则分叉存储库必须是公开的，因此最终会暴露用户的存在。

如果要实现这一点，则该用户的所有存储库都应该成为私有的，恕我直言，这是一个重要的更改。 例如，如果源存储库是公开的，则分叉存储库必须是公开的，因此最终会暴露用户的存在。

理想情况下，这种方式应该是可选的。 我看到的用例是您只想_unlist_（例如 YouTube 上的 _unlisted_ 视频）用户，这意味着您不希望该用户被显眼地显示，就好像他是您的 Gitea 之王一样，但您不会有问题如果他隐藏在你的 Gitea 丛林中的某个地方。 这个例子适用于我的实例。

理想情况下，这种方式应该是可选的。 我看到的用例是您只想_unlist_（例如 YouTube 上的 _unlisted_ 视频）用户，这意味着您不希望该用户被显眼地显示，就好像他是您的 Gitea 之王一样，但您不会有问题如果他隐藏在你的 Gitea 丛林中的某个地方。 这个例子适用于我的实例。

但是这个问题应该标题为“在Gitea中取消列出一些用户”。 😁

理想情况下，这种方式应该是可选的。 我看到的用例是您只想_unlist_（例如 YouTube 上的 _unlisted_ 视频）用户，这意味着您不希望该用户被显眼地显示，就好像他是您的 Gitea 之王一样，但您不会有问题如果他隐藏在你的 Gitea 丛林中的某个地方。 这个例子适用于我的实例。

但是这个问题应该标题为“在Gitea中取消列出一些用户”。 😁

我认为最准确的标题是“隐藏或取消列出用户”。 提供这两种选择将是一个很好的解决方案。

当然，这些功能也应该可供组织使用。

+1 用于在我未登录时隐藏（所有）用户，资源管理器 + API，但是，当我登录时，我想查看（所有）用户。

我使用 MariaDB。
使用 users.tmpl 我不能应用我想要的东西，因为当我登录时我也看不到用户。
API 始终可以列出所有用户。

我需要从公共视图显示用户，但不是所有用户。

cd /etc/gitea
纳米应用程序.ini
REQUIRE_SIGNIN_VIEW：真
工作得很好！ 但是，这个选项太极端了！
现在尊重安全方面，但我们更希望能够选择是否可见，作为公共或私人用户。

+1，我们需要隐藏 ExplorerUser 选项卡或选择应该在 ExplorerUser 列表中列出哪个用户（本地或 ldap）...很容易检索用户登录然后对其进行暴力破解...或其他任何事情
感谢您提供这个出色的工具。，gitea

REQUIRE_SIGNIN_VIEW = 真

似乎行得通。

@Braqoon您没有阅读对话。 它不会“解决问题”。

如果可以实施，那就太好了。
我想向未注册到我的 gitea 实例的窥视者公开我的一些（公共）存储库，但我不想向他们展示我的所有注册用户（包括管理员）。 正如@theAkito 所提到的，简单地REQUIRE_SIGNIN_VIEW = true并不能解决问题。

编辑：
更糟糕的是，我刚刚检查了@shuhaowu 提到的 API-Call curl -X GET "http://gitea/api/v1/users/search" -H "accept: application/json" 。 即使是非注册用户也可以轻松找出关键信息，例如is_admin或last_login 。 安全方面，这是绝对不行的。

我完全同意隐藏没有公共仓库的用户会非常有用。 假设我添加了一些用户评论私人项目的问题，如果他们能在探索列表中隐藏就完美了！

不显示没有公共回购的用户会很棒

我在这里看到很多评论，但没有关于如何配置的规范或建议。

可以保留当前系统并提供建议的受限视图的合理配置可能会导致实施。

例如，建议的配置块：

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

等等。

那么实现起来就很简单了。

@zeripath您

从我们的角度来看，我们认为这个问题是一个严重的安全问题。

Gitea 泄露了关键的个人信息：名字、姓氏、登录名、电子邮件、创建日期（他们加入我们组织的时间）。

在我们的例子中，Gitea 使用 LDAP 身份验证，基本上泄漏了我们所有的会员信息，没有任何方法可以限制/阻止泄漏。

REQUIRE_SIGNIN_VIEW不可用，因为它破坏了公共存储库。 阻止 /api/v1/users/search 端点会破坏将用户添加到存储库的能力。

至少有一种方法可以将泄漏限制为经过身份验证的用户，这将是非常感激的。

@fluboi现在您可以将 API 访问权限限制为经过身份验证的用户

编辑：看起来只有 API 没有设置：/

看到人们反复评论这个问题而不提供规范或建议的配置，或者在这里评论我提出的规范的缺陷或改进，这是非常令人失望的：（https://github.com/go-gitea/gitea/issues/2908 #issuecomment-670616617)

如果对我的评论有更多的回应和考虑，就什么是必要的和什么是可行的，这几个月前就可以实施了。

就目前而言，我已经提出了一个 PR 来关闭它，但我不知道这是否足够。

感谢@zeripath 所做的工作，并为我之前令人失望的评论感到抱歉。
据我了解，您的 PR 满足我们的需求。
再次感谢

如果对我的评论有更多的回应和考虑一起工作

我认为原因不是懒惰或恶意，而是缺乏对后端的了解，甚至可能是它所用的语言。据我所知，这里的大多数人对 Go 一无所知，因为他们是只是该服务器的用户，而不是开发人员。
关于所有这些我不认识的人，我不能说太多，但我可以为自己说：
我不了解 Gitea 后端，我不想参与 Go，因为我不喜欢 Go 语言，而且已经有很多 Go 程序员，所以生活中没有必要做其他事情，不必要的。 例如，如果后端是用Nim编写的，我会很乐意贡献，甚至可能自己解决这个问题，因为 Nim 实际上是有趣和纯粹的享受，而 Go 对我个人来说是纯粹的苦差事和烦恼。 然而，如果是这样的话，可能所有当前的贡献者都会离开，因为他们宁愿留在 Go 上。

我还认为，如果人们不了解后端的结构和/或语言，那么添加有关实现的随机想法并没有多大意义。 如果最有见识的人决定实施，特别是关于面向安全的功能，这可能是最好的，通常重要的是正确实施而不一定是精美实施。

当然，这是一个开源项目，你或任何其他贡献者没有任何义务去实施任何东西，除非是大赞助商，他们只是为了这些好处才赞助这么多。 我想我们都明白这一点。
然而，这里的人们插话，解释他们的问题，强调它的重要性，希望 Gitea 领导层能尽快解决这个问题，而不是这个存储库中的许多其他问题正在被解决。 所以大家在这里要求的，不是做更多的工作，而只是改变问题的焦点。 简单地说：扔掉另一个问题，而是解决这个问题。

这就是为什么我认为在这里插话是有效的，强调这个问题的重要性，即使发表评论的人没有时间、兴趣或根本没有帮助实施的知识。 这里的大多数人都只是用户，我也是。

我认为原因不是懒惰或恶意，而是缺乏对后端的了解，甚至可能是它所用的语言。据我所知，这里的大多数人对 Go 一无所知，因为他们是只是该服务器的用户，而不是开发人员。

我完全同意。 我是一名开发人员，但不是 Go 语言，我没有花时间熟悉基本代码和应用程​​序的工作方式，因此对实现发表评论肯定会适得其反，然后我只传达了我的用户需求！
但我真的很感激所做的工作（维护其他开源项目，我知道这不是一件容易的事，用户的反馈并不总是你所期望的！）。

请保持主题，如果您对特定问题没有任何补充，请不要发表评论。

只是一个方面说明，这偏离主题的讨论，让我们希望结束：无Gitea贡献者得到支付开发新功能或修复bug，大家都这样做，在课余时间，所以除非有人愿意赞助特定功能或开发，包括 Gitea 贡献者在内的每个人都可以自由地开发他们喜欢的任何东西，当其他贡献者将空闲时间用于这个项目开发他们需要的功能或玩得开心时，Gitea“领导层”不会对其他贡献者需要做什么发表意见。