"Each endpoint url is made up of the following segments: http:// [hub ip address] /apps/api/[app id] /[endpoint path ?access_token=[access_token]"
"app id" and "access token" are different on every hub. So I would expect the "/38/" to be different on every end hub, as that looks like the "app id".
That said... I've never used/had a need to use "http://IP/installedapp/" before.... so I guess it could follow a different format. You would need to ask Hubitat that, as that isn't even an official/documented MakerAPI endpoint (which also means that it could change/shouldn't be used/relied on - you should verify that if you plan on using it)...
Correct, the response is a weird format. I don't find the command responses especially useful except as error checking, as they (often) can have the incorrect attribute value in them depending on how fast the driver and device reports the new state back to the hub.
If you are going to support multiple hubs on the same app, might want to consider allowing the post url to be customized as well to make it easier to determine source hub.
That can be important as the same device # and app # can be used in multiple hubs / those values are not unique cross hubs.
haha.. I spent some time thinking about how to make it easier to enter that access token.. typing on mobile devices (or wall mounted tablets) isn't exactly fun or easy.. then I realized something.. I can just automatically 'fetch' the access token by going to this page:
http://192.168.0.202/installedapp/status/38
In this case, I guess the "38" (app id) needs to be entered too.. but, not the access token at least!
That actually seems like a security issue to me @bravenel .... But probably not a lot you can do about it? Shouldn't be able to fetch the security token at all, in my opinion... Bad.
I'm creating a websocket connection to the hub to get updates so I'd expect that to work for multiple tables.. not that I've tried it yet though.
support multiple hubs on the same app
that's probably beyond the scope of my initial app.. I'm going for something that is easy for anyone to get up and running.. no need to create a dashboard and manually place devices on the screen to get started. I will try to allow for some customization but no way it's going to be as flexible as the html dashboard.
Many people have multiple hubs, but I guess they could always use hubconnect (if they are ok with the account/login requirement to get the code - I am not) and get all of the devices on one hub, though.
The access token is readily available on the main page of Maker API. Obviously, you need the access token to access Maker API remotely. So you have to have the ability to get it, and that means the ability to see it. As long as you don't give it out or publish it, it is not a security issue. If you do publish it for others to see, then you've granted access to your hub.
Ok. Except you can browse to the MakerAPI config page and skim the token, without anyone having given it to you...
But I agree it isn't the end of the world. Just thought maybe it should be obfuscated by default, press a button to see it type of thing... Like password would be handled.
once i get the app up and running i will open source it and try to implement anything that anyone else might want to see.. for example, while I have maybe 30 smart devices - I know there's a TON of different devices out there.
curious.. what's the primary reason for multiple hubs? it's not to extend zigbee or zwave range right since i think the devices themselves (at least non-battery-powered ones) will do that.
Obviously, you need the access token to access Maker API remotely
I didn't even realize you could use Maker API remotely (meaning outside of your home network). If you can, what do you use for the server value?
Many different reasons. Some to extend the network, some to segregate poorly designed/performing devices away from the rest to prevent mesh issues, some to segregate by criticality, some to have a development system separate from production, etc.
You would use the hub cloud endpoint address instead of local IP. Remote MakerAPI access can be turned on/off in the MakerAPI config page you are skimming the token from.
I don't understand the issue here. You go to your Maker API page and it shows the URLs you can use to query and write Maker API calls. Everyone will have a different token and ID in those URLs. So what? You activate Maker API (which you'd have to do to use the eventsocket anyway), and then you can find your token and ID and use them in any other application you are writing that will use the Maker API calls. How is that a security issue? No one else could guess that data for my hub in a million years and anyway still wouldn't have access to it outside my LAN. So where's the problem?
I think I follow what you are suggesting about this being a way to access the token. I can however report that I fall on @bravenel's side on this. The reason is the http://192.168.xxx.xxx/installedapp/status/xxx URL is just one of many places to get that token and access to that page is just as protected or unprotected as any of the other pages in the interface. When I access it on a hub without password protection turned on, I get it without problem, but when password protection is turned on and I logged out, it required username and password to be able to access the page.
Agreed, but that isn't a great reason to not follow basic security practices either. But whatever, I only do cyber security for a living, what do I know?
I still agree that this isn't a huge issue, it just isn't ideal. I'll let it drop.
Every app that offers access tokens makes them available to you, the user. There is no avoiding that, otherwise how would you get them? You are talking about a total red herring. This is not a security issue, but a Joel-making-stuff-up issue.
When I access it on a hub without password protection turned on, I get it without problem, but when password protection is turned on and I logged out, it required username and password to be able to access the page
ahh.. that's good to know. I didn't even know there was a username/password login option for the hub. I obviously have mine disabled
In that case, the user will have to either type in their access token or enter a user/pass so the app can fetch it that way.
FWIW - as long as there's a login option which keeps users from viewing any of the hub's URL's without logging in -- that seems good from a security standpoint. I might even enable it for my hub once the tablets in my house have the token. That will keep anyone who might get into my wifi network from being able to control my devices.
Now, I suppose the fact that traffic is going via http probably won't keep it protected. I'm not sure about remote traffic - hopefully that's https which I believe secures URL params like that access token.. haven't gotten that far yet.
Nice to see someone else asking the same questions that are in my head as I also write my own app for use!
Maybe when we are both closer to release, we can share some of the json device info since i have such a tiny amount of devices, i know i'm missing out on different categorizations I should be handling.
I plan on open sourcing my app as well.
Edit: Just saw your other thread with people posting example device json. Excellent resource! Thanks for that.
