TL;DR

• git clone or download the project I have on GitHub here
• In index.js paste your Bearer token string (Base64, no "Bearer " prefix) into the token variable
• Paste your public key X.509 Certificate string (without PEM prefix/suffix) into the x5cString variable
• Run npm install and then node . from the command-line

If your token is printed out on the console then verification/validation succeeded. Otherwise, an error message will be displayed.

Consider using additional verify options for improved security once you have the basic public key verification working.

Background

Let's say that you have an API endpoint using Node.js (Express, LoopBack, Feathers, etc.) and you want to accept JWT Bearer Tokens issued by Azure AD. This is a terrific, stateless way of doing single-sign-on (SSO) between say, Microsoft Office 365 or SharePoint and your own custom single-page application (SPA).

You'll find some good examples for using ADAL within the browser to get the Microsoft Azure AD-signed Bearer Token.

However, what is perhaps not so clear is how to validate or verify the Bearer token on the Node.js side in your API code. This little show-and-tell blog article describes the "trick" needed to perform the JWT Bearer token verification.

Start Down the Rabbit Hole

I'm going to say right off the bat that Microsoft seems to make this whole thing a bit more complicated than it has to be. I started by reading this article, which tells me to examine this online JSON document that contains a "jwks_uri" value pointing to this URI where the actual public keys are stored.

The public keys are provided in JSON format as well, and you must cross-reference into them to find the right one for your particular Office 365 tenancy presumably.

Let me explain what I mean by "cross-reference". Here's what the public keys JSON file looks like. Notice that there are 3 elements (objects) in the array of public key data (as of this writing).

{
  "keys": [
    {
      "kty":"RSA",
      "use":"sig",
      "kid":"z44wMdHu8wKsumrbfaK98qxs5YI",
      "x5t":"z44wMdHu8wKsumrbfaK98qxs5YI",
      "n":"p3HhMQsqmgSjeiDsZ1ay...",
      "e":"AQAB",
      "x5c": ["MIIDBTCCAe2gAwIBAgIQaD0..."]
    },
    {
      "kty":"RSA",
      "use":"sig",
      "kid":"SSQdhI1cKvhQEDSJxE2gGYs40Q0",
      "x5t":"SSQdhI1cKvhQEDSJxE2gGYs40Q0",
      "n":"pJUB90EMxiNjgkVz5CLL...",
      "e":"AQAB",
      "x5c":["MIIDBTCCAe2gAwIBAgIQHJ7yHxN..."]
    },
    {
      "kty":"RSA",
      "use":"sig",
      "kid":"2S4SCVGs8Sg9LS6AqLIq6DpW-g8",
      "x5t":"2S4SCVGs8Sg9LS6AqLIq6DpW-g8",
      "n":"oZ-QQrNuB4ei9ATYrT61ebPt...",
      "e":"AQAB",
      "x5c":["MIIDKDCCAhCgAwIBAgIQBH..."]
    }
  ]
}

The main index into the objects in the array is the "x5t" value (X.509 "Thumbprint", see this spec):

• z44wMdHu8wKsumrbfaK98qxs5YI,
• SSQdhI1cKvhQEDSJxE2gGYs40Q0, or
• 2S4SCVGs8Sg9LS6AqLIq6DpW-g8

Following so far? Great.

Cross-Reference Azure AD-Issued Token to get the Correct Public Key

To determine which public key your particular Bearer token can be verified with, examine the corresponding "x5t" value in the header section of your Bearer token.

Then, from the matching object in the keys array (shown above and as mentioned above, available here), take the "x5c" value to construct your actual public key for token verification purposes.

Construct the Public Key

Now that you have the correct "x5c" string you're almost ready to verify your Bearer token! Wow, right?

The "trick" in this final step is to note that the "x5c" string is, as the label implies, an X.509 Certificate.

Therefore, to successfully use this "x5c" string as a public key argument to a JWT token verification call, you need to perform a small string concatenation to put it into the expected PEM format (also see here).

var token = '...';  
var x5cString = '...';  
var publicKey = '-----BEGIN CERTIFICATE-----\n' + x5cString + '\n-----END CERTIFICATE-----';  
...

// Verify
verifiedToken = jwt.verify(token, publicKey);

"Raft 2.0" Scene in Cast Away

An apt metaphor for Microsoft and .NET Core pushing into previously uncharted waters (for them) and the world of free and open source software.

