Read the statement by Michael Teeuw here.
How to keep secrets out of config.js (server only)
-
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! :)
-
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.
-
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 canrequire
it from yourconfig/config.js
file.// config/secrets.js module.exports = { weatherApiKey: "key" }; // config/config.js var secrets = require("./secrets"); var config = { // your config }
-
@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 -
@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)
-
@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?
-
@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
-
You’re right, I forgot about the
if (typeof module !== undefined)
check. It might work if you setelectronOptions: { nodeIntegration: true }
in the config, but I haven’t tested it. -
what does that line below the modules actually do out of curiousity?
-
@BKeyport if this file is loaded into a module based application, then the interfacing approach (module.export) is created for this file/module…