Lorawan-stack: Le nouvel utilisateur (administrateur) n'a aucune autorisation dans la console

Créé le 14 août 2019  ·  6Commentaires  ·  Source: TheThingsNetwork/lorawan-stack

Résumé

Lors de la création d'un utilisateur admin dans la CLI, il peut arriver que cet utilisateur ne dispose pas de droits suffisants dans la console pour créer ou modifier des passerelles et des applications. Dans un autre cas, un nouvel utilisateur normal n'a également aucune autorisation dans la console pour faire quoi que ce soit. Il peut s'agir d'un bogue ou simplement d'une documentation manquante sur la façon de créer correctement des utilisateurs.

Étapes à suivre pour reproduire

Je ne suis pas tout à fait sûr. Il s'agit ici de deux cas qui peuvent être liés à la même cause. Dans le premier cas, j'opère sur une machine qui n'a pas été configurée par moi et j'ai des informations limitées sur le processus.

Cas 1 : pile étrangère ; configuré en tant que version 3.0.0 et mis à niveau vers 3.1.0 avant d'utiliser la console.

  1. configuration ttn 3.0.0 suivant cli pour commencer
  2. mise à jour vers 3.1.0
  3. configurer le client de la console (et potentiellement le gâcher *)
  4. créer --admin utilisateur (
    5. Connectez-vous à la console et essayez de créer une passerelle.

* Ce qui s'est passé lors de la mise à niveau, c'est que le processus de création de la console a été effectué avec de mauvais uri, nous avons donc supprimé le client de la console dans la base de données et réutilisé la commande is-db . Peut-être qu'on a merdé ici.

Cas 2 : Sur ma configuration :

  1. configurer ttn après la mise en route
  2. créer un utilisateur normal ttn-lw-cli users create norman --name norman --primary-email-address norman@localhost en utilisant l'utilisateur admin depuis le démarrage
  3. essayez de créer une passerelle ou une application

Que voyez-vous maintenant ?

Dans les deux cas, la console répond par Insufficient rights for user 'myuser' après avoir entré les détails et appuyé sur le bouton Create Gateway ou Create Application .

Dans la console du navigateur, il n'y a rien d'inhabituel. L'onglet réseau affiche une réponse 403 Forbidden de ttn.

Lors de la création d'une application via la CLI avec l'utilisateur admin et de son attribution à l'utilisateur en question, l'utilisateur peut voir l'application/passerelle mais cliquer dessus génère un 403 Forbidden.

Que veux-tu voir à la place ?

Dans tous les cas, je m'attendrais à ce qu'un nouvel utilisateur créé puisse au moins créer des passerelles et des applications pour lui-même et puisse ouvrir ses vues lorsqu'il est ajouté en tant que collaborateur.

Je m'attendrais également à plus de documentation sur le processus de création d'utilisateurs et sur la gestion des droits des utilisateurs.

Environnement

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

Configuration du cas 1 :
pile-config.txt

Comment proposez-vous de mettre cela en œuvre ?

Malheureusement, je n'ai aucune idée d'où vient le problème.

Pouvez-vous le faire vous-même et soumettre une demande d'extraction ?

Je ne suis peut-être pas en mesure d'implémenter un correctif, mais je peux fournir la documentation pour la création d'utilisateurs et la gestion des droits.

ucli
Source
picture w4tsn

Commentaire le plus utile

Si un utilisateur est créé par un administrateur, les champs state (et admin ) sont extraits littéralement de la requête. Cela fonctionne comme prévu, car nous ne savons pas si l'administrateur a explicitement défini le state sur REQUESTED ou s'il l'a simplement omis.

Si l'utilisateur n'est pas créé par un administrateur, nous supposons que son objectif est d'être approuvé, et le faisons automatiquement si rien (exigence d'approbation de l'administrateur) ne l'empêche. Ils ne peuvent jamais se faire administrateur dès le départ.

La fonctionnalité "créer un utilisateur par administrateur" dans l'interface utilisateur Web indiquera plus clairement que le champ state doit être défini, mais je pense que ce serait une bonne idée d'avoir une valeur par défaut plus saine que REQUESTED , alors changeons la CLI et faisons le drapeau state de users create APPROVED par défaut.

picture htdvisser le 14 août 2019
👍2

Tous les 6 commentaires

@w4tsn quelle est votre configuration ? Avez-vous besoin de l'approbation de l'administrateur pour les nouveaux utilisateurs ?

Pouvez-vous montrer la sortie de $ ttn-lw-cli user get myuser --state ?

johanstokking picture johanstokking le 14 août 2019

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

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

Je mettrai à jour la section env avec la configuration de mon cas 1. Dans le cas 2, je n'ai pas non plus défini explicitement l'approbation de l'administrateur. L'approbation de l'administrateur de l'état de la configuration est requise = false

w4tsn picture w4tsn le 14 août 2019

Je peux confirmer que le problème peut être reproduit sur 3.1.0.
Une solution possible consiste à utiliser la commande d'activation manuelle suivante : ttn-lw-cli users set norman --state=STATE_APPROVED . Je vais voir pourquoi cela se produit bientôt.

De plus, dans les sorties ci-dessus, puisque l'état n'est pas mentionné, il est égal à zéro, ce qui signifie STATE_REQUESTED , donc les utilisateurs ne sont pas réellement activés.

adriansmares picture adriansmares le 14 août 2019
👍1

A également trouvé la cause :
https://github.com/TheThingsNetwork/lorawan-stack/blob/55381c15f6902508ea34cd40441ad2bd3146ac37/pkg/identityserver/user_registry.go#L149 -L156
Les utilisateurs créés par un administrateur ne respectent pas le paramètre d'approbation de l'administrateur et ont toujours un état par défaut ( STATE_REQUESTED ). Est-ce voulu @htdvisser ?

adriansmares picture adriansmares le 14 août 2019

Si un utilisateur est créé par un administrateur, les champs state (et admin ) sont extraits littéralement de la requête. Cela fonctionne comme prévu, car nous ne savons pas si l'administrateur a explicitement défini le state sur REQUESTED ou s'il l'a simplement omis.

Si l'utilisateur n'est pas créé par un administrateur, nous supposons que son objectif est d'être approuvé, et le faisons automatiquement si rien (exigence d'approbation de l'administrateur) ne l'empêche. Ils ne peuvent jamais se faire administrateur dès le départ.

La fonctionnalité "créer un utilisateur par administrateur" dans l'interface utilisateur Web indiquera plus clairement que le champ state doit être défini, mais je pense que ce serait une bonne idée d'avoir une valeur par défaut plus saine que REQUESTED , alors changeons la CLI et faisons le drapeau state de users create APPROVED par défaut.

htdvisser picture htdvisser le 14 août 2019
👍2

Avec #1190, qui inclut la fonctionnalité que j'ai décrite dans mon commentaire précédent, je pense que ce problème peut maintenant être clos.

htdvisser picture htdvisser le 27 août 2019
Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

MatteMoveSRL picture MatteMoveSRL  ·  7Commentaires
johanstokking picture johanstokking  ·  3Commentaires
ZeroSum24 picture ZeroSum24  ·  3Commentaires
ecities picture ecities  ·  5Commentaires
htdvisser picture htdvisser  ·  4Commentaires