Configuration v2 fails due to CORS

[jalmeroth]

I am trying to configure the latest dev-version of Homie 2 (f605adf).

When using the latest Configurator page v2 (03034c6) I am receiving an error in Chrome 63.0.3239.84 (Official Build) (64-bit) and other browsers:
Failed to load http://192.168.123.1/heart: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8000' is therefore not allowed access.

I could temporarily fix this issue by adding the following default headers after this line https://github.com/marvinroger/homie-esp8266/blob/develop/src/Homie/Boot/BootConfig.cpp#L18:

DefaultHeaders::Instance().addHeader(F("Access-Control-Allow-Origin"), F("*"));
DefaultHeaders::Instance().addHeader(F("Access-Control-Allow-Methods"), F("PUT, GET"));
DefaultHeaders::Instance().addHeader(F("Access-Control-Allow-Headers"), F("Content-Type, Origin, Referer, User-Agent"));

Please note: This is no the fix, it's just a proof to make it work temporarily.

Some of the following requests are also failing then as calls to __sendCORS() will send these headers again.

[timpur]

Ill look into a fix for CORS, but adding those lines wont help you here, because your origin is from 8000 (Self hosted webserver?) not the esp. Thus you need 8000 to allow CORS not the esp, because you cant even get to the esp in the first place? (in my understanding, might be wrong?)

Ill look into a solution for this. It would be nice to use the online config and not save to rely on the build in esp config, even though having it on the esp has other advantages, but thats up to you to decide and thats why ill try fix this.

[jalmeroth]

Ill look into a fix for CORS, but adding those lines wont help you here, because your origin is from 8000 (Self hosted webserver?) not the esp. Thus you need 8000 to allow CORS not the esp, because you cant even get to the esp in the first place? (in my understanding, might be wrong?)

That's wrong, Access-Control-Allow-Origin: * allows access from everywhere, including my local webserver (not the esp itself).

Ill look into a solution for this. It would be nice to use the online config and not save to rely on the build in esp config, even though having it on the esp has other advantages, but thats up to you to decide and thats why ill try fix this.

Yeah, the online configurator is nice, but please keep the compatibility to checkout the gh-pages branch on your local maschine to configure homie devices, when you are offline or connected to the Homie Device AP. ;)

[marvinroger]

Right, there’s a CORS issue. What I don’t get, though, is why it used to work.

The code was only handling preflight CORS request (OPTIONS), so the config endpoint was the only one that was supposed to work... anyway, the fix is pretty simple: it’s just a matter of wrapping each request into something that sends the CORS header, and it’lol work everywhere.

[timpur]

@jalmeroth

That's wrong, Access-Control-Allow-Origin: * allows access from everywhere, including my local webserver (not the esp itself).

but you want the webserver to tell the client (chrome) that its okay to go to the esp for requests ??? It wont work is you load the website from one server and then try access another webserver (ESP) with out the origin server giving CORS access??

[jalmeroth]

@timpur well… as long as the AsyncWebserver, running on the ESP, is not sending these Access-Control-Allow-Headers, modern clients (e.g. Chrome) will not let you execute the JS XHR, which is in this case hosted on my local webserver, but could be anywhere else like the online configurator, and therefore the queries to the URLs necessary to configure your device will fail.

[timpur]

Seems my understanding of CORS was totally wrong.

[timpur]

But if you want @marvinroger i can fix this issue ?

[marvinroger]

Yes @timpur, please, go ahead. 😉

[timpur]

@marvinroger assign this to me ? (how do you feel about making me a Collaborator ?)

[benzino77]

I think this is a great idea. @marvinroger you don't have so much time for the project as before and @timpur is one of the most active contributor which keep this project alive.

[marvinroger]

Well, believe me or not, I was about to. ☺️ One condition, though: add your name on the manifests. 😌 Le jeu. 14 déc. 2017 à 21:20, benzino77 <notifications@github.com> a écrit :

…

I think this is a great idea. @marvinroger <https://github.com/marvinroger> you don't have so much time for the projects as before and @timpur <https://github.com/timpur> is one of the most active contributor which keep this project alive. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#446 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA8eNUWsRl58svy8A53KQMXYMnSfxqP6ks5tAYMegaJpZM4RBNtJ> .

[tripflex]

@timpur thank you for all your hard work on this, it's much appreciated! Hope to be able to start contributing myself very soon

[tripflex]

@jalmeroth thank you for this! I was having this issue while trying to call API endpoints using a Cordova mobile app, which does not work without the device handling CORS, and can confirm the update you provided fixed this issue for me

Yes I did look at potentially using a proxy to do this, but really CORS should be handled via the server, in the case being the device.

Being as though this is for the API endpoints, I don't see any reason to not be handling this on the device, @timpur can you please make sure to include this in the 2.1.0 release? I see it was added to the milestone, and think this is something we should def have in the codebase

[tripflex]

Looking at the code itself, it appears that CORS handling already exists for /config and /wifi/connect ... so probably just need to set it for the other endpoints as well.

Adding those default headers makes it possible to get past CORS restrictions for GET requests without having to respond to OPTIONS

So looks like we would only need to add handling for HTTP_OPTIONS to call __sendCORS for the only other non-GET endpoint that does not already have it, /proxy/control

NOTE: You will still need to respond to the OPTIONS method for CORS pre-flight in most cases. (unless you are only using GET)

^ from ESPAsyncWebServer
Mozzila CORS Docs

[timpur]

@tripflex its fixed, did it last night (for me) all works, just haven't pushed to my repo, will do tonight.

All request have been opened to CORS, not really worried about security issues with that. Unless ive missed something?

@jalmeroth

[tripflex]

@timpur yup I tested myself using your 2.1 branch fork and no CORS issues at all! Thanks for fixing that so quick!

And no this is not an issue security wise, as CORS is really useful for preventing malicious scripts, browser extensions/plugins, or even other JS code from making requests to a server it should not be. Being as though this is for iot device, this should be open as the requests are almost always going to be coming from somewhere other than the device, not from the device itself.

Really this just helps prevent issues surrounding wanting to use something like Cordova to send API calls, or some custom javascript

I say this from my 10+ yrs experience as sys/net admin, and running a hosting company since 2009

[boneskull]

ha, I was just running into this. thanks @timpur