How to keep secrets out of config.js (server only)

[oscarb]

Hi!

Ever since I first found out about this project I’ve wanted to version control my config.js so I can share it with others and easily make backups. I’ve looked but haven’t found any easy way to do this while still keeping all my API keys secret since I’m running Magic Mirror server only in a docker container (with an Android tablet with Fully Kiosk Browser as the client).

However, I’ve found a way using the query parameters of the URL which works in my scenario, please let me know if you get it to work for you as well.

In the top of your config.js, add:

const urlParams = new URLSearchParams(location.search);
const secrets = Object.fromEntries(urlParams);

Then further down where the secret is to be used, just add:

modules: [
  {
	module: "currentweather",
	position: "top_right",
	config: {
		location: "Amsterdam,Netherlands",
		appid: secrets.weatherApiKey
	}
   }
]

Then, wherever you start your Magic Mirror, change the URL so it’s something like:
http://192.168.1.10:8123/?weatherApiKey=abcdefg123456&otheKey=secretkey123

Now if you only have a few secrets then managing the URL shouldn’t be that hard. However if you do have plenty of keys and if you are able to run PHP then try out this PHP script to make managing the keys more easily:

< ?php // Remove space 
  $ip = '192.168.1.10';
  $port = 8123;

  $secrets = array(
    'weatherApiKey' => '123456',
    'calendarApiKey' => 'abcdefg'
    'metroApiKey' => 'abc123',
  );

  $url = "http://$ip:$port/?" . http_build_query($secrets);
  header("Location: $url");
  exit();
?>

Don’t forget to point whatever client you’re using to this PHP script instead.

Let me know what you think or if you have any suggestions on improvements! :)

[BKeyport]

Interesting idea. Wonder if the authors of the project would entertain a “secrets” file within the user space…

(I so wish all user added material was under ~/MagicMirror/User for organizational reasons)

I do like this idea… Would be up to the owners of the individual modules to access it, I suppose.

[joshwilsonvu]

Another way to do this would be to create a config/secrets.js file containing your secrets, making sure to add it to the .gitignore so that it doesn’t get publicly committed to GitHub. Then you can require it from your config/config.js file.

// config/secrets.js
module.exports = {
  weatherApiKey: "key"
};

// config/config.js
var secrets = require("./secrets");
var config = {
  // your config
}

[oscarb]

@joshwilsonvu It would be awesome if it was that simple but I’ve tried and it doesn’t. I believe this is due to how the config file is loaded into the browser/client as a JavaScript include so then when the browser tries to require it’s not defined and the config breaks.

But on the other hand, there seems to be someone who wants to improve on that and if that happens then your suggestion would likely work :)
https://github.com/MichMich/MagicMirror/pull/1947

[sdetweil]

@oscarb browser require support is provided by electron and chrome, and the other browsers when executing javascript apps… in electron its an option… (always enabled prior to v6, off and optional v6 and after)

[oscarb]

@sdetweil I’m running Magic Mirror in server mode and I’ve tried what @joshwilsonvu suggested but can’t get that to work neither in Chrome latest version on my MacBook Pro or in Fully Kiosk Browser on my Android tablet behind my mirror as Chrome then complains require is not defined.

Do you have any ideas on how to get that working when not running Magic Mirror as an electron app?

[sdetweil]

@oscarbhm. no, not at the moment… i modified run-start.sh in 2.10 to support split mode (where electron isn’t available), but never tried this on mac. the chrome browser executable name is probably incorrect…

set serverOnly: “local”, in config.js to try it

[joshwilsonvu]

You’re right, I forgot about the if (typeof module !== undefined) check. It might work if you set electronOptions: { nodeIntegration: true } in the config, but I haven’t tested it.

[BKeyport]

what does that line below the modules actually do out of curiousity?

[sdetweil]

@BKeyport if this file is loaded into a module based application, then the interfacing approach (module.export) is created for this file/module…

[joshwilsonvu]

@BKeyport Here’s a more detailed explanation for you and anyone who is curious.

The if (typeof module !== "undefined") {} line checks if there is a global variable named module. If there is, then we must be using a module system and we have to export config using module.exports = config;. If not, then we must be in the browser and config will already be available to any other modules.

In the browser, there is no concept of separate modules (a.k.a. files); script files are loaded in and simply concatenated one after the other. So if you load config.js and then another-file.js, the config variable (var config = { ... } ) will be available as a global variable in another-file.js. The module and require variables are not defined.

In more modern code with a module system, you have to export anything you want to use elsewhere, and import it in modules where you need it. Node.js uses module.exports = ... to export and ... = require("module-to-import") to import.