Because remember, there was "Raft 1.0".

I'm not saying that .NET Core 1.0 was a failure. Just as Chuck Noland learned from his 1.0 effort, Microsoft did the same. And with 2.0 it feels like we've successfully escaped our little island. There's no going back, and it's clear sailing from here.

With .NET Core 2.0 Microsoft has managed to deliver on both platform and tooling at the same time, and deliver big.

Platform

But let's start small and mention that ARM32 support is now available for Linux and Windows. So if you've been wanting to write C# for your Raspberry Pi IoT device, have at it.

Raspberry Pi

The Windows option is Windows 10 IoT Core Edition. And for Linux there are multiple distributions available.

.NET Standard

.NET Standard 2.0 is supported on the following platforms:

• .NET Framework 4.6.1
• .NET Core 2.0
• Mono 5.4
• Xamarin.iOS 10.14
• Xamarin.Mac 3.8
• Xamarin.Android 7.5

So .NET Standard 2.0 is now the way to do portable libraries. The Portable Class Library (PCL) approach has been deprecated.

Cloud

Microsoft has already added support for .NET Core 2.0 to Azure Web Apps in all Azure regions.

Performance

There's an overall performance improvement of around 20% in .NET Core 2.0 due to several factors such as RyuJIT and PGO.

Tooling

There are so many improvements in the area of Visual Studio tooling that it really deserves its own blog post, so stay tuned for that.

Wrap Up

If you're a .NET developer like me, perhaps "your ship has finally come in"...

in the form of .NET Core 2.0.

You've got to be impressed with the commitment and coordination required to push all of this at the same time:

• 3 Visual Studio Flavors (Windows, Mac, VSCode)
• .NET Core
• .NET Standard
• ASP.NET Core
• Entity Framework Core
• Azure

Quite an accomplishment for Microsoft and a terrific sign for those who make a living working on and deploying systems on the Microsoft stack!

Pull Requests

So now you're ready to make your first "Pull Request" and give back. You want everyone to benefit from the bug fix or new feature you've come up with for this widget.

And just as importantly, you'd like to stay up-to-date with everyone else's improvements to the source code repository as well.

Getting the Latest Upstream Changes

To do this, make sure that you have added an upstream remote to your fork. The command for that is:

git remote add upstream https://github.com/REPO/REPO.git  

Now whenever you want the latest changes added to your local branch just run these two commands:

# Fetch any new changes
git fetch upstream

# Merge any changes fetched into your working files
git merge upstream/master  

Maybe you really need to support multiple SQL databases right now, or you want to write code that has some hope of being database-agnostic in the future.

And you don't particularly like the idea of an object-relational mapper (ORM) layer, at least for now.

If any of those criteria seem to fit your thinking, and you'd like to write your database queries and data seeding (DML) and/or schema migrations (DDL) in JavaScript, CoffeeScript, or TypeScript, then Knex.js is worth trying!

Who Uses It?

You'll be in pretty good company if you use Knex.js (or its sister project Bookshelf.js that provides an ORM layer). For example, the Ghost Blogging platform uses Bookshelf.js.

Training

You can visit the Knex.js site to learn more, but I also highly recommend the Pluralsight course "Data Access in Node.js Using Knex" by Carlos Saloio.

More Info

I also plan to write a number of additional blog posts about Knex.js myself, with a particular focus on TypeScript, so stay tuned!

Well, first you should know that Twilio will automatically handle replies that include words like STOP, so you don't need to worry about that.

But for other replies, perhaps you want a simple message informing your recipient that it's best to contact you via email.

To do this, the key concept to understand is that Twilio wants to read your message text from some public URL that you configure. So you'll need a public folder on a website that you control, and you'll need to place your message in an XML file in that folder. Twilio will make HTTP requests to your site just like a regular web browser.

For example, here's a sample Reply.xml file.

<?xml version="1.0" encoding="UTF-8"?>  
<Response>  
  <Sms>
      Thanks for replying. The best way to contact us is
      by email at you@yourdomain.com.
  </Sms>
</Response>  

Let's say that you have placed this file on a website at the following URL: http://www.yourdomain.com/public/Reply.xml. Now, you need to tell Twilio about this URL. You can do this in one of two ways: (1) Directly on an individual sender telephone number, or (2) Using a group of sender numbers under a "Messaging Copilot" service.

