CLIで管理者ユーザーを作成する場合、このユーザーがゲートウェイとアプリケーションを作成または編集するための十分な権限をコンソールで持っていない可能性があります。 別のケースでは、新しい通常のユーザーには、コンソールに何もする権限がありません。 バグであるか、ユーザーを適切に作成する方法に関するドキュメントが不足している可能性があります。
よくわかりません。 同じ原因に関連している可能性があるのは、ここでは2つのケースです。 最初のケースでは、自分でセットアップしていないマシンで操作しており、プロセスに関する情報が限られています。
ケース1:外部スタック。 コンソールを使用する前に、バージョン3.0.0としてセットアップし、3.1.0にアップグレードしてください。
--admin
ユーザーを作成します(*アップグレード時に発生したのは、コンソールの作成プロセスが間違ったURIで行われたため、データベース内のコンソールクライアントを削除し、 is-db
コマンドを再利用しました。 たぶん私たちはここで台無しにした。
ケース2 :私のセットアップで:
ttn-lw-cli users create norman --name norman --primary-email-address norman@localhost
を作成しますいずれの場合も、コンソールは詳細を入力して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
残念ながら、問題がどこにあるのかわかりません。
修正を実装できない場合がありますが、ユーザー作成と権利管理のドキュメントを提供できます。
@ 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
)フィールドは文字通りリクエストから取得されます。 管理者がstate
をREQUESTED
に明示的に設定したのか、それとも単に省略したのかわからないため、これは意図したとおりに機能します。
ユーザーが管理者によって作成されていない場合、ユーザーの目標は承認を受けることであると想定し、それを妨げるものがない場合(管理者の承認要件)は自動的にそれを行います。 彼らは最初から自分自身を管理者にすることはできません。
Web UIの「管理者によるユーザーの作成」機能により、 state
フィールドを設定する必要があることがより明確になりますが、 REQUESTED
よりも適切なデフォルトを設定することをお勧めします。 users create
APPROVED
のstate
フラグを作成しましょう。
以前のコメントで説明した機能を含む#1190を使用すると、この問題を解決できると思います。
最も参考になるコメント
ユーザーが管理者によって作成された場合、
state
(およびadmin
)フィールドは文字通りリクエストから取得されます。 管理者がstate
をREQUESTED
に明示的に設定したのか、それとも単に省略したのかわからないため、これは意図したとおりに機能します。ユーザーが管理者によって作成されていない場合、ユーザーの目標は承認を受けることであると想定し、それを妨げるものがない場合(管理者の承認要件)は自動的にそれを行います。 彼らは最初から自分自身を管理者にすることはできません。
Web UIの「管理者によるユーザーの作成」機能により、
state
フィールドを設定する必要があることがより明確になりますが、REQUESTED
よりも適切なデフォルトを設定することをお勧めします。users create
APPROVED
のstate
フラグを作成しましょう。