Hub Offline (after 3 seconds)

I’ve started afresh on a dashboard. On iPhone I deleted config, set up a fresh maker api instance on Hubitat (local and remote), authorised everything then selected the correct app ID during the Hubivue startup wizard. It created dashboards for all rooms etc and I’m ready to go on the iPhone.

However when I login (locally) on my MacBook with Safari, the dashboard appears then after a few seconds "Hub Offline’. If I click refresh it comes back for three seconds then ‘Hub Offline’. Any ideas why that would be happening? I’ll try the Mac OS app in the meantime. Thanks.

Edit: Opened the Mac OS app - it prompted an update. Downloaded the update but it doesn’t run the installer when I click the DMG. Scratch that - this seems to be the only installer I’ve used on Mac OS that doesn’t automatically bring a pop up to the foreground. Had to go to the finder to install.

1 Like

You didn’t setup MakerAPI correctly

Follow the guide in the HowTo section for the steps and make sure you follow the step on CORS

This is due to how the Hubitat engineers decided to configure web access vs direct - not sure why as it isn’t any more / less secure???

1 Like

That’s due to a lack of signing the app with my developer certificate. Apple and Windows are both unsigned installers - I haven’t yet paid the taxes as a developer so that people can get free software :roll_eyes:

1 Like

I’ve always imagined their rationale to be connected with a Hubitat user’s ability to “revoke” Maker API access tokens, rendering any previously connected apps orphaned. Whereas (unless I’m way off-base here), CORS gives your app a “back door” for sussing out other / newer Maker API instances, replete with current token(s).

Just my $0.02 theory.

Ah ok, thanks. It looks as though the Mac OS app suits me better anyway now I’ve update that.

Fair enough. In that case don’t pay - we like free software!

1 Like

Nope. CORS only applies to web apps. If you leave CORS not configured you still have open and unrestricted access, just that browsers will only “obey” the unset CORS directive which defaults to allowing API requests from the host the MakerAPI runs on - for local that means the hub (and they don’t allow you to run a website of your own on the hub) and for cloud it just doesn’t make sense there either - you can never run your own personal web site on hey !?

Smells more to me as folks who put that setting in don’t fully understand CORS security - and didn’t feel comfortable having a wild card value set because that felt insecure (even though that’s exactly what a public API hosted on a webserver requires)

1 Like

I should clarify… I meant to say that with CORS not configured, all access via HTTP is still equally as accessible/controlled as using the access_token and cloud_token.

HTTP access either locally or via cloud isn’t controlled by the CORS setting - only web browsers “respect” the CORS header and by default will obey it as being same site only (and yet this can be turned off in Chrome or Firefox). That’s why hubiVue web browser app fails and can’t connect, yet all other platforms (mobile, desktop etc) work fine.

The important thing to understand is that the actual validation of the CORS mechanism is done by the browser. Yep, you read that right, the browser itself is keeping it secure. Not your hub, not your cloud servers !!

So CORS provides zero security of your Maker API itself and only helps to secure websites that host the webpage and API on the same server. The point/purpose of MakerAPI is to allow external/outside API access, so use / restriction via CORS is slightly confused and counter productive.