Definiere "betrachten". Meinst du Einträge wie /explore/users ? Was ist mit den Kommentaren zu öffentlichen Themen? Soll der Kommentar ausgeblendet werden? Soll der Commit bei einem öffentlichen Repo nicht angezeigt werden?

(keiner der beiden letztgenannten Fälle ist übrigens sinnvoll machbar :) )

Ich denke, das ist dazu gedacht, sich vor explore/users zu verstecken

@bkcsoft Ja, ich beziehe mich auf /explore/users . Um die Wahrheit zu sagen, ich habe dieses Thema ganz vergessen. Ich konnte es mit einer Vorlage lösen.

Um Ihre Frage vollständig zu beantworten, habe ich den Root-Benutzer und andere "schreibgeschützte" Benutzer, die nicht auf der Seite /explore/users angezeigt werden sollen. Wenn sie keine Commits haben, sind sie im Wesentlichen aus der öffentlichen Sicht ausgeblendet. Ich möchte verhindern, dass sich jemand mit Root- oder "Nur-Lese"-Benutzern anmeldet.

Notiz:

• Mit "schreibgeschützt" meine ich, dass ich Konten habe, die schreibgeschützten Zugriff auf Repositorys in meinem Gitea-Hauptkonto haben.

@demonpig könnten Sie eine Zusammenfassung der von Ihnen verwendeten benutzerdefinierten Vorlage posten?

@techknowlogick Los geht's.
Die Datei ist 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 danke

Es wäre schön, zusätzlich zu einer Option, die alle Benutzer aus der öffentlichen Ansicht ausblendet, eine Option zum Ausblenden bestimmter Benutzer aus der öffentlichen Ansicht zu haben. Wie die Sicherung lokaler Konten, wenn Sie die LDAP-Authentifizierung aktiviert haben =/.

+1
Ich bin gerade auf das gleiche Problem gestoßen - das Nicht-LDAP-Konto nur für Administratoren wird prominent auf der Zielseite angezeigt. Dies verlangt nach "kreativen" Anmeldeversuchen ....

Ja, das wäre schön zu haben. Im Moment musste ich nur 403 jeden besuchen, der /explore/users über NGINX besucht.

FWIW, es sieht so aus, als ob sowohl die Gitea- als auch die Gogs-Community das wollen.

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

Nur den Zugriff auf /explore/users zu verweigern, löst das Problem nicht. Nutzer können weiterhin über die API gefunden werden:

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

@shuhaowu Schöner Fang! Völlig vergessen, auch den Zugriff auf diesen Endpunkt zu blockieren.

Ich würde das gerne sehen, damit der Admin-Benutzer nicht so prominent ist.

Zur Verdeutlichung: Ist dieses Problem mit REQUIRE_SIGNIN_VIEW auf true oder false ?

@davidsiefert Das glaube ich nicht. Kann grundsätzlich eine Konfigurationsoption hinzugefügt werden, die verhindert, dass das Root- oder alle anderen Benutzerkonten sowohl von den API- als auch von den /explore/users Endpunkten angezeigt werden? Vielleicht könnte Gitea so konfiguriert/entwickelt werden, dass es nur Benutzer anzeigt, die Commits gemacht haben?

…oder diejenigen, die sich für die Veröffentlichung entscheiden.

Dies wäre ein wichtiges Feature für uns. Benutzer sollten andere Benutzer nicht sehen können.

+1-Anfrage zum Ausblenden von Benutzern vor anderen außer Admin (Rechte-Flag hinzufügen)

+1

Wie würde das in der API gehandhabt?

+1

+1

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivität hatte. Es wird geschlossen, wenn in den nächsten 2 Wochen keine Aktivität mehr stattfindet. Vielen Dank für Ihre Beiträge.

Immer noch gesucht...

Ja. Auf jeden Fall noch gesucht.

temporäre Lösung (versteckt nur die Optionen aus den Ansichten) für Eilige hier: https://github.com/gogs/gogs/issues/5080#issuecomment -482657310

für Eilige hier: gogs/gogs#5080

@miqmago wie verhindert es, dass Sie "/explore/users" manuell in den Browser
Ich denke, dass das Patchen von routen.go (um https://github.com/go-gitea/gitea/blob/master/routers/routes/routes.go#L247) obligatorisch ist, oder?

Außerdem wurde #6530 als Duplikat aufgelöst.
Aber ich möchte betonen, dass die Veröffentlichung einer privaten Organisationsfunktion, aber mit der Möglichkeit, alle Benutzer selbst aus einer privaten Organisation herauszugeben, als Sicherheitslücke behandelt werden sollte :wink:

Ist es möglich, dieses Problem in den Zweig 1.8.1 zu eskalieren?

Keine Sicherheitslücke, da das Akzeptanzkriterium nie darin bestand, Benutzer zu verbergen, die Teil versteckter Organisationen sind. Dafür ist dieses Ticket da.

Keine Sicherheitslücke

In Ordnung :)

