3

Let's say I do:

eval(
 db_config = {
                        host: 'localhost',
                        user: 'root',
                        database: 'forum',
                        password: 'test'
                    }
);

 var gamefunctions = require('gamefunctions.js');

I can use db_config anywhere inside gamefunctions.js without having to pass it through a parameter. That's pretty neat. But, is this bad practice?

Reason I ask this is because if I do:

 var db_config = {
                        host: 'localhost',
                        user: 'root',
                        database: 'forum',
                        password: 'test'
                    }


 var gamefunctions = require('gamefunctions.js');

db_config becomes undefined anytime I use it in gamefunctions.js. And I would have to pass it through a parameter on each different function which just seems like evaling it first would save time and code, any downside to this?

Does eval basically just define the variables in a global scope for you, so they can be used in any file in nodejs?

NiCk Newman
  • 1,716
  • 7
  • 23
  • 48
  • 5
    Yes; that is _atrociously_ bad practice. – SLaks May 29 '15 at 16:13
  • Regardless of `eval`, defining a variable without `var` will make it global. And this _is_ bad practice. – E_net4 May 29 '15 at 16:15
  • What I'm confused about is: If I don't define db_config, I have to pass it through every single function I create. Which is tiresome and seems unintuitive, when I could just eval it, I can use the db_config object/variable freely wherever I want... which is so much nicer. Unless there is some type of security issue with doing this.. I don't think I'll change.. lol – NiCk Newman May 29 '15 at 16:17
  • 2
    Variables in Node are isolated to the module or file they're declared within. Generally speaking, true globals are a bit of an anti-pattern in Node (note: [skipping the `var` is how it becomes a global](http://stackoverflow.com/questions/1470488/what-is-the-function-of-the-var-keyword-and-when-to-use-it-or-omit-it), not the `eval()`). If you need a variable in multiple modules, you should attach it to the `module.exports` of one module and `require()` that in the others. – Jonathan Lonowski May 29 '15 at 16:17
  • Oh wow @JonathanLonowski did not know that without var it became global inside node. Thank you for that. Yeah, I will not need to use eval now. Edit: Yep, now db_config working inside gamefunctions w/o var added thanks much! – NiCk Newman May 29 '15 at 16:23
  • `eval()` takes a string so the first block code you show would not even work. – jfriend00 May 29 '15 at 16:43

1 Answers1

1

You're doing 2 things wrong and there's much more elegant solution to this.

To explain what you're doing wrong, first is the use of globals. Second is that you're storing sensitive information in your code - your database password! And besides, it won't be very portable. Suppose you want to run it on another machine that has some other database credentials you'll end up changing your code unnecessarily.

You need to store it as environment variables. And if you end up hosting it some environments automatically have those set for you so you could use them in your app. For example openshift would have an $OPENSHIFT_MONGODB_DB_HOST that it tells you to use in your app to connect to its database.

And you need to create a separate file to store your db_config which you can require from other files.

So you might create a db_config.js which would look like this

var config = {};
config.host = process.env.HOST || 'localhost';
config.user = process.env.USER || 'root';
config.password = process.env.password;
module.exports = config;

Then you can safely just pass it the sensitive information like password from console

$ password=pass
$ node index.js

And as for having that information in your gamefunctions.js all you gotta do is require it

var db_config = require('./db_config');
laggingreflex
  • 32,948
  • 35
  • 141
  • 196
  • 1
    So, you think storing a database password in your environment is a safe practice where any script or program can access it? Flexible yes, but safe? – jfriend00 May 29 '15 at 16:49
  • @jfriend00 I think I should've said it's saf*er* than storing it in your code. But yes, I thought that's the best place to store your database passwords. – laggingreflex May 29 '15 at 17:03
  • OK, I'd disagree. I think the config file approach the OP was using is exactly what config files are for and better than environment variables. You simply modify the config file when you deploy in a different environment. That's what config files are for. It also makes the various configurable settings for the app entirely documented and self describing. – jfriend00 May 29 '15 at 17:08
  • @jfriend00 I'm concerned that if you host that code up on github you have your password out in the open. I've read that there are bots scanning public repos for exactly such sensitive info. – laggingreflex May 29 '15 at 17:12
  • 1
    Yeah. I guess I thought it was kind of a "duh" that you don't put your DB password on a publicly accessible github. Your scheme requires creating some script that sets environment variables which is something else you'd have to avoid putting on github. – jfriend00 May 29 '15 at 17:15