Configuration files are, well… files. File operations are risky- theres a lot of reasons why they might fail, and we have to be prepared to handle those execptions.

For example, maybe youve written an application that reads a configuration file at launch. If, for some reason, it failed to load that config, youd need to deal with that. If the configuration were just some minor settings, you might choose to fallback to some reasonable defaults. If, on the other hand, the configuration contained important security settings, you would probably want to quit the application, or maybe fallback into some safety mode.

Patrick U. assumed that was how the NodeJS application he was working on behaved. Then, one of his fellow developers pushed their latest release into production. He went to log into his admin account, and found his password didnt work- because it had been mysteriously changed to the incredibly insecure admin. After a little poking, he found someone had left off a closing-quote in their JavaScript configuration file, and that solved the problem. But why did his password get changed when the config file was broken? Well, this code was responsible for loading the file:

try {
  settings = require('../Settings');
}
catch (e) {
  settings = {
    users: {
      admin: { password: 'admin', is_admin: true },
      grace: { password: 'admin', is_admin: true },
      patrick: { password: 'admin', is_admin: true },
      bert: { password: 'foobar', is_admin: false }
    }
  };
}

[Advertisement] Manage IT infrastructure as code across all environments with Puppet. Puppet Enterprise now offers more control and insight, with role-based access control, activity logging and all-new Puppet Apps. Start your free trial today!

http://thedailywtf.com/articles/safely-configured