Aber könnten die Kriterien zum Ausblenden von Benutzern aus einer privaten Organisation in anderen Organisationen hinzugefügt werden? Kann optional sein.
Oder zumindest optional das Blockieren der Route "/explore/users" und der entsprechenden Vorlage...
Ich würde mich freuen, es in 1.8.x zu sehen. Entschuldigung, meine derzeitigen Fähigkeiten in Go reichen nicht aus, um ein bisschen PR beizutragen :(

@igsol du hast recht, ich habe den Thread aktualisiert, sodass er jetzt nur noch für Administratoren zugänglich ist.

Aus meiner Sicht sollte das im Benutzer-Admin-Dashboard konfigurierbar sein. Ich halte das auch für recht komplex und kenne nicht alle Lösungsvorschläge. Natürlich gibt es mehrere Szenarien: Berechtigung, alle Benutzer einer Organisation zu sehen, zu der der Benutzer gehört, alle Benutzer zu sehen, nur sich selbst zu sehen, öffentliche Benutzer...

@techknowlogick weiß nicht, ob dies der richtige Ort ist, um darüber zu diskutieren und wo ich weitere Informationen dazu finden kann, aber ich habe gelesen, dass dies eine Gogs-Gabel ist, die von der Community verwaltet wird. Ich bin mir nicht sicher, was die Unterschiede zu Gogs sind, wie neue Funktionen integriert werden, die auf Gogs entwickelt wurden und warum ich zu gitea migrieren oder bei Gogs bleiben sollte, Vor- und Nachteile. Vielleicht könnten Sie mir einen Hinweis geben, um mehr Informationen zu erhalten. Auch um zu sagen, dass ich kein erfahrener Programmierer bin, aber irgendwie könnte ich auch etwas beitragen, dh ich arbeite an katalanischen Übersetzungen.

@miqmago Hier ist ein hilfreicher Vergleich zu den Angeboten von Gitea vs. Gogs: https://docs.gitea.io/en-us/comparison/ sowie der Einführungs-Blog-Post, in dem die Unterschiede in der Governance der Projekte erläutert werden: https:/ /blog.gitea.io/2016/12/welcome-to-gitea/

@igsol dieses Ticket wird es nicht in eine 1.8.x-Version schaffen, da das Projekt nur Fehlerkorrekturen zurückportiert, wir arbeiten derzeit daran, 1.9.x herauszubringen.

arbeiten derzeit daran, 1.9.x herauszubringen.

@techknowlogick Ok, ich

Bisher habe ich mir selbst geholfen, indem ich einen lokalen privaten Build erstellt habe, der meinen ziemlich brutalen Patch anwendet (so etwas wie @miqmago erwähnt, aber einfacher). Hauptsache dieses Ticket am Ende umsetzen :)

Wie auch immer, vielen Dank an das gesamte Team für die brillante Gitea.

1.9.0 wird veröffentlicht. Besteht die Möglichkeit, auf dieses Ticket aufmerksam zu machen?

@igsol
Das ist auch mein Wunsch.

Würde das helfen?

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

Würde das helfen?

8340

Würde dies nicht alle Benutzer vor der öffentlichen Ansicht verbergen?

Nur wenn REQUIRE_SIGNIN_VIEW wahr ist und Sie nicht eingeloggt sind.

Nur wenn REQUIRE_SIGNIN_VIEW wahr ist und Sie nicht eingeloggt sind.

Wenn REQUIRE_SIGNIN_VIEW wahr ist, wird es trotzdem ausgeblendet. Zweitens würden immer noch alle Benutzer ausgeblendet, was nicht der Sinn der Anfrage ist. Vor allem, da einige Benutzer nur einen einzelnen Benutzer ausblenden möchten und ich es für ein wenig übertrieben halte, wenn Sie ALLE jemals erstellten Benutzer nur wegen eines Systemkontos ausblenden würden.

In Ordnung Entschuldigung.

Können wir das Problem also bitte aktualisieren?

Was wird gewollt?

eine neue Konfiguration: ALLOW_VIEW_USERS ?

