OAuth2 and LabVIEW — Revisited for 2020, Using the New SHA256 VI

After LabVIEW 2020 released, I thought I should revisit my OAuth2 example to see how I could apply new features to improve the code. I thought it would be simple and straightforward and magically better, and fit into a single blog post. But, I think it’s going to be more of a journey than that.

I decided to start with something simple: LabVIEW 2020’s implementation of the SHA-256 secure hash that’s needed for the code verifier. This ought to be able to replace the SHA256.vi in my 2019 example, which was based on a .Net call. This is one of the only things that was Windows-specific in my code.

My first step was to create a new repo for my 2020 code. I think I want to keep my 2019 version around, so I’m hesitant to create a branch to merge back into it. I may regret it, but it felt like a new repo was the way to go.

Next, after loading the project into LabVIEW 2020, I went to SHA256.vi and selected Find -> Callers. It’s only called from two places, one of which is a unit test helper VI. (Aside: The unit test was only listed because it used a helper VI. If you think that Find -> Callers should have also reported which .lvtest files call the VI, kudo this idea.)

Good, I thought–I have unit tests and can ensure that the new VI passes all my old tests. Spoiler alert: it wasn’t that easy. Keep reading below.

First, I had to find the new VI. I knew the functionality was there; I remember it from the release notes. Ctrl-space to bring up Quickdrop, and I typed “SHA”. Hmm. Not found.

Next, I went and poked around in the Connectivity -> Web Services palettes. Also not obviously there.

Finally, I went and read the 2020 upgrade notes. Ah, it’s called “Byte Array Checksum.vi”. Of course! Where is it on the palettes? It’s in Mathematics -> Numeric -> Data Manipulation.

Now that it’s found, I should be able to drop it in place. I think my best approach is going to be to open my existing SHA256.vi and use a diagram disable structure to let me switch between the two implementations.

Oops, data type mismatch. The 2020 VI takes a byte array, not a string. Not a bad design choice, and a simple fix to just move the string to byte array outside of the structure:

Next, I right-click on my SHA256.lvtest and run it…

And it failed. Sigh. Let’s put it back to the original code and verify it passes. It does. So let’s take a closer look. The simplest test just runs the VI with the input string with a single letter ‘a’…

Now, let’s run with the 2020 VI enabled…

Wait. What? The string is the wrong length, and clearly not the same as above. But, it looks suspiciously like ASCII, so I suspect I know what’s wrong.

As the output label says, the result string has Hex Display turned on…

Let’s turn that off and see what the string looks like:

So, the computation is “right”, but it encodes the string a different way. Let’s take a look inside the 2020 VI:

Okay, so there’s a VI which creates a SHA256 object, wired to a malleable VI to apply that function to the array, followed by our culprit, “Bytes to Lowercase Hex String.vi”.

---

I’m grateful that I had unit tests to test the new VI. Otherwise, I would have embedded the new code deep inside my app, and would have had to peel it apart to debug it.

---

The LabVIEW team made the design decision to convert to a lowercase hex string for me. I’m not sure I like that, but maybe that’s just my bias because I’ve already got a VI that leaves that step out.

Before I pass judgement, let’s go look at the actual usage of the SHA256.vi in my application. If I follow the hash with a convert-to-lowercase-hex-string, then I can conveniently get rid of it and let the 2020 VI do the work. Alas, it is not to be…

The byte array is converted to ASCII, but using the more common (in web apps) Base64URL encoding. So as-is, the 2020 Byte Array Checksum.vi isn’t useful in this situation. What should I do?

I can think of three choices:

1. Ignore the 2020 VI and just use the .Net implementation I used in 2019.
2. In my SHA256.vi, add code after Byte Array Checksum.vi to convert the hex string back into a binary array.
3. Make my own copy of Byte Array Checksum.vi and remove the subVI which converts to a lowercase string.

Which would you do? Comment below, and stay tuned for another blog post to see my choice.

---

Read the other articles in this series:

• Part One — Setting up a LabVIEW Web Service Callback Function
• Part Two — The Authentication Process
• Part Three — Improving the Example
• Part Four — Reusability
• OAuth2 and LabVIEW 2020, Using the New SHA256 VI
• OAuth2 and LabVIEW 2020, A Bug in the SHA256 VI
• OAuth2 and LabVIEW — A Bug in LabVIEW’s SSL Certificate Handling
• OAuth2 and LabVIEW 2020, Changes to the LabVIEW Web Servers
• OAuth2 and LabVIEW — Replacing the Web Server