No "devices" rights to Application

Application Development
1

We’ve used the API for some time to provision devices to our TTN application. Today I noticed it did not work anymore. This is a call with Curl:

$ curl -X POST http://eu.thethings.network:8084/applications/XXXXX/devices/aaaaaaa -H "Authorization: Key ....." -d '{"lorawan_device": {"dev_id": "aaaaaaa", "dev_eui": "008000000xxxxxxx", "app_key": "........", "app_eui": "70cccccc0000000", "app_id": "XXXXX", "activation_constraints": "local", "uses32_bit_f_cnt": true}, "app_id": "XXXXX", "dev_id": "aaaaaaa"}' ; echo

I get the error

{"error":"permission denied: Broker did not set device: permission denied: NetworkServer did not set device: permission denied: No \"devices\" rights to Application \"YYYY\"","message":"permission denied: Broker did not set device: permission denied: NetworkServer did not set device: permission denied: No \"devices\" rights to Application \"YYYY\"","code":2}

Application YYYY does exist, and yes, the auth key has no access to it. But the call clearly states to use application XXXXX. What’s going on here?

2

Like the problem come up form one day to another, the issue appeared to have spontaneously gone. I guess TTN has fixed it, or some cache was flushed which made the bug disappear. Oh well.

3

Grr, it’s back again:

returned: permission denied: Broker did not set device: permission denied: NetworkServer did not set device: permission denied: No “devices” rights to Application “YYYY”

How annoying!

4

I can understand (however I don’t have a solution)

best chance : https://github.com/TheThingsNetwork/ttn/issues

5

I am also running into this issue when I try to add a device. I have no idea what the problem is considering I have been able to register all my other devices just fine.

6

Quite late, but: does anyone remember how they fixed this, and if that might have been related to a non-unique AppEUI?

And @markruys, was the following indeed the AppEUI that was actually used? If yes, then it’s not the correct length and maybe TTN will have added a leading zero. But as it doesn’t look like a registered, unique EUI to me, I assume the real AppEUI was simply redacted in the post:

The following seems to suggest that a non-unique AppEUI might be one of the causes of the error message:

(I’m not having this problem myself; just trying to understand things for future readers.)

7

Some more random thoughts:

The documentation seems quite lenient/confusing as for using the device ID in the URL:

Available HTTP Endpoints:

  • PUT /applications/{app_id}/devices/{dev_id}
  • POST /applications/{app_id}/devices
  • PUT /applications/{app_id}/devices
  • POST /applications/{app_id}/devices/{dev_id}

But for a POST (to create a new resource) I’d not necessarily expect the /aaaaaaa part in the URL used in the first post. Might that have been the culprit?

The above would not explain why the error complained about application “YYYY” while “XXXXX” was requested.

8

Yes, this was the exact solution in my case. I simply forgot to change the DevEUI to a unique one, which caused me to get that error. Thanks a lot!

9

Same problem here, after generating some devices in a script via ttnctl and then removing them again (I accidentally made them ABP), and then generating them again… Maybe I confused the system a bit :wink:
The “Devices” section in the Console now says “1 – 2 / 2” but lists no device. And “ttnctl devices list” gives

  DevID	AppEUI	DevEUI          	DevAddr	Description
     	      	register on join	<nil>  	           
     	      	register on join	<nil>  	           

  INFO Listed 2 devices

⇒ Apparently two device entries in an inconsistent state. I cannot remove them manually because they have no DevID assigned, although I cannot reuse the DevID I gave them. I’ll see if they are automatically removed by the system eventually. For now, I’ll switch to another naming scheme.