version-control – Ash Tewari

Protecting Your Api Keys

I am working on a Windows 8 app (details to follow in a subsequent post) and the code is published in a public repo on github. My app uses third-party APIs and after I committed the first cut to github, I realized that I had included my api keys in the code. The whole world had access to my keys. I did not want to publish the developer keys for those APIs to the entire world.

When the app will be released and distributed, those keys will need to be included in the app somehow. Once the keys are out there they can not be 100% protected from a determined mind. So, why bother? Why would I want to hide the api keys in the source code? Here are some good reasons –

1. It might be illegal to put the keys out there in plain sight for the whole world to see.
2. Developer keys may be throttled or have other restrictions on how many times they can be used per day or per minute.
3. The keys might allow access to expensive cloud computing resources.
4. The keys might allow access to confidential/sensitive customer data.

First, I had to take my keys back from git repo. Can you really remove information from a public git repository? Yes, you can, using git filter-branch. Here is how – https://help.github.com/articles/remove-sensitive-data. It worked! I successfully rewrote the history! My past commits don’t have those file(s) anymore that had my private api keys.

Next, I made sure that I don’t make this mistake again –

1. I added a new file ApiKeys.cs to the project.
2. Exposed the api keys as constants from a static class in this new file.
3 Added ApiKeys.cs in .gitignore file, to prevent this file from being committed to the repository.
4. Added instructions in ReadMe.txt for external developers to include their own keys.

This is not an ideal solution. If you are using a continuous build server, this technique will obviously not work. The code will not compile as-is, a file must be added to the project before it will start compiling. This works for me for now, but I am still looking for a better solution.

SVN Merge – Selecting Changesets

Here is a simple scenario – I have already merged changesets 45-55 from the trunk to branch b1. After this merge, more changes (56-60) were submitted into the trunk and I now need to merge those changes also to branch b1.

Which changesets do you select to merge ? 56-60, right ? Well, not exactly. It depends. If you are using Subversion merge command, you will need to specify 55-60. If you are using TortoiseSVN, you will select 56-60. You should keep this in mind if you are used to TortoiseSVN and you are attempting a merge using SVN merge command. Otherwise, you will end up with a merge without change 56.

Selecting changes to merge can become non-trivial when you don’t know which changes have already been merged. However, there is good news. With subversion 1.5, when you are selecting changes from source branch to merge into a target branch, don’t do it ! Subversion 1.5 onwards has built-in merge tracking. When using TortoiseSVN, if your intention is to merge all changes, just leave the changeset selection blank. Subversion knows which ones have already been merged and which ones to merge and it does it automatically. You can also select changes that have already been merged and those will be handled (excluded) automatically too.

There is a summary of what to expect from Subversion Merge-Tracking feature here – Subversion 1.5 merge-tracking in a nutshell.

There is detailed description of Subversion Merge-Tracking here and search for ‘mergeinfo property’ in Subversion documentation.

The above screen-shot shows the changes already merged in grey. Thanks to Subversion’s mergeinfo property.

So, can I just stop worrying about changesets altogether, when merging ? There are a few caveats to how mergeinfo metadata is (and sometimes not) recorded. Read this for more information – The Final Word on Merge Tracking.

Read about Subversion merging and branching here and TortoiseSVN merging documentation here – browse down to these sections : Reviewing the Merge Results and Merge Tracking.

Database Schema Version Control Tool

It is essential to treat database schema as source code and apply all the norms and best practices applicable to it. From what I hear and read, database schema version control is non-existent in too many projects.

Various techniques to accomplish version control of database schemas have been discussed and published. Martin Fowler and Pramod Sadagale has written a comprehensive article on Evolutionary Database Design. It is a must-read for everyone involved with database development.

K. Scott Allen writes in detail about an excellent system here – Versioning Databases – Change Scripts. This approach is sufficiently light-weight (for my taste) and provides complete control over the whole process.

I am providing a free tool here that you can use to implement this system. It will even create the SchemaVersionsLog table for your database, if it doesn’t exist. If you are using this tool with MSSQL Server, you can get started with very little effort. If you are using a different DBMS, you can still use this tool. It uses NHibernate to access the SchemaVersionsLog table. So, any DBMS supported by NHibernate is acceptable, as long as it comes with a command line tool to execute the sql scripts.

Download DbUpdater here.