I'll describe the more flexible "Copilot" configuration, available from your Twilio account at https://www.twilio.com/console/sms/services.

Click on the big red button to add a new messaging service. You'll want to configure the "Request URL" setting to point to the URL for your Reply.xml file. In this example: http://www.yourdomain.com/public/Reply.xml. Be sure to specify the correct protocol: http or https.

That's it. As long as Twilio can access the Reply.xml file you should now see your auto-response message when replying to SMSs.

It's beyond the scope of this post, but it's also possible to dynamically emit response messages based on context, etc. To do this, you can include parameters and values in the configured URLs. Twilio sends this data to your site so that you can act upon it before responding.

The JavaScript community has in some ways caught up to or overtaken Meteor, so the Meteor folks have had to adjust.

Meteor 1.3 is the first release that really manifests the adjustments that are being made.

ES2015 Modules

The big ticket item in this release is support for ES2015 (aka ES6) Modules. While Meteor 1.2 added support for ES2015 syntax, full support for modules was not included.

This move reflects the way that the JavaScript language itself has caught up to the once unique Meteor Package concept. And it acknowledges the popularity of npm as Meteor moves toward full support for and use of npm.

Mobile Support via Cordova Greatly Improved

Meteor 1.3 now uses the latest version of Cordova (6.0.0) and on iOS now supports WKWebView for dramatic performance improvements. Hot code push for mobile apps is also greatly improved:

...wrappers detect and handle faulty JavaScript application code. It is now possible to recover from hot code pushes of broken code that previously required an application reinstall. The hot code push system is also much faster and uses incremental and resumable updates to save network bandwidth and battery life.

On the Horizon

Next up in Meteor 1.4 we expect to see an upgrade of Meteor to Node.js version 4 and MongoDB 3.2. I'm looking forward to those improvements!

This is an important release, and it really emphasizes what Meteor can offer as a complete development platform based on JavaScript.

For example, view engine frameworks such as Angular and React are now supported on the Meteor platform.

And the latest incarnation of JavaScript itself, ES2015, is fully supported across all JavaScript code written for the platform (from browser to server).

Think about that for a moment. Meteor isn't just a web framework, it's an entire platform providing code compilation and optimization. Otherwise, how would it be able to support ES2015 across both client and server?

As the Meteor folks said in the announcement:

...we think anyone writing an app in JavaScript should be using ES2015. And it's going to drive a lot of new JavaScript adoption from developers used to other languages. So we're all in on it: the Meteor tutorial and a growing fraction of Meteor core is now pure ES2015. We've found that it lets us write dramatically more concise and readable application code, thanks to built-in support for classes, block variable scoping, arrow functions, template strings, and numerous other improvements to the language. To learn more about ES2015 and how valuable we've found it in our own work, watch Ben Newman's recent Devshop talk.

And as a platform, Meteor has improved some internal performance factors as well in version 1.2. For example, the distributed data protocol (DDP) used by Meteor to send data (e.g., an Episode document) down to the browser now uses compression to reduce on-the-wire bandwidth. And on the server, Meteor has improved MongoDB oplog tailing logic to reduce the overhead of notifying clients of large numbers of writes.

If you've been reading my other posts about Meteor, the improvements in version 1.2 offer all the more reason for you to check out Meteor for yourself.

This type of utility is very useful, particularly for generating fake data for testing data validation logic. The utility was developed by an engineer out of the MongoDB Inc. New York City office.

A nice summary report from the "Rapid Start" sessions is typically delivered to the client, and a brief mention of the mtools fake data generator usually appears on the final pages of the PDF, including the fake data "template" used to generate documents. This template could easily be adapted for data validation testing.

One piece of technical information presented on the topic of Indexing makes for a nice blog post that can be referred to again later. So let's jump right in.

Compound Indexes reference multiple fields from a collection in a single index structure. This is probably the most helpful type of index to create for optimizing a particular query, such as a query that searches for Customers.

The developer or DBA creating a compound index must determine the optimal field order within the index. The concept is to let selectivity drive the order of the fields.

• Order fields in a compound index from most selective to least selective
• Usually, this means equality fields (fields queried for a specific value) before range fields (e.g., date fields queried for a particular time period)
• When dealing with multiple equality values, start with the most selective

The desired sort order of the query results must be considered as well. And when we consider sorting, we can summarize the general rules of thumb for the optimal compound index as follows.

• Equality before range
• Equality before sorting
• Sorting before range

