Re: Services, API keys, tests, etc.

On Sep 18, 2007, at 5:56 PM, Joe Stump wrote:

Now, both of these services have both public'ish API keys and secrets. The problem I have is publicly exposing my API keys and secrets via my package's tests. With Facebook it's minimized because you have to add the Services_Facebook PEAR application to your profile (I've created a junk account specifically for the tests), but Flickr is a bit more open I think, though you'd need to give the package access to your Flickr account before write operations could happen. I suppose I could create a junk Flickr account and do the same thing I did with Facebook ... Thoughts?

My plan for this sort of thing -- I'm running into a similar issue with unit tests for the new VersionControl_SVN package -- is to have a tests directory that contains a README, with instructions on how the tests directory needs to have "sensitive.ini" or some other sort of config file in it. That README defines what the config file needs to have, such as keys, shared secrets, etc. in order for tests to run properly. Then you commit and release the package with everything *but* your sensitive config information. Those who really want to run tests can read the README and configure their own local environment accordingly to run the tests. Might be worth an RFC for a "test/secrets.ini" proposal, so that there's one place that all packages which have tests that need some sort of account information can look for that info. secrets.ini: [VersionControl_SVN] login: clay password: foo [Services_Flickr] api_key: 1234456778889 [Services_Facebook] apikey: 12356789 ... and so on. The test can load parse_ini_file('@tests@/secrets.ini', true) and pick out the credentials needed by the package. Given the rise of web service packages that need exactly this sort of thing, this sounds better to me with every keystroke. :) -Clay -- Killersoft.com