CORS errors

[gobengo]

When I access peoplesopen-dash on my home node using a DNS name, it doesn't work. It appears to be because the webapp UI is making requests to http://172.30.0.1/cgi-bin/infogather . These requests are blocked by the browser because that web service doesn't allow this 'Origin' via the proper CORS headers.

Failed to load http://172.30.0.1/cgi-bin/infogather: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

I get this error when accessing:

• via https://admin.peoplesopen.net while connected to my home node
• when running peoplesopen-dash locally via npm start, and accessing via both http://127.0.0.1:3000/ and http://localhost:3000/

What serves that endpoint on the home node itself? Is it easy for us to add the required CORS response headers? Or perhaps run an http proxy that will do CORS as needed without changing the underlying /infogather app.

--

Workaround: Run your own CORS proxy alongside peoplesopen-dash:

• npm install -g corsproxy
• corsproxy to run corsproxy at default baseUrl of http://localhost:1337 (see README to configure port/host)
• change peoplesopen-dash/src/config.js (note localhost:1337/ prefix):

  export default {
    ubusUrl: 'http://localhost:1337/172.30.0.1/ubus',
    infogatherUrl: 'http://localhost:1337/172.30.0.1/cgi-bin/infogather',
    username: 'admin'
  }

• use http://localhost:3000 as normal. This app will request the home node through the corsproxy, which will add the appropriate Access-Control-Allow-* headers such that the browser doesn't block AJAX requests from the frontend

---

Future Work:

• Because npm, it would be quite reasonable for peoplesopen-dash's process to do corsproxy-like stuff on some sub-route. However, because we're delegating all that to react-scripts start, I'm not sure how to add that capability
  • There are pluses and minuses to 'ejecting' from create-react-app. Anyone opposed to ejecting at some point (maybe not now)?

[Juul]

@jtremback Any ideas?

[bennlich]

Removing the hardcoded hostname from config.js seemed to resolve this issue.

[paidforby]

The proposed solution 43229cf appears to prevent us from developing on the dashboard locally (at least with Chrome on Debian Stretch)
To reproduce,

1. Flash node with sudowrt 0.3.0
2. Connect to node via ethernet on port 3
3. Set wired settings to 172.30.0.9/22
4. run google-chrome --disable-web-security --user-data-dir
5. git clone https://github.com/sudomesh/peoplesopen-dash/
6. cd into it and npm install
7. npm start
8. Attempt to log in using default password, it should appear to soft fail (like you used the wrong pw).
9. Check console, notice Failed to load resource: the server responded with a status of 404 (Not Found) when you hit http://localhost:3000/ubus
10. Stop npm and git checkout fa86dd22c3b9ca41a81ac7f39431f76e30e5b57f
11. npm start
12. Attempt to log in with default pw, this time is should work.

According to @jtremback the easiest way is the one documented in the readme, adding the --disable-web-security --user-data-dir to Chrome. This is workaround for sure, but seems simpler than running a proxy, unless @gobengo knows a way of rolling that proxy into npm start?

[bennlich]

Ahhhh, I see. Serving the website from a development computer, but still wanting to test API calls against an actual node IP. This was not a use case I was thinking about when I made that change, but I see how it is desireable now :-P

A proxy seems like a reasonable solution to me. I think it can be pretty simple: forward the /ubus path to the node IP.

Another solution would be to write a dev deploy script that simply copies the build/ directory to the node you want to test on. This is what I did manually when I was testing the change you mentioned.

I think I like the proxy solution more though. Can work on this at the working group meeting today.

Thanks for the detailed report!

[bennlich]

I chatted w/ @eenblam about this issue in the software working group today. His preference (and I think I now agree), is to go with the deploy script solution as opposed to the http proxy solution. The dev cycle would then be something like:

1. Make a change to the src on your computer
2. Build + deploy to connected node (i.e. copy a bunch of static assets over)
3. Test by pointing your browser to the node (i.e. against a real production environment)

instead of the current cycle which is:

1. Make a change to the src on your computer
2. Test in a development environment that has workarounds (i.e. the http proxy or forcing your browser to ignore CORS) to talk to the API on the node

This change would encourage one to actually test with a production setup on a node, instead of with a half-production / half-development system like before (which led to this CORS issue in the first place).

It also leaves room to stub out the node API calls in the future, so you could develop locally without requiring a node connected to your computer.

The only downside IMO is that, until we stub out the API calls, you have an extra step in the dev cycle. But the simpler architecture is way worth it I think, and will save us from more bugs like this one in the future.

[gobengo]

Re-reading this, I think the talk about how to improve development of dash is a bit different than what I was seeing when I filed this issue. I believe back then I was just trying to run a home node for the first time, with an official release of everything (no git cloning), and was seeing these errors. That was awhile ago.

I should re-test the original piece of this issue. If I can now access dash through 'https://admin.peoplesopen.net', then we should close this issue. I assigned myself this issue to retest.

@bennlich can you propose what's in your last comment, but as a new issue?