"보기"를 정의합니다. /explore/users 와 같은 목록을 말씀하시는 건가요? 공개 문제에 대한 댓글은 어떻게 됩니까? 댓글을 숨기고 싶습니까? 공개 리포지토리에 커밋하면 커밋이 표시되지 않아야 합니까?

(후자의 두 경우 중 어느 것도 합리적인 방법으로 수행할 수 없습니다. :) )

explore/users 에서 숨기기 위한 것 같습니다.

@bkcsoft 예, /explore/users 언급하고 있습니다. 당신에게 진실, 나는이 문제에 대해 모두 잊어 버렸습니다. 템플릿을 사용하여 해결할 수 있었습니다.

귀하의 질문에 완전히 답하기 위해 루트 사용자와 /explore/users 페이지에 표시하고 싶지 않은 다른 "읽기 전용" 사용자가 있습니다. 커밋이 없으면 기본적으로 공개 보기에서 숨겨집니다. 누군가 루트 또는 "읽기 전용" 사용자로 로그인하는 것을 방지하고 싶습니다.

메모:

• "읽기 전용"이란 기본 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 계정이 방문 페이지에 눈에 띄게 표시됩니다. 이것은 "창조적인" 로그인 시도를 요구합니다 ....

예, 이것이 있으면 좋을 것입니다. 현재로서는 NGINX를 통해 /explore/users 를 방문하는 사람을 403명으로 지정해야 했습니다.

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 끝점 모두에서 표시되지 않도록 하는 구성 옵션을 추가할 수 있습니까? 커밋을 한 사용자만 표시하는 방식으로 Gitea를 구성/개발할 수 있습니까?

...또는 출판을 선택한 사람들.

이것은 우리에게 중요한 기능이 될 것입니다. 사용자는 다른 사용자를 볼 수 없어야 합니다.

관리자를 제외한 다른 사용자로부터 사용자를 숨기기 위한 +1 요청(권한 플래그 추가)

+1

API에서는 어떻게 처리됩니까?

+1

+1

이 문제는 최근 활동이 없었기 때문에 자동으로 오래된 것으로 표시되었습니다. 앞으로 2주 동안 더 이상 활동이 없으면 폐쇄됩니다. 귀하의 기여에 감사드립니다.

그래도 원했던...

예. 확실히 여전히 원했습니다.

여기에서 급한 사람들을 위한 임시 솔루션(보기에서 옵션을 숨김): https://github.com/gogs/gogs/issues/5080#issuecomment -482657310

바쁘신 분들을 위해: gogs/gogs#5080

@miqmago 브라우저에서 "/explore/users"를 수동으로 입력하는 것을 어떻게 방지합니까?
route.go의 패치(https://github.com/go-gitea/gitea/blob/master/routers/routes/routes.go#L247 주변)가 필수라고 생각합니다. 그렇지 않나요?

또한 #6530이 중복으로 해결되었습니다.
그러나 개인 조직 기능이 릴리스되었지만 모든 개인 조직의 모든 사용자가 노출될 가능성이 있는 것은 보안 허점으로 취급되어야 한다는 점을 강조하고 싶습니다.wink:

이 문제를 1.8.1 분기로 에스컬레이션할 수 있습니까?

허용 기준은 숨겨진 조직의 일부인 사용자를 숨기는 것이 아니므로 보안 허점이 아닙니다. 그것이 바로 이 티켓의 목적입니다.

보안 구멍이 아닙니다.

확인 :)

