Skip to content

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 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 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”. 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 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”.

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.

A message from Fabiola De la Cueva

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 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 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, add code after Byte Array to convert the hex string back into a binary array.
  3. Make my own copy of Byte Array 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:

5 Comments Post a comment
  1. Aristos Queue #

    Are you needing your code to work on Windows, Mac, and Linux? The .NET solution is not multiplatform, but the new VI is. If multiplatform matters, then one of the second two solutions seems like the right idea.

    I have flagged this post for the developer of this new VI to consider. (Seems like at the very least we should add some Quick Drop nicknames to make it more findable.)

    June 8, 2020
  2. Rich Tollerton #

    Oh, crap, that’s my feature.

    Go back to that 2020 VI you opened up. You should just be able to copy the underlying “Apply Hash Function To Byte Array.vim” along with out to your code, in order to get a raw byte checksum. Will that do ya?

    The MD5 VI this is replacing spat out hex-encoded strings, and AFAIK the majority of hex encoding of hashes uses lowercase… So there ya go, I guess.

    Regarding Base64, uh, check out vi.lib/httpClient/, I guess. Really user-visible, yeah, I know. :F

    June 8, 2020

Trackbacks & Pingbacks

  1. OAuth2 and LabVIEW - Revisited for 2020, Part 2 - Stravaro, LLC
  2. OAuth2 and LabVIEW - The Evolution of an Example - Stravaro, LLC
  3. OAuth2 and LabVIEW - Part Two, The Authentication Process - Stravaro, LLC

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.