Chrome’s badidea

If case you misunderstood the title, NO, Chrome is not a bad idea. It is my browser of choice for almost 10 years. It’s a great choice. However, because of the security restrictions, you may bump in pages like this:

In case of invalid certificate or some other similar issues, your browser will refuse to load a page of your choice. This is often a smart choice, however if you really know what you are doing, there is an easy way to bypass it. Till now in certain cases, you could expand the details view and continue on the site. In certain scenarios and for certain versions that is not possible anymore. If you google this error message, you will find a bunch of suggestion that may or may not work, although I find all of them cumbersome.
There is however an easy trick and I’ll write it down here as I continuously forget it and I need to poke a friend of mine, Damir Varga, who initially introduced me to it (and apparently has a better memory than I do).

Now back to the trick.

In case you are presented with the above situation, click anywhere in the page and type on your keyboard ‘badidea‘. That’s all, that simple. Your page will now load.

Top trick!

Happy browsing!

Persisting sensitive information with PowerShell

It often happens that I need to persist a password or another sensitive information strings in a file or database. When it happens I can never recall what was exactly the command I used to do so in the past. That’s why I decided to encapsulate the two operation of encrypting and decrypting a string in a cmdlet so that the next time I can just check my blog post.

A small preface about the operation of encryption. It is based on the ConvertTo-SecureString cmdlet which on its own uses Advanced Encryption Standard (AES) encryption algorithm. Supported key lengths by the AES encryption algorithm in this case are 128, 192, or 256 bits and they do depend on the specified key length.

As you can see, there are two required parameters, string that you are trying to encrypt and the key to use to encrypt it. As mentioned above, specified key must have a length of 128, 192, or 256 bits. This translate in a string with length respectively equal to 8, 12 or 16 chars. The calculation is simple, strings inside PowerShell are represented as 16-bit Unicode, instances of .NET’s System.String class, thus 16 bits per character. Knowing this, the maths is easy.
For record, if we haven’t specified any key, the Windows Data Protection API (DPAPI) would be used to encrypt the standard string representation and we wouldn’t be capable of decrypting our string on a different computer.
After we invoke our cmdlet, we will get back the encrypted string. We can then persist that information safely in, at example, our configuration file or a database field.

Once we need to read our value back we can use the following cmdlet:

Passing in the encrypted string and the key that should be used to decrypt the information, this cmdlet will return the decrypted string.

Following an example:

You can expect to see outputted console the “My strong super password”.

That’s all folks. Keep your sensitive information safe!

TextTransform issues after VS Project Upgrade

Recently I moved one of my projects from Visual Studio 2012 to Visual Studio 2015. Considering the project type, I was hoping for a smooth upgrade. However that was not the case. Once I tried building my solution I started getting the following error:

The command ""C:\Program Files (x86)\Common Files\Microsoft Shared\TextTemplating\14.0\TextTransform.exe"" -out "bin\LinkSet.xml" "App_Data\LinkSet.tt"" exited with code 3.

A quick search on Google gave me no results. This surprised me and I started to dig deeper hoping to understand what is causing this issue. In my project file I found a curios thing. Under the TextTransform related property group there was the following:

It is quite hard to spot the difference in these lines, however there is an important one. Lets go trough this MsBuild code:

_TransformExe propery is declared with a value that equals $(CommonProgramFiles32)\microsoft shared\TextTemplating\11.0\TextTransform.exe. In case that given path is not found the value will be overridden with the values in the following lines, until the path is found. In this way, the transformation tool will be found independently of the version of Visual Studio installed on your machine. There is however a small issue as the lines with a Condition set, in the value that is assigned, there is a quote at the end of the path. This quote will, later on, clash during the invocation of the tool at the line:

This leads me to the initial error message, you can see that in case Visual Studio 2012 is not installed on the machine I’m building with, the command executed will be like following "C:\Program Files (x86)\Common Files\Microsoft Shared\TextTemplating\14.0\TextTransform.exe"" -out "bin\LinkSet.xml" "App_Data\LinkSet.tt" which has one quote too much.
The solution is quite simple, edit your project file with the text editor of choice, find the incriminated lines and remove the final quote. You should end up with lines being modified like this

If you run your build now, it will succeed without the TextTransform.exe exiting with Code 3.