그러나 한 개인 조직에서 다른 조직으로 사용자를 숨기는 기준을 추가할 수 있습니까? 선택적으로 있을 수 있습니다.
또는 "/explore/users" 경로 및 해당 템플릿의 선택적인 차단...
1.8.x에서 볼 수 있게 되어 기쁩니다. 죄송합니다. 현재 Go에 대한 기술이 홍보에 기여하기에 충분하지 않습니다 :(

@igsol 맞습니다 . 스레드를 업데이트하여 지금은 관리자만 액세스할 수 있습니다.

내 관점에서 이는 사용자 관리 대시보드에서 구성할 수 있는 것이어야 합니다. 나는 또한 이것이 매우 복잡하고 제안된 모든 솔루션을 알지 못한다고 생각합니다. 확실히 여러 시나리오가 있습니다. 사용자가 속한 조직의 모든 사용자를 볼 수 있는 권한, 모든 사용자를 볼 수 있는 권한, 자신만 볼 수 있는 권한, 공개 사용자...

@techknowlogick 은 이것이 토론하기에 적합한 장소인지, 이에 대한 추가 정보를 어디에서 찾을 수 있는지 알지 못하지만 이것이 커뮤니티에서 관리하는 gogs fork라는 것을 읽었습니다. gog와의 차이점, gog에서 개발된 새로운 기능을 통합하는 방법, gitea로 마이그레이션해야 하거나 gog, 장단점을 고수해야 하는 이유에 대해 잘 모르겠습니다. 더 많은 정보를 얻을 수 있는 곳을 알려줄 수 있습니다. 또한 저는 경험이 풍부한 프로그래머는 아니지만 어떻게든 기여할 수 있습니다. 즉, 카탈로니아어 번역 작업을 하고 있습니다.

@miqmago 다음은 Gitea 대 Gogs가 제공하는 것에 대한 유용한 비교입니다: https://docs.gitea.io/en-us/comparison/ 뿐만 아니라 프로젝트 거버넌스의 차이점에 대해 설명하는 출시 블로그 게시물: https:// /blog.gitea.io/2016/12/welcome-to-gitea/

@igsol 이 티켓은 버그 수정만 백포팅하는 프로젝트로 인해 1.8.x 릴리스에 포함되지 않습니다. 현재 1.9.x를 출시하기 위해 노력하고 있습니다.

현재 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 가 true이면 어쨌든 숨겨집니다. 둘째, 요청의 요점이 아닌 모든 사용자를 여전히 숨깁니다. 특히 일부 사용자는 한 명의 사용자만 숨기고 싶어하기 때문에 하나의 시스템 계정으로 인해 생성된 모든 사용자를 숨기는 것은 조금 과하다고 생각합니다.

그래 미안.

문제를 업데이트할 수 있습니다.

원하는 것은 무엇입니까?

새 구성: ALLOW_VIEW_USERS ?

원하는 것은 무엇입니까?

이상적으로는 개인적인 관점에서 각 사용자가 다음과 같이 설정할 수 있는 설정을 원합니다.

...
공개 보기에서 계정 숨기기 [ ]
...

_Hide e-mail address_와 같은 다른 설정들 사이에 있을 것입니다.

모든 사람이 결정할 수 있도록 하는 것이 가장 좋은 솔루션이라고 생각하지만 관리자 설정에 포함시키는 것도 괜찮습니다.

이것이 구현되면 해당 사용자의 모든 리포지토리가 비공개가 되어야 하며 이는 IMHO의 사소한 변경입니다. 예를 들어, 소스 리포지토리가 공개인 경우 분기된 리포지토리는 공개되어야 하므로 사용자의 존재가 결국 노출됩니다.

이것이 구현되면 해당 사용자의 모든 리포지토리가 비공개가 되어야 하며 이는 IMHO의 사소한 변경입니다. 예를 들어, 소스 리포지토리가 공개인 경우 분기된 리포지토리는 공개되어야 하므로 사용자의 존재가 결국 노출됩니다.

이상적으로 이 방법은 선택 사항이어야 합니다. 사용자를 _unlisted_(예: YouTube의 _unlisted_ 동영상)하려는 사용 사례를 봅니다. 즉, 이 사용자가 Gitea의 왕인 것처럼 눈에 띄게 표시되는 것을 원하지 않지만 문제가 없을 것입니다. 그가 당신의 Gitea의 정글 어딘가에 숨겨져 있다면. 이 예는 제 경우에 해당됩니다.

이상적으로 이 방법은 선택 사항이어야 합니다. 사용자를 _unlisted_(예: YouTube의 _unlisted_ 동영상)하려는 사용 사례를 봅니다. 즉, 이 사용자가 Gitea의 왕인 것처럼 눈에 띄게 표시되는 것을 원하지 않지만 문제가 없을 것입니다. 그가 당신의 Gitea의 정글 어딘가에 숨겨져 있다면. 이 예는 제 경우에 해당됩니다.

그러나 이 문제의 제목은 "Gitea에서 일부 사용자 목록 해제"로 지정해야 합니다. 😁

이상적으로 이 방법은 선택 사항이어야 합니다. 사용자를 _unlisted_(예: 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
...

등등.

그러면 간단하게 구현할 수 있습니다.

구현된 구성 변경이 API-Access에도 영향을 미치는 경우 귀하가 제시한 @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는 개인적으로 순수한 잡일이자 성가시기 때문에 이 문제를 직접 해결할 수도 있습니다. 그러나 만약 그렇다면 현재 기여한 사람들은 모두 바둑에 남아 있기 때문에 떠날 것입니다.

또한 백엔드의 구조 및/또는 언어에 대해 전혀 모르는 사람들이 구현과 관련하여 무작위 아이디어를 추가하는 것은 의미가 없다고 생각합니다. 가장 지식이 풍부한 사람들이 구현, 특히 보안 지향 기능과 관련하여 구현을 결정하는 경우 일반적으로 올바르게 구현해야 하며 반드시 아름답게 구현해야 하는 것은 아닙니다.

물론 이것은 오픈 소스 프로젝트이며 귀하 또는 다른 기여자는 이러한 혜택을 위해 많은 것을 후원하는 큰 후원자를 제외하고는 아무 것도 구현할 의무가 없습니다. 나는 우리 모두가 그것을 이해한다고 생각합니다.
그러나 여기 사람들은 문제를 설명하고 문제의 중요성을 강조하며 Gitea 리더십이 이 저장소의 다른 많은 문제 대신 해결되는 대신 이 문제를 최대한 빨리 해결하기를 바랍니다. 그래서 여기 있는 모든 사람들이 요구하는 것은 더 많은 일을 하는 것이 아니라 문제의 초점을 바꾸는 것입니다. 간단히: 다른 문제를 버리고 대신 이 문제를 해결하십시오.

그렇기 때문에 댓글을 게시하는 사람이 시간이 없거나 관심이 없거나 단순히 구현에 도움이 되는 지식이 없더라도 이 문제의 중요성을 강조하면서 여기에서 차임벨을 내는 것이 타당하다고 생각합니다. 여기 있는 대부분의 사람들은 저와 마찬가지로 그냥 사용자입니다.

그 이유는 게으름이나 악의적 인 의도가 아니라 백엔드에 대한 이해 부족과 아마도 그것이 쓰여진 언어까지 있다고 생각합니다. 내가 본 한, 여기있는 대부분의 사람들은 바둑에 대해 전혀 모릅니다. 개발자가 아닌 이 서버의 사용자만 가능합니다.

더 동의할 수 없습니다. 저는 개발자지만 Go를 사용하지 않으며 기본 코드와 애플리케이션 작동 방식에 익숙해질 시간이 없었습니다. 따라서 구현에 대해 논평하는 것은 확실히 비생산적일 것입니다. 그런 다음 내 사용자 요구 사항만 전달했습니다!
그러나 나는 수행한 작업에 정말로 감사합니다(다른 오픈 소스 프로젝트를 유지 관리하는 것이 쉬운 일이 아니며 사용자의 피드백이 항상 기대하는 것이 아니라는 것을 알고 있습니다!).

주제를 유지하십시오. 특정 문제에 대해 추가할 사항이 없으면 댓글을 달지 마십시오.

참고로 이 주제를 벗어난 토론이 끝나기를 바랍니다. Gitea 기고자 중 누구도 새로운 기능을 개발하거나 버그를 수정하는 대가를 받지 않으며, 우리 모두는 여가 시간에 이를 수행하므로 누군가가 특정 기능이나 개발을 기꺼이 후원하지 않는 한, Gitea 기고자를 포함한 모든 사람은 자신이 좋아하는 것은 무엇이든 자유롭게 개발할 수 있으며 Gitea "리더십"은 다른 기고자가 필요하거나 재미있는 기능을 개발하는 이 프로젝트에 여가 시간을 할애할 때 무엇을 해야 하는지에 대해 말하지 않습니다.