Was wird gewollt?

Idealerweise aus meiner persönlichen Sicht würde ich mir eine Einstellung wünschen, die jeder Benutzer so einstellen kann:

...
Konto aus der öffentlichen Ansicht ausblenden [ ]
...

Dazwischen liegen andere Einstellungen wie _E-Mail-Adresse ausblenden_.

Es wäre auch in Ordnung, es in die Admin-Einstellungen aufzunehmen, obwohl ich denke, dass es die beste Lösung ist, jedem die Möglichkeit zu geben, sich zu entscheiden.

Wenn dies implementiert werden soll, sollten alle Repositorys dieses Benutzers privat werden, was IMHO eine nicht triviale Änderung ist. Beispielsweise müssen gegabelte Repositorys öffentlich sein, wenn das Quell-Repository öffentlich ist, sodass die Existenz des Benutzers schließlich offengelegt wird.

Wenn dies implementiert werden soll, sollten alle Repositorys dieses Benutzers privat werden, was IMHO eine nicht triviale Änderung ist. Beispielsweise müssen gegabelte Repositorys öffentlich sein, wenn das Quell-Repository öffentlich ist, sodass die Existenz des Benutzers schließlich offengelegt wird.

Im Idealfall sollte dieser Weg optional sein. Ich sehe Anwendungsfälle, in denen Sie nur einen Benutzer _nicht gelistet_ (wie _nicht gelistete_ Videos auf YouTube) möchten, was bedeutet, dass Sie nicht möchten, dass dieser Benutzer prominent angezeigt wird, als ob er der König Ihrer Gitea wäre, aber Sie hätten kein Problem wenn er irgendwo im Dschungel deiner Gitea versteckt wäre. Dieses Beispiel trifft auf meine Instanz zu.

Im Idealfall sollte dieser Weg optional sein. Ich sehe Anwendungsfälle, in denen Sie nur einen Benutzer _nicht gelistet_ (wie _nicht gelistete_ Videos auf YouTube) möchten, was bedeutet, dass Sie nicht möchten, dass dieser Benutzer prominent angezeigt wird, als ob er der König Ihrer Gitea wäre, aber Sie hätten kein Problem wenn er irgendwo im Dschungel deiner Gitea versteckt wäre. Dieses Beispiel trifft auf meine Instanz zu.

Aber dann sollte diese Ausgabe den Titel "Einige Benutzer in Gitea auflisten" tragen. 😁

Im Idealfall sollte dieser Weg optional sein. Ich sehe Anwendungsfälle, in denen Sie nur einen Benutzer _nicht gelistet_ (wie _nicht gelistete_ Videos auf YouTube) möchten, was bedeutet, dass Sie nicht möchten, dass dieser Benutzer prominent angezeigt wird, als ob er der König Ihrer Gitea wäre, aber Sie hätten kein Problem wenn er irgendwo im Dschungel deiner Gitea versteckt wäre. Dieses Beispiel trifft auf meine Instanz zu.

Aber dann sollte diese Ausgabe den Titel "Einige Benutzer in Gitea auflisten" tragen. 😁

Ich denke, der genaueste Titel wäre "Benutzer ausblenden oder aufheben". Beide Optionen anzubieten wäre eine gute Lösung.

Diese Funktionen sollten natürlich auch für Organisationen verfügbar sein.

+1 für (alle) Benutzer ausblenden, wenn ich nicht angemeldet bin, Explorer + API, aber wenn ich mich angemeldet habe, möchte ich (alle) Benutzer sehen.

Ich benutze MariaDB.
Mit users.tmpl kann ich nicht anwenden, was ich will, weil ich beim Einloggen die Benutzer auch nicht sehen kann.
Die API kann immer alle Benutzer auflisten.

Ich brauche Anzeigebenutzer aus der öffentlichen Ansicht, aber nicht alle Benutzer.

cd /etc/gitea
nano app.ini
REQUIRE_SIGNIN_VIEW: wahr
Arbeite sehr gut! Aber diese Option war extrem!
Der Sicherheitsaspekt wird jetzt respektiert, aber wir würden es vorziehen, wählen zu können, ob wir als öffentlicher oder privater Benutzer sichtbar sind oder nicht.

+1, wir müssen die Registerkarte ExplorerUser ausblenden ODER auswählen, welcher Benutzer (lokal oder ldap) in der ExplorerUser-Liste aufgeführt werden soll ... es ist einfach, die Benutzeranmeldung abzurufen und sie dann brutal zu erzwingen ... oder etwas anderes
Vielen Dank für dieses wunderbare Tool., gitea

