Définir « visualiser ». Faites-vous référence à des annonces comme /explore/users ? Qu'en est-il des commentaires sur des problèmes publics, voulez-vous que le commentaire soit masqué ? S'engager dans un dépôt public, le commit ne doit-il pas être affiché ?

(aucun de ces deux derniers cas n'est faisable de manière sensée d'ailleurs :) )

Je pense que c'est pour se cacher de explore/users

@bkcsoft Oui, je fais référence à /explore/users . Pour vous la vérité, j'ai oublié tout ce problème. J'ai pu le résoudre en utilisant un modèle.

Pour répondre pleinement à votre question, j'ai l'utilisateur root et d'autres utilisateurs "en lecture seule" que je ne veux pas afficher sur la page /explore/users . S'ils n'ont pas de commits, alors ils sont essentiellement cachés à la vue du public. Je veux empêcher quelqu'un de se connecter avec les utilisateurs root ou "en lecture seule".

Noter:

• Par "lecture seule", je veux dire que j'ai des comptes qui ont un accès en lecture seule aux référentiels de mon compte Gitea principal.

@demonpig pourriez -vous publier un aperçu du modèle personnalisé que vous utilisez ?

@techknowlogick Et voilà.
Le fichier est dans : ${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 merci

Ce serait bien d'avoir, en plus d'une option qui cache tous les utilisateurs de la vue publique, une option pour cacher des utilisateurs spécifiques de la vue publique. Comme les comptes locaux de sauvegarde lorsque vous avez activé l'authentification LDAP =/.

+1
Je viens de rencontrer le même problème : le compte non LDAP réservé aux administrateurs est affiché en évidence sur la page de destination. Cela demande des tentatives de connexion "créatives" ....

Ouais, ce serait bien d'avoir. Pour l'instant, je viens d'avoir 403 personnes qui visitent /explore/users via NGINX.

FWIW, il semble que la communauté gitea et gogs le souhaite.

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

Refuser l'accès à /explore/users ne résout pas le problème. Les utilisateurs peuvent toujours être trouvés via l'API :

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

@shuhaowu Belle prise ! J'ai totalement oublié de bloquer l'accès à ce point de terminaison également.

J'aimerais voir cela afin que l'utilisateur administrateur ne soit pas si important.

Pour clarifier, ce problème avec REQUIRE_SIGNIN_VIEW défini sur true ou false ?

@davidsiefert Je ne le crois pas. Fondamentalement, peut-il y avoir une option de configuration ajoutée qui empêcherait le compte root ou tous les autres utilisateurs d'être affichés à la fois à partir de l'API et des points /explore/users terminaison

… ou ceux qui choisissent d'être publiés.

Ce serait une caractéristique importante pour nous. Les utilisateurs ne devraient pas être en mesure de voir les autres utilisateurs.

+1 demande pour cacher les utilisateurs des autres sauf administrateur (ajouter un indicateur de droits)

+1

Comment cela serait-il géré dans l'API ?

+1

+1

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité n'a lieu au cours des 2 prochaines semaines. Merci pour vos contributions.

Toujours voulu...

Oui. Certainement toujours recherché.

solution temporaire (masque juste les options des vues) pour ceux qui sont pressés ici : https://github.com/gogs/gogs/issues/5080#issuecomment -482657310

pour les plus pressés ici : gogs/gogs#5080

@miqmago comment cela empêche-t-il de taper manuellement "/explore/users" dans le navigateur ?
Je suppose que le correctif de routes.go (autour de https://github.com/go-gitea/gitea/blob/master/routers/routes/routes.go#L247 ) est obligatoire, n'est-ce pas ?

De plus, le #6530 a été résolu en tant que doublon.
Mais je voudrais souligner que la sortie de la fonctionnalité d'organisation privée, mais avec la possibilité d'exposer tous les utilisateurs, même de n'importe quelle organisation privée, doit être traitée comme une faille de sécurité :wink:

Est-il possible d'escalader ce problème dans la branche 1.8.1 ?

Pas une faille de sécurité, car les critères d'acceptation n'étaient jamais de masquer les utilisateurs faisant partie d'organisations cachées. C'est à ça que sert ce billet.

Pas une faille de sécurité

D'accord :)

Mais les critères pour masquer les utilisateurs d'une organisation privée à d'autres organisations pourraient-ils être ajoutés ? Peut être en option.
Ou au moins le blocage facultatif de la route "/explore/users" et du modèle correspondant...
Je serais heureux de le voir en 1.8.x. Désolé, mes compétences actuelles en Go ne sont pas suffisantes pour contribuer aux relations publiques :(

@igsol tu as raison, j'ai mis à jour le fil donc maintenant il n'est accessible que par les utilisateurs admin pour le moment.

À mon avis, cela devrait être quelque chose de configurable dans le tableau de bord de l'administrateur des utilisateurs. Je pense aussi que c'est assez complexe et je ne connais pas toutes les solutions proposées. Bien sûr, il existe plusieurs scénarios : autorisation de voir tous les utilisateurs d'une organisation à laquelle l'utilisateur appartient, de voir tous les utilisateurs, de ne voir que lui-même, les utilisateurs publics...

@techknowlogick ne sait pas si c'est le bon endroit pour en discuter et où puis-je trouver plus d'informations à ce sujet, mais j'ai lu qu'il s'agissait d'une fourchette de gogs gérée par la communauté. Pas sûr des différences avec les gogs, comment intégrer les nouvelles fonctionnalités développées sur les gogs et pourquoi devrais-je migrer vers gitea ou m'en tenir aux gogs, avantages et inconvénients. Peut-être pourriez-vous m'indiquer quelque part pour obtenir plus d'informations. Aussi pour dire que je ne suis pas un programmeur expérimenté en déplacement, mais que je pourrais aussi contribuer d'une manière ou d'une autre, c'est-à-dire que je travaille sur des traductions en catalan.

@miqmago Voici une comparaison utile sur ce que propose Gitea vs Gogs : https://docs.gitea.io/en-us/comparison/ ainsi que le billet de blog de lancement expliquant les différences de gouvernance des projets : https:// /blog.gitea.io/2016/12/welcome-to-gitea/

@igsol, ce ticket ne sera pas intégré à une version 1.8.x en raison du projet de rétroportage des corrections de bogues, nous travaillons actuellement à la sortie de la version 1.9.x.

travaille actuellement sur la sortie de la version 1.9.x.

@techknowlogick Ok, je vois, NP.

Jusqu'à présent, je me suis aidé en créant une construction privée locale en appliquant mon patch assez brutal (quelque chose comme @miqmago mentionné, mais en plus simple). L'essentiel est d'implémenter ce ticket à la fin :)

En tout cas merci à toute l'équipe pour le brillant Gitea.

1.9.0 est publié. Y a-t-il une chance d'attirer l'attention sur ce billet ?

@igsol
C'est aussi mon souhait.

Cela aiderait-il?

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

Cela aiderait-il?

8340

Cela ne cacherait-il pas tous les utilisateurs à la vue du public ?

Uniquement si REQUIRE_SIGNIN_VIEW est vrai et que vous n'êtes pas connecté.

Uniquement si REQUIRE_SIGNIN_VIEW est vrai et que vous n'êtes pas connecté.

Si REQUIRE_SIGNIN_VIEW est vrai, il est quand même masqué. Deuxièmement, cela masquerait toujours tous les utilisateurs, ce qui n'est pas le but de la requête. Surtout que certains utilisateurs ne veulent masquer qu'un seul utilisateur et je pense que ce serait un peu exagéré de masquer TOUS les utilisateurs jamais créés à cause d'un seul compte système.

D'accord, désolé.

Alors pouvons-nous s'il vous plaît mettre à jour le problème.

Qu'est-ce qui est recherché ?

une nouvelle config : ALLOW_VIEW_USERS ?

Qu'est-ce qui est recherché ?

Idéalement de mon point de vue personnel, je souhaiterais un paramètre que chaque utilisateur peut définir comme ceci :

...
Masquer le compte de la vue publique [ ]
...

Ce qui serait entre d'autres paramètres comme _Masquer l'adresse e-mail_.

Ce serait également bien de l'inclure dans les paramètres d'administration, même si je pense que permettre à tout le monde de décider est la meilleure solution.

Si cela doit être mis en œuvre, tous les référentiels de cet utilisateur doivent devenir privés, ce qui est un changement non trivial à mon humble avis. Par exemple, les référentiels fork doivent être publics si le référentiel source est public, de sorte que l'existence de l'utilisateur sera éventuellement exposée.

Si cela doit être mis en œuvre, tous les référentiels de cet utilisateur doivent devenir privés, ce qui est un changement non trivial à mon humble avis. Par exemple, les référentiels fork doivent être publics si le référentiel source est public, de sorte que l'existence de l'utilisateur sera éventuellement exposée.

Idéalement, cette méthode devrait être facultative. Je vois des cas d'utilisation où vous voulez juste _désinscrire_ (comme des vidéos _non répertoriées_ sur YouTube) un utilisateur, ce qui signifie que vous ne voulez pas que cet utilisateur soit affiché bien en vue comme s'il était le roi de votre Gitea mais vous n'auriez pas de problème s'il était caché quelque part dans la jungle de votre Gitea. Cet exemple est vrai pour mon instance.

Idéalement, cette méthode devrait être facultative. Je vois des cas d'utilisation où vous voulez juste _désinscrire_ (comme des vidéos _non répertoriées_ sur YouTube) un utilisateur, ce qui signifie que vous ne voulez pas que cet utilisateur soit affiché bien en vue comme s'il était le roi de votre Gitea mais vous n'auriez pas de problème s'il était caché quelque part dans la jungle de votre Gitea. Cet exemple est vrai pour mon instance.

Mais alors ce problème devrait être intitulé "Délister certains utilisateurs dans Gitea". ??

Idéalement, cette méthode devrait être facultative. Je vois des cas d'utilisation où vous voulez juste _désinscrire_ (comme des vidéos _non répertoriées_ sur YouTube) un utilisateur, ce qui signifie que vous ne voulez pas que cet utilisateur soit affiché bien en vue comme s'il était le roi de votre Gitea mais vous n'auriez pas de problème s'il était caché quelque part dans la jungle de votre Gitea. Cet exemple est vrai pour mon instance.

Mais alors ce problème devrait être intitulé "Délister certains utilisateurs dans Gitea". ??

Je pense que le titre le plus précis serait « Masquer ou supprimer les utilisateurs ». Offrir les deux options serait une excellente solution.

Ces fonctionnalités devraient également être disponibles pour les organisations, bien sûr.

+1 pour masquer (tous) les utilisateurs lorsque je ne me connecte pas, explorer + API, mais, lorsque je me connecte, je veux voir (tous) les utilisateurs.

J'utilise MariaDB.
Avec users.tmpl, je ne peux pas appliquer ce que je veux, car lorsque je me connecte, je ne peux pas non plus voir les utilisateurs.
L'API peut toujours répertorier tous les utilisateurs.

J'ai besoin d'afficher l'utilisateur de la vue publique, mais pas tous les utilisateurs.

cd /etc/gita
nano app.ini
REQUIRE_SIGNIN_VIEW : vrai
Fonctionne très bien ! Mais, cette option était extrême !
L'aspect sécurité est désormais respecté, mais nous préférerions pouvoir choisir d'être visible ou non, en tant qu'utilisateur public ou privé.

+1, nous devons masquer l'onglet ExplorerUser OU choisir quel utilisateur (local ou ldap) doit être répertorié dans la liste ExplorerUser ... il est facile de récupérer la connexion de l'utilisateur puis de le forcer brutalement ... ou autre chose
Merci pour ce merveilleux outil., gitea

REQUIRE_SIGNIN_VIEW = vrai

Semble faire l'affaire.

@Braqoon Vous n'avez pas lu la conversation. Il ne "fait pas l'affaire".

Ce serait formidable si cela pouvait être mis en œuvre.
Je souhaite exposer certains de mes dépôts (publics) à des personnes qui ne sont pas enregistrées sur mon instance gitea, mais je ne veux pas leur montrer tous mes utilisateurs enregistrés (y compris l'administrateur). Comme @theAkito l'a mentionné, simplement REQUIRE_SIGNIN_VIEW = true ne résout pas le problème.

Éditer:
Pire encore, je viens de vérifier l'API-Call curl -X GET "http://gitea/api/v1/users/search" -H "accept: application/json" comme mentionné par @shuhaowu. Même les utilisateurs non enregistrés peuvent facilement découvrir des informations critiques telles que is_admin ou last_login . Du point de vue de la sécurité, il s'agit d'un interdit absolu.

Je suis tout à fait d'accord qu'il serait très utile de masquer éventuellement les utilisateurs qui n'ont pas de dépôt public. Disons que j'ajoute quelques utilisateurs pour commenter des problèmes sur des projets privés, ce serait parfait s'ils pouvaient être rendus invisibles dans la liste d'exploration !

Ce sera génial de ne pas montrer les utilisateurs qui n'ont pas de dépôt public

Je vois beaucoup de commentaires ici, mais aucune spécification ou proposition sur la façon dont il est configuré.

Une configuration sensée qui pourrait conserver le système actuel et offrir les vues restreintes proposées conduirait probablement à la mise en œuvre.

Par exemple, un bloc de configuration suggéré :

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

etc.

Ensuite, ce serait simple à mettre en œuvre.

@zeripath l'approche que vous avez définie me semble raisonnable et devrait couvrir la plupart des cas d'informations exposées, si les modifications de configuration implémentées affectent également l'API-Access.

De notre côté, nous pensons que ce problème est un grave problème de sécurité.

Gitea divulgue des informations personnelles critiques : prénom, nom, identifiant, e-mail, date de création (quand ils ont rejoint notre organisation).

Dans notre cas, Gitea utilise l'authentification LDAP et diffuse essentiellement toutes les informations de nos membres, sans aucun moyen de limiter/arrêter cette fuite.

REQUIRE_SIGNIN_VIEW n'est pas utilisable car il casse les référentiels publics. Le blocage du point de terminaison /api/v1/users/search interrompt la possibilité d'ajouter un utilisateur à un référentiel.

Il serait vraiment apprécié d'avoir au moins un moyen de limiter la fuite aux utilisateurs authentifiés.

@fluboi pour l'instant, vous pouvez limiter l'accès à l'API aux utilisateurs authentifiés

EDIT : on dirait qu'il n'y a pas de paramètre pour l'API uniquement :/

C'est plus que décevant de voir des gens commenter à plusieurs reprises ce problème sans proposer de spécification ou de configuration proposée, ou commenter les lacunes ou les améliorations de ma spécification proposée ici : (https://github.com/go-gitea/gitea/issues/2908 #issuecomment-670616617)

S'il y avait eu plus de réponses et de considération à mon commentaire en travaillant ensemble sur ce qui était nécessaire et ce qui fonctionnerait, cela aurait été réalisable il y a des mois.

Dans l'état actuel des choses, j'ai proposé un PR pour clore cela, mais je ne sais pas si cela est suffisant.

Merci pour votre travail @zeripath et désolé pour mon précédent commentaire décevant.
D'après ce que j'ai compris, votre RP répond à nos besoins.
Merci encore

S'il y avait eu plus de réponse et de considération à mon commentaire en travaillant ensemble

Je pense que la raison n'est pas la paresse ou l'intention malveillante, mais plutôt le manque de compréhension du backend et peut-être même de la langue dans laquelle il est écrit. Pour autant que j'ai pu le voir, la plupart des gens ici n'ont aucune idée de Go, car ils sont uniquement les utilisateurs de ce serveur et non les développeurs.
Je ne peux pas trop parler de tous ces gens que je ne connais pas, mais je peux parler pour moi :
Je ne comprends pas le backend de Gitea et je ne veux pas m'impliquer avec Go, car je n'aime pas le langage et il y a déjà des tonnes de programmeurs Go, de toute façon, donc pas besoin de faire autre chose dans la vie, inutilement. Par exemple, si le backend était écrit en Nim, je serais prêt à contribuer avec plaisir, peut-être même à résoudre ce problème moi-même, car Nim est en fait un plaisir et un pur plaisir, tandis que Go est une pure corvée et ennui, pour moi personnellement. Cependant, si tel était le cas, probablement tous les contributeurs actuels partiraient, car ils préfèrent rester avec Go.

Je pense également que cela n'a pas beaucoup de sens pour les personnes qui ajoutent des idées aléatoires concernant l'implémentation, s'ils n'ont aucune idée de la structure du backend et/ou du langage. Il est probablement préférable que les personnes les mieux informées décident de la mise en œuvre, en particulier en ce qui concerne les fonctionnalités axées sur la sécurité, qui sont généralement importantes pour être mises en œuvre correctement et pas nécessairement magnifiquement.

Bien sûr, il s'agit d'un projet open source et vous ou tout autre contributeur n'avez aucune obligation de mettre en œuvre quoi que ce soit, sauf peut-être pour les gros sponsors, qui ne sponsorisent autant pour ces avantages. Je pense que nous comprenons tous cela.
Cependant, les gens ici interviennent, expliquant leur problème, soulignant l'importance de celui-ci, dans l'espoir que la direction de Gitea s'attaquera à ce problème dès que possible, au lieu de tant d'autres problèmes dans ce référentiel qui sont plutôt traités. Donc tout ce que les gens ici demandent, ce n'est pas de faire plus de travail, mais juste de changer l'orientation des problèmes. Simplement : éliminez un autre problème et résolvez celui-ci à la place.

C'est pourquoi je pense qu'il est valable d'intervenir ici, en soulignant l'importance de cette question, même si cette personne qui publie un commentaire n'a pas le temps, l'intérêt ou tout simplement pas les connaissances pour aider à la mise en œuvre. La plupart des gens ici ne sont que des utilisateurs, comme moi aussi.

Je pense que la raison n'est pas la paresse ou l'intention malveillante, mais plutôt le manque de compréhension du backend et peut-être même de la langue dans laquelle il est écrit. Pour autant que j'ai pu le voir, la plupart des gens ici n'ont aucune idée de Go, car ils sont uniquement les utilisateurs de ce serveur et non les développeurs.

Je ne peux pas être plus d'accord. Je suis développeur mais pas en Go et je n'ai pas pris le temps de me familiariser avec le code de base et le fonctionnement de l'application donc il serait certainement contre-productif de commenter l'implémentation et là je n'ai fait que relayer mon besoin utilisateur !
Mais j'apprécie VRAIMENT le travail effectué (maintenir d'autres projets open source, je sais que ce n'est pas une tâche facile et les retours des utilisateurs ne sont pas toujours ceux que l'on attend !).

Veuillez vous en tenir au sujet, si vous n'avez rien à ajouter sur un problème spécifique, veuillez ne pas commenter.

Juste un petit mot et espérons mettre fin à cette discussion hors sujet : aucun des contributeurs de Gitea