Lorawan-stack: У нового пользователя (администратора) нет разрешений в консоли

Созданный на 14 авг. 2019  ·  6Комментарии  ·  Источник: TheThingsNetwork/lorawan-stack

Резюме

При создании пользователя-администратора в CLI может случиться так, что у этого пользователя недостаточно прав в Консоли для создания или редактирования шлюзов и приложений. В другом случае у нового обычного пользователя также нет разрешений на выполнение каких-либо действий в консоли. Это может быть ошибка или просто отсутствует документация о том, как правильно создавать пользователей.

Действия по воспроизведению

Я не совсем уверен. Здесь два случая, которые могут быть связаны с одной и той же причиной. В первом случае я работаю на машине, которая не была настроена мной, и у меня ограниченная информация о процессе.

Случай 1: внешний стек; установить как версию 3.0.0 и обновить до 3.1.0 перед использованием консоли.

  1. настроить ttn 3.0.0 после начала работы с cli
  2. обновить до 3.1.0
  3. настроить консольный клиент (и потенциально испортить его *)
  4. создать пользователя --admin (
    5. Войдите в консоль и попробуйте создать шлюз.

* При обновлении произошло то, что процесс создания консоли был выполнен с неправильным uris, поэтому мы удалили консольный клиент из базы данных и повторно использовали команду is-db . Может быть, мы напортачили здесь.

Случай 2 : в моей настройке:

  1. настроить ttn после начала работы
  2. создайте обычного пользователя ttn-lw-cli users create norman --name norman --primary-email-address norman@localhost , используя пользователя admin с самого начала
  3. попробуйте создать шлюз или приложение

Что ты видишь сейчас?

В любом случае консоль отвечает Insufficient rights for user 'myuser' после ввода данных и нажатия кнопки Create Gateway или Create Application .

В консоли браузера нет ничего необычного. На вкладке сети отображается ответ 403 Forbidden от ttn.

При создании приложения через интерфейс командной строки с пользователем-администратором и назначении его соответствующему пользователю пользователь может видеть приложение/шлюз, но при нажатии на него появляется ошибка 403 Forbidden.

Что вы хотите видеть вместо этого?

В любом случае я ожидаю, что новый созданный пользователь сможет по крайней мере создавать шлюзы и приложения для себя и иметь возможность открывать свои представления при добавлении в качестве соавтора.

Я также ожидаю больше документации о процессе создания пользователя и о том, как управлять правами пользователя.

Окружающая обстановка

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

Конфигурация случая 1:
стек-config.txt

Как вы предлагаете это реализовать?

К сожалению, я понятия не имею, где проблема.

Можете ли вы сделать это самостоятельно и отправить запрос на слияние?

Возможно, я не смогу реализовать исправление, но я могу предоставить документацию по созданию пользователей и управлению правами.

picture w4tsn

Самый полезный комментарий

Если пользователь создается администратором, поля state (и admin ) берутся буквально из запроса. Это работает так, как предполагалось, поскольку мы не знаем, установил ли администратор явно state на REQUESTED или просто пропустил его.

Если пользователь не создан администратором, мы предполагаем, что его цель — получить одобрение, и делаем это автоматически, если этому ничто не препятствует (требование одобрения администратором). Они никогда не смогут сделать себя администратором с самого начала.

Функция «создать пользователя администратором» в веб-интерфейсе сделает более понятным, что поле state необходимо установить, но я думаю, что было бы неплохо иметь более разумное значение по умолчанию, чем REQUESTED , так что давайте изменим CLI и сделаем флаг state users create APPROVED по умолчанию.

picture htdvisser 14 авг. 2019
👍2

Все 6 Комментарий

@ w4tsn какая у вас конфигурация? Требуется ли вам одобрение администратора для новых пользователей?

Можете ли вы показать вывод $ ttn-lw-cli user get myuser --state ?

johanstokking picture johanstokking 14 авг. 2019

Дело 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"
}

Случай 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"
}

Я обновлю раздел env моей конфигурацией case 1. В случае 2 я также явно не устанавливал одобрение администратора. Требуется одобрение администратора состояния конфигурации = false

w4tsn picture w4tsn 14 авг. 2019

Я могу подтвердить, что проблема может быть воспроизведена на 3.1.0.
Возможным решением является использование следующей команды ручной активации: ttn-lw-cli users set norman --state=STATE_APPROVED . Я скоро посмотрю, почему это происходит.

Кроме того, в приведенных выше выводах, поскольку состояние не упоминается, оно равно нулю, что означает STATE_REQUESTED , поэтому пользователи фактически не активированы.

adriansmares picture adriansmares 14 авг. 2019
👍1

Так же нашел причину:
https://github.com/TheThingsNetwork/lorawan-stack/blob/55381c15f6902508ea34cd40441ad2bd3146ac37/pkg/identityserver/user_registry.go#L149 -L156
Пользователи, созданные администратором, не соблюдают настройку одобрения администратором и всегда имеют состояние по умолчанию ( STATE_REQUESTED ). Это предназначено для @htdvisser ?

adriansmares picture adriansmares 14 авг. 2019

Если пользователь создается администратором, поля state (и admin ) берутся буквально из запроса. Это работает так, как предполагалось, поскольку мы не знаем, установил ли администратор явно state на REQUESTED или просто пропустил его.

Если пользователь не создан администратором, мы предполагаем, что его цель — получить одобрение, и делаем это автоматически, если этому ничто не препятствует (требование одобрения администратором). Они никогда не смогут сделать себя администратором с самого начала.

Функция «создать пользователя администратором» в веб-интерфейсе сделает более понятным, что поле state необходимо установить, но я думаю, что было бы неплохо иметь более разумное значение по умолчанию, чем REQUESTED , так что давайте изменим CLI и сделаем флаг state users create APPROVED по умолчанию.

htdvisser picture htdvisser 14 авг. 2019
👍2

С #1190, который включает в себя функциональность, описанную в моем предыдущем комментарии, я думаю, что теперь эту проблему можно закрыть.

htdvisser picture htdvisser 27 авг. 2019
Была ли эта страница полезной?
0 / 5 - 0 рейтинги

Смежные вопросы

htdvisser picture htdvisser  ·  9Комментарии
johanstokking picture johanstokking  ·  8Комментарии
ecities picture ecities  ·  5Комментарии
johanstokking picture johanstokking  ·  5Комментарии
ecities picture ecities  ·  5Комментарии