Lorawan-stack: O novo usuário (admin) não tem permissões no console

Criado em 14 ago. 2019  ·  6Comentários  ·  Fonte: TheThingsNetwork/lorawan-stack

Resumo

Ao criar um usuário admin na CLI pode acontecer que este usuário não tenha direitos suficientes no Console para criar ou editar Gateways e Aplicativos. Em outro caso, um novo usuário normal também não tem permissões no console para fazer nada. Pode ser um bug ou apenas falta de documentação sobre como criar usuários corretamente.

Passos para reproduzir

Eu não tenho certeza. São dois casos aqui que podem estar relacionados à mesma causa. No primeiro caso estou operando em uma máquina que não foi configurada por mim e tenho informações limitadas sobre o processo.

Caso 1: pilha estrangeira; configurado como versão 3.0.0 e atualizado para 3.1.0 antes de usar o Console.

  1. configuração ttn 3.0.0 seguindo cli começando
  2. atualizar para 3.1.0
  3. configurar o cliente do console (e potencialmente estragar tudo*)
  4. criar --admin usuário (
    5 .faça login no console e tente criar um Gateway.

*O que aconteceu na atualização foi que o processo de criação do console foi feito com uris errados, então excluímos o cliente do console no banco de dados e reutilizamos o comando is-db . Talvez tenhamos estragado tudo aqui.

Caso 2 : Na minha configuração:

  1. configurar ttn seguindo os primeiros passos
  2. crie um usuário normal ttn-lw-cli users create norman --name norman --primary-email-address norman@localhost usando o usuário admin desde o início
  3. tente criar um gateway ou aplicativo

O que você vê agora?

Em ambos os casos, o Console responde com Insufficient rights for user 'myuser' após inserir os detalhes e pressionar o botão Create Gateway ou Create Application .

No console do navegador não há nada incomum. A guia de rede mostra uma resposta 403 Forbidden de ttn.

Ao criar um aplicativo na CLI com o usuário admin e atribuí-lo ao usuário em questão, o usuário pode ver o aplicativo/gateway, mas clicar nele produz um 403 Forbidden.

O que você quer ver em vez disso?

De qualquer forma, eu esperaria que um novo usuário criado pudesse pelo menos criar gateways e aplicativos para si mesmo e poder abrir suas visualizações quando adicionado como colaborador.

Eu também esperaria mais documentação sobre o processo de criação de usuários e como gerenciar os direitos do usuário.

Ambiente

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

Configuração do caso 1:
stack-config.txt

Como você se propõe a implementar isso?

Infelizmente não faço ideia de onde está o problema.

Você pode fazer isso sozinho e enviar um Pull Request?

Posso não conseguir implementar uma correção, mas posso fornecer a documentação para a criação do usuário e o gerenciamento de direitos.

ucli
Fonte
picture w4tsn

Comentários muito úteis

Se um usuário for criado por um administrador, os campos state (e admin ) serão retirados literalmente da solicitação. Isso funciona como pretendido, pois não sabemos se o administrador definiu explicitamente o state REQUESTED ou apenas o deixou de fora.

Se o usuário não for criado por um administrador, assumimos que seu objetivo é ser aprovado e fazer isso automaticamente se nada (requisito de aprovação do administrador) impedir isso. Eles nunca podem se tornar administradores desde o início.

A funcionalidade "criar usuário por administrador" na interface do usuário da web deixará mais claro que o campo state precisa ser definido, mas acho que seria uma boa ideia ter um padrão mais sensato do que REQUESTED , então vamos alterar a CLI e fazer o sinalizador state de users create APPROVED por padrão.

picture htdvisser em 14 ago. 2019
👍2

Todos 6 comentários

@w4tsn qual é a sua configuração? Você está exigindo aprovação do administrador para novos usuários?

Você pode mostrar a saída de $ ttn-lw-cli user get myuser --state ?

johanstokking picture johanstokking em 14 ago. 2019

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"
}

Vou atualizar a seção env com a configuração do meu caso 1. No caso 2, também não defini explicitamente a aprovação do administrador. A aprovação do administrador do estado de configuração necessária = false

w4tsn picture w4tsn em 14 ago. 2019

Posso confirmar que o problema pode ser reproduzido em 3.1.0.
Uma possível correção é usar o seguinte comando de ativação manual: ttn-lw-cli users set norman --state=STATE_APPROVED . Vou investigar por que isso acontece em breve.

Além disso, nas saídas acima, como o estado não é mencionado, é zero, o que significa STATE_REQUESTED , portanto, os usuários não são realmente ativados.

adriansmares picture adriansmares em 14 ago. 2019
👍1

Também encontrei a causa:
https://github.com/TheThingsNetwork/lorawan-stack/blob/55381c15f6902508ea34cd40441ad2bd3146ac37/pkg/identityserver/user_registry.go#L149 -L156
Os usuários criados por um administrador não respeitam a configuração de aprovação do administrador e sempre têm o estado padrão ( STATE_REQUESTED ). Isso é pretendido @htdvisser ?

adriansmares picture adriansmares em 14 ago. 2019

Se um usuário for criado por um administrador, os campos state (e admin ) serão retirados literalmente da solicitação. Isso funciona como pretendido, pois não sabemos se o administrador definiu explicitamente o state REQUESTED ou apenas o deixou de fora.

Se o usuário não for criado por um administrador, assumimos que seu objetivo é ser aprovado e fazer isso automaticamente se nada (requisito de aprovação do administrador) impedir isso. Eles nunca podem se tornar administradores desde o início.

A funcionalidade "criar usuário por administrador" na interface do usuário da web deixará mais claro que o campo state precisa ser definido, mas acho que seria uma boa ideia ter um padrão mais sensato do que REQUESTED , então vamos alterar a CLI e fazer o sinalizador state de users create APPROVED por padrão.

htdvisser picture htdvisser em 14 ago. 2019
👍2

Com #1190, que inclui a funcionalidade que descrevi no meu comentário anterior, acho que esse problema pode ser encerrado.

htdvisser picture htdvisser em 27 ago. 2019
Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

johanstokking picture johanstokking  ·  5Comentários
kschiffer picture kschiffer  ·  7Comentários
ecities picture ecities  ·  5Comentários
ecities picture ecities  ·  5Comentários
htdvisser picture htdvisser  ·  9Comentários