Lorawan-stack: 新規(管理者)ユーザーにはコンソールでの権限がありません

作成日 2019年08月14日  ·  6コメント  ·  ソース: TheThingsNetwork/lorawan-stack

概要

CLIで管理者ユーザーを作成する場合、このユーザーがゲートウェイとアプリケーションを作成または編集するための十分な権限をコンソールで持っていない可能性があります。 別のケースでは、新しい通常のユーザーには、コンソールに何もする権限がありません。 バグであるか、ユーザーを適切に作成する方法に関するドキュメントが不足している可能性があります。

再現する手順

よくわかりません。 同じ原因に関連している可能性があるのは、ここでは2つのケースです。 最初のケースでは、自分でセットアップしていないマシンで操作しており、プロセスに関する情報が限られています。

ケース1:外部スタック。 コンソールを使用する前に、バージョン3.0.0としてセットアップし、3.1.0にアップグレードしてください。

  1. cliの開始後にttn3.0.0をセットアップします
  2. 3.1.0にアップデート
  3. コンソールクライアントをセットアップします(そして潜在的にそれを台無しにします*)
  4. --adminユーザーを作成します(
    5.コンソールにログインし、ゲートウェイの作成を試みます。

*アップグレード時に発生したのは、コンソールの作成プロセスが間違ったURIで行われたため、データベース内のコンソールクライアントを削除し、 is-dbコマンドを再利用しました。 たぶん私たちはここで台無しにした。

ケース2 :私のセットアップで:

  1. 開始後にttnを設定する
  2. はじめから管理者ユーザーを使用して、通常のユーザーttn-lw-cli users create norman --name norman --primary-email-address norman@localhostを作成します
  3. ゲートウェイまたはアプリケーションを作成してみてください

あなたは今何を見ていますか?

いずれの場合も、コンソールは詳細を入力してCreate GatewayまたはCreate Applicationボタンを押した後、 Insufficient rights for user 'myuser'で応答します。

ブラウザコンソールでは、異常なことは何もありません。 ネットワークタブには、ttnからの403Forbidden応答が表示されます。

管理者ユーザーを使用してCLIを介してアプリケーションを作成し、それを問題のユーザーに割り当てると、ユーザーにはアプリケーション/ゲートウェイが表示される場合がありますが、それをクリックすると403Forbiddenが表示されます。

代わりに何を見たいですか?

いずれにせよ、新しく作成されたユーザーは、少なくとも自分自身のゲートウェイとアプリケーションを作成でき、共同編集者として追加されたときにビューを開くことができると期待しています。

また、ユーザー作成プロセスとユーザー権限の管理方法に関するドキュメントが増えることを期待しています。

環境

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

ケース1の構成:
stack-config.txt

これをどのように実装することを提案しますか?

残念ながら、問題がどこにあるのかわかりません。

これを自分で行い、プルリクエストを送信できますか?

修正を実装できない場合がありますが、ユーザー作成と権利管理のドキュメントを提供できます。

ucli

最も参考になるコメント

ユーザーが管理者によって作成された場合、 state (およびadmin )フィールドは文字通りリクエストから取得されます。 管理者がstateREQUESTEDに明示的に設定したのか、それとも単に省略したのかわからないため、これは意図したとおりに機能します。

ユーザーが管理者によって作成されていない場合、ユーザーの目標は承認を受けることであると想定し、それを妨げるものがない場合(管理者の承認要件)は自動的にそれを行います。 彼らは最初から自分自身を管理者にすることはできません。

Web UIの「管理者によるユーザーの作成」機能により、 stateフィールドを設定する必要があることがより明確になりますが、 REQUESTEDよりも適切なデフォルトを設定することをお勧めします。 users create APPROVEDstateフラグを作成しましょう。

全てのコメント6件

@ w4tsnあなたの設定は何ですか? 新規ユーザーの管理者の承認が必要ですか?

$ ttn-lw-cli user get myuser --stateの出力を表示できますか?

ケース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"
}

ケース1の構成でenvセクションを更新します。 ケース2では、管理者の承認も明示的に設定しませんでした。 構成状態の管理者の承認が必要= false

3.1.0でも問題が再現できることを確認できました。
考えられる修正は、次の手動アクティベーションコマンドを使用することです: ttn-lw-cli users set norman --state=STATE_APPROVED 。 なぜこれがすぐに起こるのかを調べます。

また、上記の出力では、状態が記載されていないため、ゼロになります。つまり、 STATE_REQUESTEDであるため、ユーザーは実際にはアクティブ化されません。

また、原因を見つけました:
https://github.com/TheThingsNetwork/lorawan-stack/blob/55381c15f6902508ea34cd40441ad2bd3146ac37/pkg/identityserver/user_registry.go#L149 -L156
管理者によって作成されたユーザーは、管理者の承認設定を尊重せず、常に状態のデフォルト( STATE_REQUESTED )を持ちます。 これは@htdvisserを対象としていますか?

ユーザーが管理者によって作成された場合、 state (およびadmin )フィールドは文字通りリクエストから取得されます。 管理者がstateREQUESTEDに明示的に設定したのか、それとも単に省略したのかわからないため、これは意図したとおりに機能します。

ユーザーが管理者によって作成されていない場合、ユーザーの目標は承認を受けることであると想定し、それを妨げるものがない場合(管理者の承認要件)は自動的にそれを行います。 彼らは最初から自分自身を管理者にすることはできません。

Web UIの「管理者によるユーザーの作成」機能により、 stateフィールドを設定する必要があることがより明確になりますが、 REQUESTEDよりも適切なデフォルトを設定することをお勧めします。 users create APPROVEDstateフラグを作成しましょう。

以前のコメントで説明した機能を含む#1190を使用すると、この問題を解決できると思います。

このページは役に立ちましたか?
0 / 5 - 0 評価

関連する問題

johanstokking picture johanstokking  ·  3コメント

thinkOfaNumber picture thinkOfaNumber  ·  4コメント

bafonins picture bafonins  ·  5コメント

kschiffer picture kschiffer  ·  7コメント

htdvisser picture htdvisser  ·  4コメント