MongoDB has supported bitwise update operations for some time. But if you wanted to find or atomically find-and-modify documents with fields matching a certain bit pattern you were out of luck. But now, as of Developer Preview 3.1.6, bitwise query support is built-in.

Example

For data collection systems with many multi-select lists and checkboxes to deal with, this could be a particularly useful feature. You may be storing these lists as an array using (at least) 4 bytes (int32) to save each and every selection made by the user. With a multi-select offering, say, 30 options/checkboxes, if the user checks all of them that's 120 bytes.

By storing this information in a bitwise fashion in a single, 32-bit value, for example, the space occupied by the element would be 4 bytes, regardless of which checkboxes are checked by the user.

Yes, this savings of 116 bytes seems negligible. But if we saved this over 20 fields per document, and 500 documents per quarter, and 1000 users per quarter, it adds up! In this example, it adds up to a savings of about 1GB per quarter, per database by my calculations. If you had 25 such databases, that's roughly 100GB in space savings per year.

Bitwise Storage Can Improve Overall Performance

To quote a MongoDB blog post regarding data compression:

Size is one factor, and there are others. Disk I/O latency is dominated by seek time on rotational storage. By decreasing the size of the data, fewer disk seeks will be necessary to retrieve a given quantity of data, and disk I/O throughput will improve. In terms of RAM, some compressed formats can be used without decompressing the data in memory. In these cases more data can fit in RAM, which improves performance.

So there's more to be gained by implementing bitwise data storage schemes than simply the cost savings on storage media.

Another subtle implication of this bitwise approach is that updates to these types of elements in a given document can occur "in-place" without expanding the size of the document.

Git-TF to the Rescue

With the cross-platform Git-TF tools, you can use Git to work with TFS. A couple simple commands provided by Git-TF allow you to push your Git commits as TFS check-ins, pull the latest code from TFS into your Git repo, etc.

One of the nice side benefits of syncing your Git repo with a TFS folder is that you can organize your code in whatever local folder structure you wish. With a typical TFS-based project, your local folders must match the structure defined in the central TFS location. But with Git-TF, you can hook up your local Git repo folder to whatever TFS central folder or sub-folder you wish to synch with.

Git-TF Workflow

Here are the Git-TF commands that you'll want to learn.

For initial setup of a Git repo based on a folder in TFS, run a command like the following.

git tf clone https://yourproject.visualstudio.com/DefaultCollection $/YourRepo/SubFolder repo  

That command should be run with your current working directory set to the parent folder for your new, local Git repo. And in this example, the subfolder repo is being created. The TFS folder to which you are mapping is indicated with the opening dollar sign, which in this example is $/YourRepo/SubFolder.

After that initial setup is out of the way, change your working directory into the subfolder you just created. For example:

cd repo  

And now you may want to configure your TFS username and password so that you won't be prompted for them every time you issue a command.

git config git-tf.server.username YourUsernameOrEmail  

git config git-tf.server.password YourPassword  

Now you make your changes to the files in your local Git repo and commit them locally as needed.

git add --all .  
git commit -am "commit one"  

git add --all .  
git commit -am "commit two"  

Finally, you sync your local changes and any remote TFS changes made by others with these two commands:

git tf pull --rebase  
git tf checkin  

That's it for the typical workflow. Rinse and repeat the last 4 commands (add, commit, pull, and checkin).

I'd recommend creating a batch script in your local repo folder (call it tf-checkin.bat for example) that prompts for your commit message and executes all of the commands. Here's an example:

@echo off
SET /P CM=Enter Commit Message:  
git add --all .  
git commit -am "%CM%"  
git tf pull --rebase  
git tf checkin  

TFS Online and SSL

When syncing with a TFS Online project, Git-TF will be hitting an SSL connection. Under the hood, Git-TF uses Java, so you may need to configure Java to use your org's SSL certificate. Here's an example of the command to do that.

"C:\Program Files\Java\jre1.8.0_51\bin\keytool" -import -keystore "C:\Program Files\Java\jre1.8.0_51\lib\security\cacerts" -alias startssl -file "M:\My Org Cert\MyOrg-CA.cer"

I was prompted to enter a password for the keystore. The default password is: changeit

Note that the paths in the example command above will be different depending on the version of Java installed on your system. In the example above, the version 1.8.0_51 is referenced in two places.

Git and SSL

