cloud – Ash Tewari

KeyNode with Node.js and Microsoft Azure

KeyNode is a application to issue and verify software license keys. Technology stack for KeyNode is Node.js, MongoDB and Microsoft Azure.

I had built this functionality with C9.io (a cloud-based IDE with a built-in source code repository and debugger), mongohq (MongoDB as a service – now part of compose.io) and appfog (Cloud PAAS built on top of CloudFoundry). It used SMTP/gmail to email license files. That was the version I created a couple of years ago to issue tamper-proof signed xml license files for CodeDemo (a code snippet tool for developers, presenters and instructors).

For KeyNode (open source) I switched to a different toolset : Visual Studio Code and Windows Azure, simplified the code to remove signed xml file and open-sourced it on GitHub. Signed xml allowed offline verification in CodeDemo (a Wpf/Desktop app). Removing signed xml requires verification to happen online. I am working on adding the web endpoint for verification of license keys. This version uses SendGrid to email license keys. KeyNode is deployed as a Windows Azure Web App. The Azure Web App is on Continuous Deployment feed from the source code repository on GitHub.

I created and tested this Node.js application locally without IIS and deployed it as an Azure Web App without making any changes to the code at all. Node.js applications are hosted in Azure under IIS with iisnode. Iisnode is a native IIS module that allows hosting of node.js applications in IIS on Windows. Read more about iisnode here. Iisnode architecture also makes it significantly easier to take advantages of scalability afforded by Azure.

KeyNode is a work in progress. My plan is to use this as the basis for further explorations in the following areas :

DevOps, Docker and Microservices (at miniature scale of course!)
Create a Web UI with Express (a Node.js web application framework)
Integrate with Azure Storage/Queues
and more…

I invite you to check out the live site on Azure and fork it for your own experiments : KeyNode on GitHub.

Resources :

Photo Credit : Piano Keyboard (www.kpmalinowski.pl)

PackRaft with Xamarin and Microsoft Azure

PackRaft is a cross-platform mobile application built with Xamarin. It integrates with Microsoft Azure services, such as Azure Table Storage and Azure App Service. It is created with Xamarin.Forms for iOS and Android (Windows version will be coming soon).

The purpose of creating this sample application was to expand expertise in cross-platform mobile development with Windows Azure integration, specifically with Xamarin.Forms and Azure App Service. With Xamarin.Forms, it is possible to achieve close to 100% code reuse across these platforms for certain type of apps. Azure App Service provide a set of rich cloud backend services for your mobile applications.

PackRaft allows the user to setup a fleet of vehicles of various seating capacities. Groups of riders are assigned to these rides according to the count of riders in each group. You can specify that certain groups be kept together on a single vehicle – and the app tries to honor those requests if possible. I did this via a rudimentary implementation of a bin packing algorithm. This implementation is deployed as an API App in Microsoft Azure.

PackRaft uses Azure Mobile Services SDK to persist Fleet data to Azure Table Storage and to authenticate users with Facebook and Microsoft accounts. Twitter and Google account authentication is also supported by Azure Mobile Services SDK out of the box and those will also be enabled in PackRaft soon.

PackRaft is available on Android, iPhone and iPad.

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.

SQL Azure Notes

My invitation code for SQL Azure CTP finally arrived. I had been waiting for this.

You can create a database in from the SQL Azure Management page, shown above.

After you have created the database, of course, you can use DbUpdater with your SQL Azure databases. Here is the command-line :
DbUpdater.exe ..\SqlScripts /server:”tcp:SERVER.ctp.database.windows.net” /db:DATABASE /user:”USER@SERVER” /password:PASSWORD /confirm:true

And you will need this DbUpdater.exe.config file :

<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>
<appSettings>
<add key=”file-prefix” value=”db” />
<add key=”file-extension” value=”sql” />
<add key=”schema-versions-name” value=”schema-versions-table.sql” />
<add key=”baseline-name” value=”baseline.sql” />
<add key=”post-script-prefix” value=”post” />
<add key=”post-script-always-apply” value=”true” />
<add key=”exe-file” value=”C:\Program Files\Microsoft SQL Server\90\Tools\Binn\SQLCMD.EXE” />
<add key=”exe-args” value=’-U %UserName% -P %Password% -S “%ServerName%” -d %DbName% -i “%SqlFile%”‘ />
<add key=”dialect” value=”NHibernate.Dialect.MsSql2000Dialect” />
<add key=”driver_class” value=”NHibernate.Driver.SqlClientDriver” />
<add key=”connection_string” value=”Server=%ServerName%;Database=%DbName%;User ID=%UserName%;Password=%Password%;Trusted_Connection=False;” />
</appSettings>
</configuration>

You can run sqlcmd.exe directly to execute t-sql scripts on SQL Azure. Here is a sample command :
sqlcmd.exe -S SERVER.ctp.database.windows.net -U USER@SERVER -P PASSWORD -d DB -i “baseline.sql”

I received these errors when I executed my SQL Server 2005 scripts on a SQL Azure database –

‘ANSI_NULLS’ is not a recognized SET option.
Deprecated feature ‘SET ANSI_PADDING OFF’ is not supported in this version of SQL Server.
Deprecated feature ‘More than two-part column name’ is not supported in this version of SQL Server.
Deprecated feature ‘Data types: text ntext or image’ is not supported in this version of SQL Server.
Deprecated feature ‘Table hint without WITH’ is not supported in this version of SQL Server.

These are not the limitations of the SQL Azure platform. SQL Azure is based on SQL Server 2008 Database Engine. The complete list of deprecated features in SQL Server 2008 are listed here along with the replacements (if any) : Deprecated Database Engine Features in SQL Server 2008 – MSDN.
After modifying the scripts to replace the deprecated features, the scripts could be executed without any further issues. All stored procedures, triggers and views were created without any errors.

The following error is a SQL Azure limitation.

‘Filegroup reference and partitioning scheme’ is not supported in this version of SQL Server.

Here is more detailed information on unsupported T-SQL – Unsupported Transact-SQL Statements (SQL Azure Database) – MSDN