Moq, according to its GitHub page, is “The most popular and friendly mocking framework for .NET”.
Mocking frameworks allow you to create a ‘fake’ version of a dependency (typically an interface, or abstract class).
With this fake, you can then instruct the methods return values, or invoke behaviour.
Alternatively you can assert the methods were called, with a certain set of parameters.
How we verify these methods were called can affect the maintainability of our tests.

Let’s suppose we have this interface.

Which is a dependency of the class we’re testing:

Our method takes a firstName and lastName and creates a Customer object using those parameters.
It then passes that Customer object to the Save method on the injected ICustomerService.
For the purposes of our test, we inject a mocked ICustomerService
The Save method returns an int, so we set our mocked method to return 1, when it is called with any Customer object.

Our unit test could look something like this:

This test will of course pass. But, if we make a small change in our CustomerController

Now our test will correctly fail.
However the exact reason for the failure isn’t clear:

All this tells us is that we didn’t call our dependency with an object that matches. It doesn’t give any indication as to why that object didn’t match.

Moq has a Callback function which we can use to assign our mocked ICustomerService.Save method to a variable outside of our setup.
Later on, we can use this variable for assertions.

And now, we can individually assert on each parameter:

If we run this test (without fixing our code from the previous failure) it now gives a much clearer failure:

I was recently working on a requirement to log the number of breached sites a password appeared on when customers were registering (if that password had been breached at all)
Importantly, we are not logging the breached password itself (nor the hash of the password) – just the number of breaches that particular password appeared in (as per the Pwned Passwords data set)

So, to log this, I’m raising a custom Application Insights event, using the client side Javascript SDK.

Pwned Passwords implements a k-anonymity approach to protecting the hashed passwords, to prevent the necessity to call the API with the full password hash. You can’t validate the entire hash, by calling the API with it.
Instead, you call the API, supplying the first 5 characters of the hash.

For example, the SHA1 hash of ‘password1’ is e38ad214943daad1d64c102faec29de4afe9da3d
So, to test if ‘password1’ has been breached, we call the Pwned Passwords API, specifying the first 5 characters of that hash as a parameter:

https://api.pwnedpasswords.com/range/e38ad

That returns some 486 results in total. In other words, 486 breached password hashes start with e38ad
The results are all the suffixes of those hashes, along with the number of breaches that hash appeared on.
This way, we can validate if that password hash appears in the breached list, without giving away the password, or even the hashed password, by searching the list for the original password hash; minus the first five characters:
pwnedpasswords e38ad results

We can see that the suffix of our hash is in that list:
e38ad214943daad1d64c102faec29de4afe9da3d

So far, so good, we can perform this client side quite easily, and send our custom event to Application Insights.

Here’s a documented, cut down version of the code I was using to do that:

This worked great.
The problem, however, is Application Insights, by default, logs dependencies, and other telemetry.

If we take a look at End-to-end transaction details of our logged custom event, we can see that before our CUSTOMEVENT is logged, we have a dependency – an Ajax call, to api.pwnedpasswords.com/range/e38ad

App Insights showing AJAX call to pwned passwords API

Our custom event, by design, contains the number of breaches.

In a lot of cases, this breach number was unique in the returned range.
In the case of ‘password1’ (at the time of writing) this number was 2391888.

When plain text searching for ‘2391888’ (the count, recorded in our custom event) we can see:
pwnedpasswords e38ad results - count

Join the prefix, to the returned suffix and we know the full hash is:
e38ad214943daad1d64c102faec29de4afe9da3d

Because these are generally ‘weak’ or breached passwords, we can try a SHA1 reverse tool, such as: https://isc.sans.edu/tools/reversehash.html – which gives us the correct, original password: password1

The security risk here is incredibly low…

For a start, our Application Insights instance is obviously protected.
Secondly, not every password can be reversed. Also, the count may be something quite low, like 1, or 2 – hundreds of breached passwords returned in the range query may also have a breach count of 1, or 2.

However small the risk, I wanted to eradicate this, while still using the client-side Javascript SDK for Application Insights.
I’ve written a separate post on how to Hide Sensitive Data with Application Insights JavaScript SDK using a Telemetry Initializer

Another possible solution…

This would require the PwnedPasswords api to change slightly, but instead of returning the whole suffix of the hash, perhaps the last n characters could be returned.
By omitting 5 characters from the start of the suffix, the collision rate would be sufficiently low enough, but make hash-reversal impossible.

Just a thought…

Application Insights is incredibly powerful, especially when using the JavaScript Client SDK.

The problem is, sometimes we can be logging a little too much.

In a recent post, I explained how I needed to log the number of breaches a breached password had appeared on, using the Have I Been Pwned API.
The trouble was, since I was doing all of this client side, the AJAX request was visible as a dependency of my custom event log.
The AJAX request contained information that allowed me (or anyone with access to Application Insights) to piece together the full password (hash) in some cases.

My paranoid mind didn’t like this.
I needed to obfuscate the irrelevant data in the GET request to that particular API.

All I really needed to do is stop the Ajax dependency call logging the hash prefix part of my query to the api.pwnedpasswords.com endpoint.

To solve this, I created a very simple telemetry initializer.
This function runs for each piece of telemetry recorded, and checks to see if the target is “api.pwnedpasswords.com
If it is, it simply replaces (for example) /range/e38ad with  /range/{SHA} whilst still recording that the call was made.

Adding this just after initialising the Application Insights SDK did the trick:

Application Insights now receives this dependency call as /range/{RANGE} (as opposed to the actual hash prefix)

As some people know, I run a web development agency called Cohoda LTD.

As part of our service, like most development agencies, we offer web hosting. To keep things as lean as possible, we deliberately don’t try to host email servers ourselves, instead we set up clients with email on Google GSuite (or Office 365 if the client prefers)
I always (where possible) use CloudFlare for DNS, and found myself repeatedly entering the same MX records for each domain, time and time again.

CloudFlare has a handy “Upload DNS File” feature tucked under ‘Advanced’ at the bottom of your DNS entries.

Here, you can specify any file to upload (which must conform to the BIND format to work)
On upload, those DNS entries will be added.

Here’s one for quickly adding GSuite (Google Apps / Gmail) mx records to CloudFlare:

Simply save this as (for example) gsuite-cloudflare.txt and upload that when you want to quickly add Google Apps mx records to your domain in CloudFlare.

I travel from Farnborugh main to Waterloo reasonably regularly, and it works out cheaper for me to buy monthly season tickets, with a Travel Card (allowing travel on the underground and busses)

I was recently looking at how much extra a First Class season ticket would be than Standard Class.

Turns out, South Western Railway are charging a premium – for the Travel Card portion of the First Class ticket!

We can see this as follows:

Standard Class – Without Travel Card

£373.70

Standard Class – With Travel Card

£456.60

This means, the Travel Card portion of this fare is £82.90

Now, let’s take look at First Class season tickets:

First Class – Without Travel Card

£635.20

First Class – With Travel Card

£776.10

As before, we can work out the Travel Card portion of the fare:
£776.10 – £635.20 = £140.90
That equates to £140.90 for the Travel Card.

Charging £58 on top of the ‘standard class’ Travel Card portion.

Last time I checked (I travel on the tube most days) I couldn’t find a first class carriage?

Page 1 of 41