Lorawan-stack: El nuevo usuario (administrador) no tiene permisos en la Consola

Creado en 14 ago. 2019  ·  6Comentarios  ·  Fuente: TheThingsNetwork/lorawan-stack

Resumen

Al crear un usuario administrador en la CLI, puede suceder que este usuario no tenga suficientes derechos en la Consola para crear o editar Gateways y Aplicaciones. En otro caso, un nuevo usuario normal tampoco tiene permisos en la consola para hacer nada. Puede ser un error o simplemente falta documentación sobre cómo crear usuarios correctamente.

Pasos para reproducir

No estoy completamente seguro. Son dos casos aquí que pueden estar relacionados con la misma causa. En el primer caso, estoy operando en una máquina que no configuré y tengo información limitada sobre el proceso.

Caso 1: pila extranjera; configurado como versión 3.0.0 y actualizado a 3.1.0 antes de usar la consola.

  1. configuración ttn 3.0.0 siguiente cli para comenzar
  2. actualizar a 3.1.0
  3. configurar el cliente de la consola (y potencialmente arruinarlo *)
  4. crear --admin usuario (
    5. Inicie sesión en la consola e intente crear una puerta de enlace.

*Lo que sucedió en la actualización fue que el proceso de creación de la consola se realizó con uris incorrectos, por lo que eliminamos el cliente de la consola en la base de datos y reutilizamos el comando is-db . Tal vez nos equivocamos aquí.

Caso 2 : en mi configuración:

  1. configuración ttn después de la introducción
  2. cree un usuario normal ttn-lw-cli users create norman --name norman --primary-email-address norman@localhost usando el usuario administrador desde el inicio
  3. intente crear una puerta de enlace o aplicación

¿Qué ves ahora?

En cualquier caso, la consola responde con Insufficient rights for user 'myuser' después de ingresar los detalles y presionar el botón Create Gateway o Create Application .

En la consola del navegador no hay nada raro. La pestaña de red muestra una respuesta 403 Prohibida de ttn.

Al crear una aplicación a través de la CLI con el usuario administrador y asignarla al usuario en cuestión, el usuario puede ver la aplicación/puerta de enlace, pero al hacer clic en ella, aparece un 403 Prohibido.

¿Qué quieres ver en su lugar?

En cualquier caso, espero que un nuevo usuario creado pueda al menos crear puertas de enlace y aplicaciones para sí mismo y poder abrir sus vistas cuando se agregue como colaborador.

También esperaría más documentación sobre el proceso de creación de usuarios y cómo administrar los derechos de los usuarios.

Ambiente

The Things Network Stack for LoRaWAN: ttn-lw-stack
Version:             3.1.0
Go version:          go1.12.7
OS/Arch:             linux/amd64

Configuración del caso 1:
pila-config.txt

¿Cómo propone implementar esto?

Lamentablemente no tengo ni idea de dónde está el problema.

¿Puedes hacerlo tú mismo y enviar una solicitud de extracción?

Es posible que no pueda implementar una solución, pero puedo proporcionar la documentación para la creación de usuarios y la gestión de derechos.

ucli

Comentario más útil

Si un administrador crea un usuario, los campos state (y admin ) se toman literalmente de la solicitud. Esto funciona según lo previsto, ya que no sabemos si el administrador estableció explícitamente state en REQUESTED o simplemente lo omitió.

Si el usuario no es creado por un administrador, asumimos que su objetivo es obtener la aprobación y lo hacemos automáticamente si nada (requisito de aprobación del administrador) lo impide. Nunca pueden convertirse en administradores desde el principio.

La funcionalidad "crear usuario por administrador" en la interfaz de usuario web dejará más claro que el campo state debe configurarse, pero creo que sería una buena idea tener un valor predeterminado más sensato que REQUESTED , así que cambiemos la CLI y hagamos que el indicador state sea users create APPROVED de forma predeterminada.

Todos 6 comentarios

@ w4tsn ¿cuál es su configuración? ¿Necesita la aprobación del administrador para los nuevos usuarios?

¿Puedes mostrar la salida de $ ttn-lw-cli user get myuser --state ?

Caso 1:

{
  "ids": {
    "user_id": "someadmin"
  },
  "created_at": "2019-08-14T07:20:10.542Z",
  "updated_at": "2019-08-14T07:20:10.542Z",
  "password_updated_at": "0001-01-01T00:00:00Z"
}

Caso 2:

{
  "ids": {
    "user_id": "myuser"
  },
  "created_at": "2019-08-06T10:30:34.091Z",
  "updated_at": "2019-08-06T10:30:34.091Z",
  "password_updated_at": "0001-01-01T00:00:00Z"
}

Actualizaré la sección env con la configuración de mi caso 1. En el caso 2, tampoco configuré explícitamente la aprobación del administrador. Se requiere la aprobación del administrador del estado de configuración = falso

Puedo confirmar que el problema se puede reproducir en 3.1.0.
Una posible solución es usar el siguiente comando de activación manual: ttn-lw-cli users set norman --state=STATE_APPROVED . Voy a investigar por qué sucede esto pronto.

Además, en las salidas anteriores, dado que el estado no se menciona, es cero, lo que significa STATE_REQUESTED , por lo que los usuarios no están realmente activados.

También encontré la causa:
https://github.com/TheThingsNetwork/lorawan-stack/blob/55381c15f6902508ea34cd40441ad2bd3146ac37/pkg/identityserver/user_registry.go#L149 -L156
Los usuarios creados por un administrador no respetan la configuración de aprobación del administrador y siempre tienen un estado predeterminado ( STATE_REQUESTED ). ¿Es esto intencionado @htdvisser ?

Si un administrador crea un usuario, los campos state (y admin ) se toman literalmente de la solicitud. Esto funciona según lo previsto, ya que no sabemos si el administrador estableció explícitamente state en REQUESTED o simplemente lo omitió.

Si el usuario no es creado por un administrador, asumimos que su objetivo es obtener la aprobación y lo hacemos automáticamente si nada (requisito de aprobación del administrador) lo impide. Nunca pueden convertirse en administradores desde el principio.

La funcionalidad "crear usuario por administrador" en la interfaz de usuario web dejará más claro que el campo state debe configurarse, pero creo que sería una buena idea tener un valor predeterminado más sensato que REQUESTED , así que cambiemos la CLI y hagamos que el indicador state sea users create APPROVED de forma predeterminada.

Con el #1190, que incluye la funcionalidad que describí en mi comentario anterior, creo que ahora se puede cerrar este problema.

¿Fue útil esta página
0 / 5 - 0 calificaciones