I have heard some say it isn't but they never suggest an alternative. Is this true?
UPDATE Is it possible to store this external from application and have it called?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
In Enterprise environments, storing any kind of credentials (Keys / usernames etc) in applications is highly discouraged.
All such credentials should be stored on:
This way you can enforce ACL* on these. And only the user id running these apps should have access to these. For example, you can create user ids "accounting_producion" or "accounting_qa". And app should run as these users. And only such users + support users should have access to configs.
And any change can be quickly propagated though all instances.
ACL -> Access Control Lists
I'd vote definitely in the configuration -- you'll probably want to, at the least, have a different key for dev and/or staging. Having it in the configuration file makes the most sense as this is typically different for each environment.
Note that if we are talking about an interperted vs compiled environment, said configuration file could be whatever language you are using rather than xml/yaml/json/.ini/whatever format you just made up.
In light of your comment, consider this question in terms of an API key: are you going to assign the same key to every user of your API?
Consider a scenario in which you are being attacked. You can isolate the source of the attack by IP address, and see that it's coming from a company with access to your API key. You must assume that their key has been compromised. However, if your API key is hard-coded, you will need to change the API key in the application, redistribute the application to every customer, and make sure that any of the customers' applications/services which rely on your API have been modified to deal with the new API key.
This is a cost for both your company and your customers; it could influence your relationship with your customers negatively.
If, instead, you store your API keys in a database, one per customer, you can simply run a single SQL query and fix the problem.
I generally try to get everything which is environment dependent out of the application. I haven't run across a configuration item such at you listed which needs to be in the application for technical reasons. It looks like you are looking for your options.
Many items are well suited to being placed in a configuration files. The rest of the items should work well when placed in the applications database.
Some run-time environments contain variables and/or command line arguments which the application can read. These are a good choice for configuration items which you may need to override for a particular run.
Placing configuration items in the application means you need to have environment specific compiles. This can result in problems which can only be replicated in one environment, because that is the only environment which has the broken code. It also risks that the wrong version will be built for the next environment.