REQUIRE_SIGNIN_VIEW = wahr

Scheint den Trick zu machen.

@Braqoon Du hast die Konversation nicht gelesen. Es macht nicht "den Trick".

Wäre super wenn das umgesetzt werden könnte.
Ich möchte einige meiner (öffentlichen) Repos Peeps aussetzen, die nicht bei meiner gitea-Instanz registriert sind, aber ich möchte ihnen nicht alle meine registrierten Benutzer (einschließlich Admin) anzeigen. Wie @theAkito erwähnte, REQUIRE_SIGNIN_VIEW = true das Problem nicht.

Bearbeiten:
Schlimmer noch, ich habe gerade den API-Call curl -X GET "http://gitea/api/v1/users/search" -H "accept: application/json" überprüft, wie von @shuhaowu erwähnt. Sogar nicht registrierte Benutzer können kritische Informationen wie is_admin oder last_login leicht herausfinden. Aus Sicherheitsgründen ein absolutes No-Go.

Ich stimme voll und ganz zu, dass es sehr nützlich wäre, Benutzer möglicherweise auszublenden, die kein öffentliches Repo haben. Nehmen wir an, ich füge einige Benutzer hinzu, um Probleme zu privaten Projekten zu kommentieren. Es wäre perfekt, wenn sie in der Erkundungsliste unsichtbar gemacht werden könnten!

Es wird großartig sein, keine Benutzer anzuzeigen, die kein öffentliches Repo haben

Ich sehe hier viele Kommentare, aber keine Spezifikationen oder Vorschläge für die Konfiguration.

Eine sinnvolle Konfiguration, die das aktuelle System beibehalten und die vorgeschlagenen eingeschränkten Ansichten bieten könnte, würde wahrscheinlich zur Implementierung führen.

Zum Beispiel ein vorgeschlagener Konfigurationsblock:

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

und so weiter.

Dann wäre es einfach zu implementieren.

@zeripath der von dir beschriebene Ansatz erscheint mir vernünftig und sollte die meisten Fälle von exponierten Informationen abdecken, wenn die implementierten Konfigurationsänderungen auch den API-Zugriff betreffen.

Von unserer Seite halten wir dieses Problem für ein ernstes Sicherheitsproblem.

Gitea gibt wichtige persönliche Informationen frei: Vorname, Nachname, Login, E-Mail, Erstellungsdatum (als sie unserer Organisation beigetreten sind).

In unserem Fall verwendet Gitea die LDAP-Authentifizierung und gibt im Grunde alle unsere Mitgliederinformationen durch, ohne dieses Leck zu begrenzen/zu stoppen.

REQUIRE_SIGNIN_VIEW nicht verwendet werden, da es öffentliche Repositorys zerstört. Das Blockieren des Endpunkts /api/v1/users/search unterbricht die Möglichkeit, einen Benutzer zu einem Repository hinzuzufügen.

Es wäre wirklich wünschenswert, zumindest eine Möglichkeit zu haben, das Leck auf authentifizierte Benutzer zu beschränken.

@fluboi vorerst könnten Sie den API-Zugriff auf authentifizierte Benutzer beschränken

BEARBEITEN: es sieht so aus, als ob es keine Einstellung nur für API gibt :/

