New (admin) user has no permissions in Console

[w4tsn]

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.

1. setup ttn 3.0.0 following cli getting started
2. update to 3.1.0
3. setup Console client (and potentially screw it up*)
4. create --admin user (
   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:

1. setup ttn following the getting started
2. create a normal user ttn-lw-cli users create norman --name norman --primary-email-address norman@localhost using the admin user from getting-started
3. 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.

[johanstokking]

@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?

[w4tsn]

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

[adriansmares]

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]

Also found the cause:

lorawan-stack/pkg/identityserver/user_registry.go

Lines 149 to 156 in 55381c1

	if !createdByAdmin {
	if is.configFromContext(ctx).UserRegistration.AdminApproval.Required {
	req.User.State = ttnpb.STATE_REQUESTED
	} else {
	req.User.State = ttnpb.STATE_APPROVED
	}
	req.User.Admin = false
	}

Users created by an admin do not respect the admin approval setting and always have state default (STATE_REQUESTED). Is this intended @htdvisser ?

[htdvisser]

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]

With #1190, which includes the functionality I described in my previous comment, I think this issue can now be closed.