Saat membuat pengguna admin di CLI, pengguna ini mungkin tidak memiliki hak yang memadai di Konsol untuk membuat atau mengedit Gateway dan Aplikasi. Dalam kasus lain, pengguna normal baru juga tidak memiliki izin di konsol untuk melakukan apa pun. Mungkin bug atau hanya dokumentasi yang hilang tentang cara membuat pengguna dengan benar.
Saya tidak sepenuhnya yakin. Ada dua kasus di sini yang mungkin terkait dengan penyebab yang sama. Dalam kasus pertama saya mengoperasikan mesin yang tidak saya setel dan saya memiliki informasi terbatas tentang prosesnya.
Kasus 1: tumpukan asing; setup sebagai versi 3.0.0 dan ditingkatkan ke 3.1.0 sebelum menggunakan Konsol.
--admin
(*Apa yang terjadi saat upgrade adalah proses pembuatan Console dilakukan dengan uris yang salah, jadi kami menghapus klien konsol di database dan menggunakan kembali perintah is-db
. Mungkin kita kacau di sini.
Kasus 2 : Pada pengaturan saya:
ttn-lw-cli users create norman --name norman --primary-email-address norman@localhost
menggunakan pengguna admin dari awalDalam kedua kasus tersebut, Konsol merespons dengan Insufficient rights for user 'myuser'
setelah memasukkan detail dan menekan tombol Create Gateway
atau Create Application
.
Di konsol browser tidak ada yang aneh. Tab jaringan menunjukkan respons 403 Forbidden dari ttn.
Saat membuat aplikasi melalui CLI dengan pengguna admin dan menugaskannya ke pengguna yang bersangkutan, pengguna mungkin melihat aplikasi/gerbang tetapi mengkliknya menghasilkan 403 Forbidden.
Bagaimanapun saya berharap pengguna baru yang dibuat setidaknya dapat membuat gateway dan aplikasi untuk dirinya sendiri dan dapat membuka pandangan mereka ketika ditambahkan sebagai kolaborator.
Saya juga mengharapkan lebih banyak dokumentasi tentang proses pembuatan pengguna dan cara mengelola hak pengguna.
The Things Network Stack for LoRaWAN: ttn-lw-stack
Version: 3.1.0
Go version: go1.12.7
OS/Arch: linux/amd64
Konfigurasi kasus 1:
stack-config.txt
Sayangnya saya tidak tahu di mana letak masalahnya.
Saya mungkin tidak dapat menerapkan perbaikan tetapi saya dapat memberikan dokumentasi untuk pembuatan pengguna dan manajemen hak.
@w4tsn apa konfigurasi Anda? Apakah Anda memerlukan persetujuan admin untuk pengguna baru?
Bisakah Anda menunjukkan output dari $ ttn-lw-cli user get myuser --state
?
Kasus 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"
}
Kasus 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"
}
Saya akan memperbarui bagian env dengan konfigurasi kasus 1 saya. Dalam kasus 2 saya juga tidak secara eksplisit mengatur persetujuan admin. Diperlukan persetujuan admin status konfigurasi = false
Saya dapat mengonfirmasi bahwa masalah tersebut dapat direproduksi pada 3.1.0.
Perbaikan yang mungkin dilakukan adalah menggunakan perintah aktivasi manual berikut: ttn-lw-cli users set norman --state=STATE_APPROVED
. Saya akan mencari tahu mengapa ini terjadi segera.
Juga, dalam output di atas karena status tidak disebutkan, itu adalah nol, yang berarti STATE_REQUESTED
, sehingga pengguna tidak benar-benar diaktifkan.
Ditemukan juga penyebabnya:
https://github.com/TheThingsNetwork/lorawan-stack/blob/55381c15f6902508ea34cd40441ad2bd3146ac37/pkg/identityserver/user_registry.go#L149 -L156
Pengguna yang dibuat oleh admin tidak menghormati pengaturan persetujuan admin dan selalu memiliki status default ( STATE_REQUESTED
). Apakah ini dimaksudkan @htdvisser ?
Jika pengguna dibuat oleh admin, bidang state
(dan admin
) diambil secara harfiah dari permintaan. Ini berfungsi sebagaimana mestinya, karena kita tidak tahu apakah admin secara eksplisit menyetel state
ke REQUESTED
atau membiarkannya begitu saja.
Jika pengguna tidak dibuat oleh admin, kami berasumsi bahwa tujuan mereka adalah untuk mendapatkan persetujuan, dan secara otomatis melakukannya jika tidak ada (persyaratan persetujuan admin) yang mencegahnya. Mereka tidak pernah bisa menjadikan diri mereka admin sejak awal.
Fungsionalitas "buat pengguna oleh admin" di UI web akan memperjelas bahwa bidang state
perlu disetel, tetapi saya pikir akan lebih baik jika memiliki default yang lebih waras daripada REQUESTED
, jadi mari kita ubah CLI dan buat flag state
dari users create
APPROVED
secara default.
Dengan #1190, yang mencakup fungsionalitas yang saya jelaskan di komentar saya sebelumnya, saya pikir masalah ini sekarang dapat ditutup.
Komentar yang paling membantu
Jika pengguna dibuat oleh admin, bidang
state
(danadmin
) diambil secara harfiah dari permintaan. Ini berfungsi sebagaimana mestinya, karena kita tidak tahu apakah admin secara eksplisit menyetelstate
keREQUESTED
atau membiarkannya begitu saja.Jika pengguna tidak dibuat oleh admin, kami berasumsi bahwa tujuan mereka adalah untuk mendapatkan persetujuan, dan secara otomatis melakukannya jika tidak ada (persyaratan persetujuan admin) yang mencegahnya. Mereka tidak pernah bisa menjadikan diri mereka admin sejak awal.
Fungsionalitas "buat pengguna oleh admin" di UI web akan memperjelas bahwa bidang
state
perlu disetel, tetapi saya pikir akan lebih baik jika memiliki default yang lebih waras daripadaREQUESTED
, jadi mari kita ubah CLI dan buat flagstate
dariusers create
APPROVED
secara default.