Git itself may also complain that you have a "self signed certificate in certificate chain". If that happens, run the following command too.

git config --global http.sslVerify false  

Conclusion

I think you'll find that investing a little time to learn Git and use Git-TF for code located in TFS will save you a lot of time and frustration down the road.

Query Builder

The visual Query Builder is what people new to MongoDB (and partial to SQL syntax) will appreciate the most, because it eases you into the JSON-based query language that is natively supported by MongoDB, making you productive with MongoDB immediately.

You can easily:

1. Select a "table" (MongoDB Collection, as in the left-most pane in the screenshot below)
2. Drag a field from the table-view of your MongoDB Collection (the middle pane below), and
3. Drop the field into the Query Builder (the right-most pane) to build up your "where" clause and to specify sorting and projection (which fields should be included or excluded)

Screenshot 1 - MongoChef Query Builder

MongoDB 3.x Support

One of the shortcomings of some other offerings such as RoboMongo is lack of support for the new storage engines introduced in MongoDB 3.0.

MongoChef fully supports MongoDB 3.0, including the WiredTiger and In-memory storage engines.

Licensing

MongoChef is offered for free for "non-commercial" use, which I take to mean that if you are simply using it to personally learn MongoDB, you are honoring the terms of the free license. Otherwise, MongoChef is licensed per-person (on as many machines as that person wishes to use) for $99.

Conclusion

MongoChef by 3T Software Labs is a worthwile tool with many useful features. It comes recommended/sponsored by Red Gate Software. Check it out by registering on the 3T website.

Here's a summary of the new features mentioned in the announcement:

• Support for BI and Visualization Tools. A new connector for BI and visualization provides SQL-based access to MongoDB, opening up data from modern applications to the BI and Visualization tools used by 100s of millions of information workers, including Tableau, BusinessObjects, Qlik, and Cognos. The connector provides unprecedented performance and scalability by leveraging MongoDB’s powerful Aggregation Framework to process data within the database.

• Encryption for Data at Rest. Building on MongoDB’s extensive security features, including encryption for data on the wire, MongoDB 3.2 will add a new option for encrypting data at rest, with keys secured by the industry standard Key Management Interoperability Protocol (KMIP). At-rest encryption is especially critical for regulated industries such as healthcare, financial services, retailers and certain government agencies. Security is top of mind for CIOs today, and with encryption for data at rest organizations can address their stringent security requirements.

• Document Validation. For decades, organizations have relied on databases to play an integral role in their data governance strategy by ensuring the quality and integrity of their data. With MongoDB 3.2, document validation rules can be applied to one or more fields to verify data types, values and the presence of mandatory fields. By combining document validation with MongoDB’s dynamic schema, organizations will have enormous flexibility in defining rules that ensure data quality while simplifying application development.

• Dynamic Lookups. A key to enabling access to BI and Visualization tools is the ability to combine data across collections. Lookups provide greater flexibility for modeling data and add to the wide range of use cases for which MongoDB is well suited. With MongoDB 3.2, lookups will be available as part of the Aggregation Framework.

• Schema Visualization. A new graphical interface to MongoDB, code named mongoScout, will provide developers and DBAs a powerful, intuitive interface for exploring and understanding their data structure. In addition to displaying individual documents, mongoScout analyzes collections to visualize the existence of fields and the cardinality of their values. DBAs and developers can use mongoScout to make intelligent decisions about indexes and validation rules.

I haven't been able to find any further details related to the Document Validation feature. I'm curious to know how this will be implemented.

A follow-up announcement will be released soon with information about the availability of an advanced beta program for previewing these new features before their full release, which is slated for Q4 2015.

I think that people who haven't learned yet how to write modular or object-oriented JavaScript, but who are fluent in C#, will appreciate a tool like this. But this is a commercial tool with as-yet unspecified pricing, which will certainly dampen enthusiasm.

I've tried other transpilers such as CoffeeScript, and I can't say that I'm really a fan of them, especially when the two languages in question are very similar. I do very much like the idea of simpler syntax and "sugar" that transpiled languages offer, but I find that there's a cognitive overhead that I can't get away from.

This cognitive overhead occurs because in my head I'm aware of the syntax of both languages and I'm often "mentally transpiling" and thinking about what the output will be when I write the to-be-transpiled code.

So when it comes to JavaScript and transpiling to it from CoffeeScript or C#, my take is that it is better to just learn and use the JavaScript syntax itself.