Defina "visualización". ¿Se refiere a anuncios como /explore/users ? ¿Qué hay de ellos comentando sobre temas públicos? ¿Quieres que se oculte el comentario? Comprometerse con un repositorio público, ¿no debería mostrarse el compromiso?

(por cierto, ninguno de los dos últimos casos es factible de una manera sensata :))

Creo que esto está destinado a esconderse de explore/users

@bkcsoft Sí, me refiero a /explore/users . Para ti la verdad, me olvidé por completo de este tema. Pude resolverlo usando una plantilla.

Para responder completamente a su pregunta, tengo el usuario root y otros usuarios de "solo lectura" que no quiero que se muestren en la página /explore/users . Si no tienen confirmaciones, están esencialmente ocultas a la vista del público. Quiero evitar que alguien inicie sesión con los usuarios root o de "solo lectura".

Nota:

• Por "solo lectura" me refiero a que tengo cuentas que tienen acceso de solo lectura a los repositorios en mi cuenta principal de Gitea.

@demonpig, ¿podrías publicar un resumen de la plantilla personalizada que estás usando?

@techknowlogick Aquí tienes.
El archivo está en: ${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 gracias

Sería bueno tener, además de una opción que oculta a todos los usuarios de la vista pública, tener una opción para ocultar usuarios específicos de la vista pública. Como las cuentas locales de respaldo cuando tiene habilitado ldap auth = /.

+1
Acabo de encontrar el mismo problema: la cuenta que no es LDAP solo para administradores se muestra de manera destacada en la página de destino. Esto solicita intentos de inicio de sesión "creativos" ...

Sí, sería bueno tener esto. Por ahora, acabo de tener que 403 a cualquiera que visite /explore/users través de NGINX.

FWIW, parece que tanto la comunidad de gitea como la de gogs quieren esto.

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

Negar el acceso a / explore / users solo no resuelve el problema. Aún se pueden encontrar usuarios a través de la API:

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

@shuhaowu ¡ Buena captura! También se olvidó por completo de bloquear el acceso a ese punto final.

Me encantaría ver esto para que el usuario administrador no sea tan destacado.

Para aclarar, ¿este problema con REQUIRE_SIGNIN_VIEW establecido en true o false ?

@davidsiefert No lo creo. Básicamente, ¿se puede agregar una opción de configuración que evite que la raíz o todas las demás cuentas de usuario se muestren tanto desde la API como desde los puntos finales /explore/users ? ¿Quizás Gitea podría configurarse / desarrollarse de una manera en la que solo muestre a los usuarios que han realizado confirmaciones?

… O aquellos que optan por ser publicados.

Esta sería una característica importante para nosotros. Los usuarios no deberían poder ver a otros usuarios.

+1 solicitud para ocultar usuarios de otros excepto del administrador (agregar marca de derechos)

+1

¿Cómo se manejaría eso en API?

+1

+1

Este problema se ha marcado automáticamente como obsoleto porque no ha tenido actividad reciente. Se cerrará si no se realizan más actividades durante las próximas 2 semanas. Gracias por sus aportaciones.

Todavía quería ...

Si. Definitivamente todavía lo quiero.

solución temporal (solo oculta las opciones de las vistas) para aquellos que tienen prisa aquí: https://github.com/gogs/gogs/issues/5080#issuecomment -482657310

para los que tienen prisa aquí: gogs / gogs # 5080

@miqmago ¿cómo evita escribir manualmente "/ explore / users" en el navegador?
Supongo que el parcheo de routes.go (alrededor de https://github.com/go-gitea/gitea/blob/master/routers/routes/routes.go#L247) es obligatorio, ¿no?

Además, el # 6530 se resolvió como duplicado.
Pero me gustaría enfatizar que tener una función de organización privada lanzada, pero con la posibilidad de exponer a todos los usuarios, incluso de cualquier organización privada, debe tratarse como un agujero de seguridad: guiño:

¿Es posible escalar este problema a la rama 1.8.1?

No es un agujero de seguridad, ya que el criterio de aceptación nunca fue ocultar a los usuarios que forman parte de organizaciones ocultas. Para eso es este boleto.

No es un agujero de seguridad

OK :)

Pero, ¿podrían agregarse los criterios para ocultar a los usuarios de una organización privada a otras organizaciones? Puede ser opcional.
O al menos bloqueo opcional de la ruta "/ explore / users" y la plantilla correspondiente ...
Me encantaría verlo en 1.8.x. Lo siento, mis habilidades actuales en Go no son suficientes para contribuir con algunas relaciones públicas :(

@igsol , tienes razón, he actualizado el hilo, por lo que ahora solo los usuarios administradores pueden acceder a él.

En mi punto de vista, eso debería ser algo configurable en el panel de administración del usuario. También creo que esto es bastante complejo y no conozco todas las soluciones propuestas. Seguro que hay múltiples escenarios: permiso para ver a todos los usuarios de una organización a la que pertenece el usuario, para ver a todos los usuarios, para verse solo a sí mismos, usuarios públicos ...

@techknowlogick no sé si este es el lugar correcto para discutirlo y dónde puedo encontrar más información al respecto, pero he leído que esta es una bifurcación de gogs mantenida por la comunidad. No estoy seguro de las diferencias con gogs, cómo integra las nuevas funciones desarrolladas en gogs y por qué debería migrar a gitea o ceñirme a gogs, pros y contras. Tal vez podrías indicarme algún lugar para obtener más información. También decir que no soy un programador experimentado, pero de alguna manera podría contribuir también, es decir, estoy trabajando en traducciones al catalán.

@miqmago Aquí hay una comparación útil sobre lo que ofrece Gitea vs Gogs: https://docs.gitea.io/en-us/comparison/ , así como la publicación del blog de lanzamiento que explica las diferencias en la gobernanza de los proyectos: https: / /blog.gitea.io/2016/12/welcome-to-gitea/

@igsol este ticket no se convertirá en una versión 1.8.x debido a que el proyecto solo incluye correcciones de errores, actualmente estamos trabajando para sacar la versión 1.9.x.

actualmente trabajando para sacar 1.9.x.

@techknowlogick Ok, ya veo, NP.

Hasta ahora, me ayudé a mí mismo haciendo una compilación privada local aplicando mi parche bastante brutal (algo como @miqmago mencionado, pero más simple). Lo principal es implementar este ticket al final :)

De todos modos gracias a todo el equipo por la brillante Gitea.

Lanzamiento de 1.9.0. ¿Existe la posibilidad de llamar la atención sobre este ticket?

@igsol
Este es mi deseo también.

¿Ayudaría esto?

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

¿Ayudaría esto?

8340

¿No ocultaría esto a todos los usuarios de la vista pública?

Solo si REQUIRE_SIGNIN_VIEW es verdadero y no ha iniciado sesión.

Solo si REQUIRE_SIGNIN_VIEW es verdadero y no ha iniciado sesión.

Si REQUIRE_SIGNIN_VIEW es verdadero, de todos modos está oculto. En segundo lugar, aún ocultaría a todos los usuarios, que no es el objetivo de la solicitud. Especialmente, dado que algunos usuarios solo quieren ocultar a un solo usuario y creo que sería un poco exagerado si ocultara TODOS los usuarios creados solo por una cuenta del sistema.

Esta bien perdón.

Entonces, ¿podemos actualizar el problema?

¿Qué se quiere?

una nueva configuración: ALLOW_VIEW_USERS?

¿Qué se quiere?

Idealmente, desde mi punto de vista personal, desearía una configuración que cada usuario pueda establecer así:

...
Ocultar cuenta de la vista pública []
...

Que estaría entre otras configuraciones como _Ocultar dirección de correo electrónico_.

También estaría bien incluirlo en la configuración de administración, aunque creo que hacer que todos puedan decidir es la mejor solución.

Si esto se va a implementar, todos los repositorios de ese usuario deberían volverse privados, lo cual no es un cambio trivial en mi humilde opinión. Por ejemplo, se requiere que los repositorios bifurcados sean públicos si el repositorio de origen es público, por lo que la existencia del usuario se expondrá eventualmente.

Si esto se va a implementar, todos los repositorios de ese usuario deberían volverse privados, lo cual no es un cambio trivial en mi humilde opinión. Por ejemplo, se requiere que los repositorios bifurcados sean públicos si el repositorio de origen es público, por lo que la existencia del usuario se expondrá eventualmente.

Idealmente, esta forma debería ser opcional. Veo casos de uso en los que solo desea _desenlistar_ (como videos _no listados_ en YouTube) a un usuario, lo que significa que no desea que este usuario se muestre de manera prominente como si fuera el rey de su Gitea, pero no tendría ningún problema si estuviera escondido en algún lugar de la jungla de tu Gitea. Este ejemplo es cierto para mi caso.

Idealmente, esta forma debería ser opcional. Veo casos de uso en los que solo desea _desenlistar_ (como videos _no listados_ en YouTube) a un usuario, lo que significa que no desea que este usuario se muestre de manera prominente como si fuera el rey de su Gitea, pero no tendría ningún problema si estuviera escondido en algún lugar de la jungla de tu Gitea. Este ejemplo es cierto para mi caso.

Pero entonces este número debería titularse "Eliminar algunos usuarios de Gitea". 😁

Idealmente, esta forma debería ser opcional. Veo casos de uso en los que solo desea _desenlistar_ (como videos _no listados_ en YouTube) a un usuario, lo que significa que no desea que este usuario se muestre de manera prominente como si fuera el rey de su Gitea, pero no tendría ningún problema si estuviera escondido en algún lugar de la jungla de tu Gitea. Este ejemplo es cierto para mi caso.

Pero entonces este número debería titularse "Eliminar algunos usuarios de Gitea". 😁

Creo que el título más exacto sería "Ocultar o eliminar usuarios de la lista". Ofrecer ambas opciones sería una gran solución.

Estas funciones también deberían estar disponibles para las organizaciones, por supuesto.

+1 para ocultar (todos) los usuarios cuando no estoy iniciando sesión, explorador + API, pero, cuando estoy iniciando sesión, quiero ver (todos) los usuarios.

Yo uso MariaDB.
Con users.tmpl no puedo aplicar lo que quiero, porque, cuando estoy iniciando sesión, no puedo ver a los usuarios también.
La API siempre puede enumerar a todos los usuarios.

Necesito mostrar al usuario desde la vista pública, pero no a todos los usuarios.

cd / etc / gitea
nano app.ini
REQUIRE_SIGNIN_VIEW: verdadero
¡Funciona muy bien! ¡Pero esta opción fue extrema!
Ahora se respeta el aspecto de seguridad, pero preferiríamos poder elegir si ser visible o no, como usuario público o privado.

+1, necesitamos ocultar la pestaña ExplorerUser O elegir qué usuario (local o ldap) debe aparecer en la lista ExplorerUser ... es fácil recuperar el inicio de sesión del usuario y luego forzarlo ... o cualquier otra cosa
Gracias por esta maravillosa herramienta., Gitea

REQUIRE_SIGNIN_VIEW = verdadero

Parece funcionar.

@Braqoon No leíste la conversación. No "hace el truco".

Sería genial si esto pudiera implementarse.
Quiero exponer algunos de mis repositorios (públicos) a personas que no están registradas en mi instancia de gitea, pero no quiero mostrarles a todos mis usuarios registrados (incluido el administrador). Como mencionó @theAkito , simplemente REQUIRE_SIGNIN_VIEW = true no soluciona el problema.

Editar:
Peor aún, acabo de verificar la API-Call curl -X GET "http://gitea/api/v1/users/search" -H "accept: application/json" como lo menciona @shuhaowu. Incluso los usuarios no registrados pueden descubrir fácilmente información crítica como is_admin o last_login . En cuanto a seguridad, esto es absolutamente imposible.

Estoy totalmente de acuerdo en que sería muy útil ocultar posiblemente a los usuarios que no tienen un repositorio público. Digamos que agrego algunos usuarios para comentar sobre problemas en proyectos privados, ¡sería perfecto si pudieran hacerse invisibles en la lista de exploración!

Será genial que no muestre a los usuarios que no tienen repositorio público

Veo muchos comentarios aquí, pero no hay especificaciones ni propuestas sobre cómo está configurado.

Una configuración sensata que pudiera mantener el sistema actual y ofrecer las vistas restringidas propuestas probablemente conduciría a la implementación.

Por ejemplo, un bloque de configuración sugerido:

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

y así.

Entonces sería sencillo de implementar.

@zeripath, el enfoque presentado por usted me parece razonable y debería cubrir la mayoría de los casos de información expuesta, si los cambios de configuración implementados también afectan el acceso a la API.

Por nuestra parte, creemos que este problema es un problema de seguridad grave.

Gitea filtra información personal crítica: nombre, apellido, inicio de sesión, correo electrónico, fecha de creación (cuando se unieron a nuestra organización).

En nuestro caso, Gitea usa autenticación LDAP y básicamente filtra toda la información de nuestros miembros, sin ninguna forma de limitar / detener esa filtración.

REQUIRE_SIGNIN_VIEW no se puede utilizar ya que rompe los repositorios públicos. Bloquear / api / v1 / users / search endpoint rompe la capacidad de agregar un usuario a un repositorio.

Sería muy apreciado tener al menos una forma de limitar la filtración a los usuarios autenticados.

@fluboi, por ahora, podría limitar el acceso a la API a usuarios autenticados

EDITAR: parece que no hay configuración solo para API: /

Es más que decepcionante ver a la gente comentar repetidamente sobre este problema sin ofrecer una especificación o configuración propuesta, o comentar sobre las deficiencias o mejoras a mi especificación propuesta aquí: (https://github.com/go-gitea/gitea/issues/2908 # issuecomment-670616617)

Si hubiera habido más respuesta y consideración a mi comentario trabajando juntos sobre lo que era necesario y lo que funcionaría, esto habría sido implementable hace meses.

Tal como está, he propuesto un RP para cerrar esto, pero no sé si es suficiente.

Gracias por tu trabajo @zeripath y perdón por mi anterior comentario decepcionante.
Por lo que tengo entendido, su RR.PP. satisface nuestras necesidades.
Gracias de nuevo

Si hubiera habido más respuesta y consideración a mi comentario trabajando juntos

Creo que la razón no es la pereza o las intenciones maliciosas, sino la falta de comprensión del backend y tal vez incluso el idioma en el que está escrito. Por lo que he visto, la mayoría de las personas aquí no tienen idea de Go, ya que son solo usuarios de este servidor y no desarrolladores.
No puedo hablar demasiado sobre todas estas personas que no conozco, pero puedo hablar por mí mismo:
No entiendo el backend de Gitea y no quiero involucrarme con Go, porque no me gusta el lenguaje y, de todos modos, ya hay toneladas de programadores de Go, así que no hay necesidad de hacer otra cosa en la vida, innecesariamente. Por ejemplo, si el backend estuviera escrito en Nim , estaría dispuesto a contribuir felizmente, tal vez incluso a solucionar este problema yo mismo, ya que Nim es realmente divertido y puro disfrute, mientras que Go es pura tarea y molestia para mí personalmente. Sin embargo, si ese fuera el caso, probablemente todos los contribuyentes actuales se irían, porque prefieren quedarse con Go.

También creo que no tiene mucho sentido para las personas que agregan ideas aleatorias con respecto a la implementación, si no tienen idea sobre la estructura del backend y / o el lenguaje. Probablemente sea mejor, si los más conocedores deciden sobre la implementación, especialmente en lo que respecta a las características orientadas a la seguridad, que generalmente son importantes para implementarse correctamente y no necesariamente de manera hermosa.

Por supuesto, este es un proyecto de código abierto y usted o cualquier otro contribuyente no tiene ninguna obligación de implementar nada, excepto tal vez para los grandes patrocinadores, que solo patrocinan hasta cierto punto por estos beneficios. Creo que todos lo entendemos.
Sin embargo, la gente aquí interviene, explicando su problema, enfatizando la importancia del mismo, con la esperanza de que el liderazgo de Gitea aborde este problema lo antes posible, en lugar de tantos otros problemas en este repositorio que en su lugar se están abordando. Entonces, todo lo que la gente aquí está pidiendo no es hacer más trabajo, sino simplemente cambiar el enfoque de los problemas. Simplemente: descarte otro problema y, en su lugar, resuelva este.

Es por eso que creo que es válido intervenir aquí, enfatizando la importancia de este tema, incluso si la persona que publica un comentario no tiene tiempo, interés o simplemente no tiene el conocimiento para ayudar con la implementación. La mayoría de las personas aquí son solo usuarios, como yo también.

Creo que la razón no es la pereza o las intenciones maliciosas, sino la falta de comprensión del backend y tal vez incluso el idioma en el que está escrito. Por lo que he visto, la mayoría de las personas aquí no tienen idea de Go, ya que son solo usuarios de este servidor y no desarrolladores.

No puedo estar más de acuerdo. Soy desarrollador, pero no estoy en Go y no me he tomado el tiempo de familiarizarme con el código base y la forma en que funciona la aplicación, por lo que ciertamente sería contraproducente comentar sobre la implementación y luego solo transmití mi necesidad de usuario.
Pero REALMENTE aprecio el trabajo realizado (mantener otros proyectos de código abierto, sé que no es una tarea fácil y los comentarios de los usuarios no siempre son los que esperarías).

Por favor, manténgase en el tema, si no tiene nada que agregar sobre un tema específico, no comente.

Solo una nota al margen y esperemos que termine esta discusión fuera del tema: a ninguno de los colaboradores de Gitea se le paga por desarrollar nuevas funciones o corregir errores, todos lo hacemos en nuestro tiempo libre, así que a menos que alguien esté dispuesto a patrocinar una función o desarrollo específico, todos, incluidos los colaboradores de Gitea, son libres de desarrollar lo que quieran y el "liderazgo" de Gitea no tiene voz sobre lo que otros colaboradores deben hacer cuando dedican su tiempo libre a este proyecto para desarrollar funciones que necesitan o se divierten haciendo.