Iodide should not hardcode server addresses

[wlach]

Right now we hardcode server addresses in the iodide .js during the webpack phase of the build:

iodide/webpack.config.js

Line 27 in b026e53

let { EVAL_FRAME_ORIGIN } = process.env;

To deploy internally at Mozilla (where we use a docker container), we set the circle environment for these two variables at build time. This has a number of disadvantages:

1. If the origins ever change (as just happened with GCP), we need to remember to update the CircleCI configuration from their interface (very easy to forget)
2. We can't use the same docker container for a production and stage version of the iodide server.

We should somehow fix the webpack builds to not require hardcoding this information. Not sure offhand what the right set of solutions here is, hopefully it's not too complicated.

/cc @bcolloran @robotblake

[bcolloran]

The domains are needed to verify the that the communications between the eval-frame and the editor come from the correct hosts. since we're pretty much all-in on the server at this point, i guess we could have django inject the correct domains when it serves the pages (as we do with other NB info) -- they'd still need to be configured in .env for each deployment, but you wouln't have to re-build. so questions then:

1. would that solve this use case?
2. would serving the host info via django rather than hardcoding it at build time be less secure? (i assume not since we serve all kinds of secure token things this way using django?)
3. how big of a deal is this? is it worth a day of someone's time to fix it?

one other thing: if we don't set the host domains at build time, we'd need to fully deprecate start-and-serve mode. i don't use that anymore ever, but it's worth noting.

also cc @hamilton and @mdboom re the start-and-serve bit

[wlach]

On some level, yeah, we need this information to come from Django. No, I don't think it's any less secure: If you can't trust what Django is sending you, well, you basically can't trust anything. There's almost certainly a way to keep start-and-serve working with this approach, I suspect it's something we can just add to the webpack config.

I would say this is pretty much something we have to fix before we can put this into production internally. Our internal configuration is already quite complex and has many moving pieces and assumptions, for sure this will come back to bite us again (perhaps at an inopportune time) if we don't fix it sooner.

[wlach]

Can probably use something like this technique: https://facebook.github.io/create-react-app/docs/title-and-meta-tags#injecting-data-from-the-server-into-the-page