Lorawan-stack: New (admin) user has no permissions in Console
Summary
When creating an admin user in the CLI it may happen that this user has not sufficient rights in the Console to create or edit Gateways and Applications. In another case a new normal user has also no permissions in the console to do anything. It might be a bug or just missing documentation on how to create users properly.
Steps to Reproduce
I'm not completely sure. It's two cases here that may be related to the same cause. In the first case I'm operating on a machine which was not setup by me and I have limited information on the process.
Case 1: foreign stack; setup as version 3.0.0 and upgraded to 3.1.0 before using the Console.
- setup ttn 3.0.0 following cli getting started
- update to 3.1.0
- setup Console client (and potentially screw it up*)
- create
--adminuser (
5 .login to console and try to create a Gateway.
*What happend on upgrade was that the Console creation process was done with wrong uris, so we deleted the console client in the database and re-used the is-db command. Maybe we screwed up here.
Case 2: On my setup:
- setup ttn following the getting started
- create a normal user
ttn-lw-cli users create norman --name norman --primary-email-address norman@localhostusing the admin user from getting-started - try create a gateway or application
What do you see now?
In either case the Console responds with Insufficient rights for user 'myuser' after entering the details and hitting the Create Gateway or Create Application button.
In the browser console there is nothing unusual. The network tab shows a 403 Forbidden response from ttn.
When creating an application over the CLI with the admin user and assigning it to the user in question, the user may see the application/gateway but clicking on it yields in a 403 Forbidden.
What do you want to see instead?
In any case I'd expect a new created user to be able to at least create gateways and applications for itself and be able to open their views when added as collaborator.
I'd also expect more documentation on the user creation process and how to manage user rights.
Environment
The Things Network Stack for LoRaWAN: ttn-lw-stack
Version: 3.1.0
Go version: go1.12.7
OS/Arch: linux/amd64
Case 1 config:
stack-config.txt
How do you propose to implement this?
Unfortunately I have no idea where the problem lies.
Can you do this yourself and submit a Pull Request?
I may not be able to implement a fix but I can provide the documentation for the user creation and rights management.
w4tsn
All 6 comments
@w4tsn what's your configuration? Are you requiring admin approval for new users?
Can you show the output of $ ttn-lw-cli user get myuser --state?
johanstokking
on 14 Aug 2019
Case 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"
}
Case 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"
}
I'll update env section with my case 1 configuration. In case 2 I did also not excplicitly set admin approval. The config state admin approval required = false
w4tsn
on 14 Aug 2019
I can confirm that the issue can be reproduced on 3.1.0.
A possible fix is using the following manual activation command: ttn-lw-cli users set norman --state=STATE_APPROVED. I'll look into why this happens soon.
Also, in the above outputs since the state is not mentioned, it is zero, which means STATE_REQUESTED, so the users are not actually activated.
adriansmares
on 14 Aug 2019
Also found the cause:
https://github.com/TheThingsNetwork/lorawan-stack/blob/55381c15f6902508ea34cd40441ad2bd3146ac37/pkg/identityserver/user_registry.go#L149-L156
Users created by an admin do not respect the admin approval setting and always have state default (STATE_REQUESTED). Is this intended @htdvisser ?
adriansmares
on 14 Aug 2019
If a user is created by an admin, the state (and admin) fields are taken literally from the request. This works as intended, since we don't know if the admin explicitly set the state to REQUESTED or just left it out.
If the user is not created by an admin, we assume that their goal is to get approved, and automatically do that if nothing (admin approval requirement) prevents that. They can never make themselves admin from the start.
The "create user by admin" functionality in the web UI will make it more clear that the state field needs to be set, but I think it would be a good idea to have a more sane default than REQUESTED, so let's change the CLI and make the state flag of users create APPROVED by default.
htdvisser
on 14 Aug 2019
With #1190, which includes the functionality I described in my previous comment, I think this issue can now be closed.
htdvisser
on 27 Aug 2019
Related issues
rvolosatovs
·
9Comments
ecities
·
5Comments
MatteMoveSRL
·
7Comments
adriansmares
·
8Comments
htdvisser
·
4Comments
Most helpful comment
If a user is created by an admin, the
state(andadmin) fields are taken literally from the request. This works as intended, since we don't know if the admin explicitly set thestatetoREQUESTEDor just left it out.If the user is not created by an admin, we assume that their goal is to get approved, and automatically do that if nothing (admin approval requirement) prevents that. They can never make themselves admin from the start.
The "create user by admin" functionality in the web UI will make it more clear that the
statefield needs to be set, but I think it would be a good idea to have a more sane default thanREQUESTED, so let's change the CLI and make thestateflag ofusers createAPPROVEDby default.