Es ist mehr als enttäuschend zu sehen, dass Leute dieses Problem wiederholt kommentieren, ohne eine Spezifikation oder vorgeschlagene Konfiguration anzubieten oder die Mängel oder Verbesserungen meiner vorgeschlagenen Spezifikation hier zu kommentieren: (https://github.com/go-gitea/gitea/issues/2908 #issuecomment-670616617)

Wenn es mehr Resonanz und Rücksicht auf meinen Kommentar gegeben hätte, gemeinsam zu überlegen, was notwendig ist und was funktionieren würde, wäre dies schon vor Monaten umsetzbar gewesen.

So wie es aussieht, habe ich eine PR vorgeschlagen, um dies zu schließen, aber ich weiß nicht, ob es ausreicht.

Danke für deine Arbeit @zeripath und entschuldige meinen vorherigen enttäuschenden Kommentar.
Soweit ich weiß, entspricht Ihre PR unseren Anforderungen.
Danke noch einmal

Wenn es mehr Resonanz und Rücksicht auf meinen Kommentar gegeben hätte, wenn wir zusammengearbeitet hätten

Ich denke, der Grund ist nicht Faulheit oder böswillige Absicht, sondern das mangelnde Verständnis des Backends und vielleicht sogar der Sprache, in der es geschrieben ist. Soweit ich gesehen habe, haben die meisten Leute hier keine Ahnung von Go, so wie sie es sind nur Benutzer dieses Servers und keine Entwickler.
Ich kann nicht viel über all diese Leute sagen, die ich nicht kenne, aber ich kann für mich selbst sprechen:
Ich verstehe das Gitea-Backend nicht und möchte mich nicht auf Go einlassen, weil ich die Sprache nicht mag und es sowieso schon jede Menge Go-Programmierer gibt, so dass man im Leben nicht unnötig etwas anderes tun muss. Wenn zum Beispiel das Backend in Nim geschrieben wäre, würde ich gerne dazu beitragen, dieses Problem vielleicht sogar selbst zu beheben, da Nim eigentlich Spaß macht und pure Freude macht, während Go für mich persönlich reine lästige Pflicht und Ärger ist. Wenn dies jedoch der Fall wäre, würden wahrscheinlich alle aktuellen Mitwirkenden gehen, weil sie lieber bei Go bleiben.

Ich denke auch, es macht wenig Sinn, wenn Leute zufällige Ideen zur Implementierung hinzufügen, wenn sie keine Ahnung von der Struktur des Backends und/oder der Sprache haben. Es ist wahrscheinlich am besten, wenn die Fachkundigsten über die Implementierung entscheiden, insbesondere in Bezug auf sicherheitsorientierte Funktionen, die normalerweise wichtig sind, um richtig und nicht unbedingt schön zu implementieren.

Natürlich ist dies ein Open-Source-Projekt und Sie oder andere Mitwirkende sind nicht verpflichtet, irgendetwas zu implementieren, außer vielleicht für große Sponsoren, die nur für diese Vorteile viel sponsern. Ich denke, das haben wir alle verstanden.
Die Leute hier stimmen jedoch ein, erklären ihr Problem und betonen die Bedeutung in der Hoffnung, dass die Führung von Gitea dieses Problem so schnell wie möglich angeht, anstatt so viele andere Probleme in diesem Repository, die stattdessen behandelt werden. Alles was die Leute hier fordern, ist also nicht mehr Arbeit zu machen, sondern nur den Fokus der Themen zu ändern. Einfach: Wirf ein anderes Problem weg und löse dieses stattdessen.

Deshalb halte ich es für angebracht, sich hier einzuklinken und die Bedeutung dieses Themas zu betonen, auch wenn die Person, die einen Kommentar veröffentlicht, keine Zeit, kein Interesse oder einfach nicht das Wissen hat, um bei der Umsetzung zu helfen. Die meisten Leute hier sind nur Benutzer, wie ich es auch bin.

Ich denke, der Grund ist nicht Faulheit oder böswillige Absicht, sondern das mangelnde Verständnis des Backends und vielleicht sogar der Sprache, in der es geschrieben ist. Soweit ich gesehen habe, haben die meisten Leute hier keine Ahnung von Go, so wie sie es sind nur Benutzer dieses Servers und keine Entwickler.

Mehr könnte ich nicht zustimmen. Ich bin Entwickler, aber nicht in Go und habe mir nicht die Zeit genommen, mich mit dem Basiscode und der Funktionsweise der Anwendung vertraut zu machen, daher wäre es sicherlich kontraproduktiv, die Implementierung zu kommentieren, und dann habe ich nur meine Benutzerbedürfnisse mitgeteilt!
Aber ich schätze die geleistete Arbeit WIRKLICH (die Pflege anderer Open-Source-Projekte, ich weiß, es ist keine leichte Aufgabe und das Feedback der Benutzer ist nicht immer das, was Sie erwarten würden!).

Bitte bleiben Sie beim Thema, wenn Sie zu einem bestimmten Thema nichts hinzuzufügen haben, kommentieren Sie bitte nicht.

Nur eine Randnotiz und hoffen wir auf ein Ende dieser Off-Topic-Diskussion: Keiner der Gitea-Mitwirkenden wird dafür bezahlt, neue Funktionen zu entwickeln oder Fehler zu beheben, das tun wir alle in unserer Freizeit. Jeder, einschließlich Gitea-Mitwirkenden, ist frei, zu entwickeln, was er möchte, und Gitea "Leadership" hat keinen Einfluss darauf, was andere Mitwirkende tun müssen, wenn sie ihre Freizeit diesem Projekt widmen, um Funktionen zu entwickeln, die sie brauchen oder Spaß daran haben.