api.get("/zigbee/devices) doesn't work

[cag014 731]

Using swagger, you can load and see the api/zigbee/devices data

api.get("/zigbee/devices") is not working

It does work using api.get("/proxy?url=http://..../api/zigbee/devices"

 

BTW, this zigbee data includes vendors and models of the ZigBee devices. Why this data is not available in api.get("/devices") and on UI? Same as for Zwave devices

 

Edited October 6, 2025 by cag014

[tinman 1,070]

due to this:

 

Please login or register to see this image.

/monthly_2025_10/image.png.1f4889983a8111f8be315a2bef2e8b77.png" />

 

all nginx locations are now more protected

 

[cag014 731]

10 hours ago, tinman said:

due to this:

 

Please login or register to see this link.

 

all nginx locations are now more protected

 

api.get() Restrictions: It's ironic that Fibaro's own internal API function (api.get()) can't access endpoints that are freely available via browser.

The /api/devices endpoint exposes most device data but omits vendor/model info for ZigBee devices, which freely available for Z=Wave devices.

Security Justifications: The move to restrict access due to "cybersecurity concerns" feels more like a blanket excuse than a targeted fix.

If browser access to /api/zigbee/devices is still open (and Swagger), then the restriction on api.get() seems arbitrary or poorly implemented.

 

Edited October 7, 2025 by cag014

[jgab 2,641]

The REST api was not freely available, you need to provide the credentials. 

You log into the HC3 Web UI (giving the credentials), the browser remembers that and you can open the swagger and make the calls without having to enter the credentials again.

If you try to go directly to the swagger page in a new browser (or creds expired), you are redirected to the HC3 login page.

 

The question is of course what endpoints a QA/Scene should be able to use without having to provide creds.

When an app is installed in MacOS or Windows, the user these days have to approve what services/APIs the app is allowed to use.

Maybe some kind of access rights list for QAs ? Grouped in some sensible way...

The solution is NOT to force user to give the creds to apps they install so the apps can make the calls...

 

Now we install an encrypted QA in our HC3 and it has free range to the REST APIs... and we have no idea what's going on...

Edited October 7, 2025 by jgab

[m.roszak 763]

Some of the endpoints are OS level based (like this one mentioned here) and some are direcly on our main server API (most of the API).

So for the ones based on OS level you need to provide the credentials (and use http get instead of build-in api.get).

[cag014 731]

Sounds OK to have sensitive data at OS level and credentials required for access.

My question is why vendor/model data of Zigbee devices is sensitive and secured while for all other devices is not?

The Zigbee IEEE and network addresses are available at "/api/devices" level, but not vendor!!!!

Again. it sounds like a mistake to store Zigbee data at OS level.

By the way, same issue we had with "api/icons" and just recently it was fixed and now it works with standard api.get() request.

@m.roszak could you please ask your team to store that data in standard devices location

Please login or register to see this spoiler.

 

 

 

[m.roszak 763]

I agree that is should be under "manufacturer" and "model" in normal API, I will make a task for adding this.

[cag014 731]

8 hours ago, jgab said:

The REST api was not freely available, you need to provide the credentials. 

That's correct, but in order to access api.get() you need to login into HC, so the credentials are applied, isn't?

[jgab 2,641]

Yes.

So when you log in and install a 3rd party QA (or your own), the QA will have access to the api forever (api.get etc)

It's not very smart to have a 11111 port that bypasses the auth, or worse, force the user to give the HC3 credentials to the QA so it can call the api.

Instead it would make sense to have some check boxes to tell what api groups the QA should have access to.

Probably more fine grained, ex. a QA could read its own properties but not others' etc.

 

[cag014 731]

You are absolutely correct, but it should be some logic what info must be restricted.

The vendor/model of devices is not a security breach!!! same for icons (which now is accessible, means it was a mistake to protect in the first place)

 

[jgab 2,641]

Yes, the auth approach hasn’t been very consistent so far…

There need to be some clever grouping of capabilities given to a QA. Don’t want the user to approve 200+ api endpoints