LabVIEW
Pure LabVIEW JSON Web Token (JWT) Library (Use on VxWorks, Linux, Windows, etc)
It's not quite finished yet (I think I have like 5 documentation labels across all of the libraries and zero VI documentation) but I have implemented a pure LabVIEW JWT library that provides the currently required 'none' and 'HS256' (HMAC SHA-256) signature algorithms. All of the cryptographic, base64, and JSON functions are all pure LabVIEW contained in separate PPLs and then the JWT ppl utilizes these to provide verification of HS256 signed JWTs as well as generate unsigned and HS256 signed JWTs.
I'm currently working on a dev environment/process to [relatively] easily manage ppl build artifacts for multiple targets (VxWorks, Linux-RT, Windows) utilizing a single source root folder and need to clean that up a bit. Once I get the development environment cleaned up and document the build output organization I'll be pushing everything into a github repo for public critique consumption. I'm also working on all of this in 2018f1 so I need to down-save everything to an older version which will be a bit of a hassle with this architecture. I'll update this post with a link once it's available. In the mean-time to whet your appetites here are some screenshots showing the final test VI for working with JWTs:
All of the abstraction is in place to implement the other signature algorithms without needing massive changes to the existing libraries; I just need a bit of a break before I try to dip my toes into implementing asymmetric key encryption in LabVIEW. (perhaps someone can donate some effort once I make this available?) As evident from the screenshot, the standard payload claims are also handled separately from the rest of the JSON payload to more easily handle all the conversion for you. Anything left at default values doesn't get added to the encoded and signed payload.
This was partly an educational exercise for moi, and mainly because the only current solutions I've seen involve using windows DLLs or .NET components which won't work for all of my targets.
In the mean-time, if this looks like something you're interested in, let me know what version of LabVIEW you're on and I'll try to get an environment set up to rebuild everything with! If you have any tips on managing multiple LV versions in a git repo I'd be interested in that as well! (I'm thinking master branch is always latest version with branches for merging updates into for older versions of LV)
Cheers,
Derrick B
Just one version on GitHub would work for me 
.
I'd publish in a version of your convenience. Then on requires (here on the forum), you could convert and post versions on demand.
You'd get yourself into a lot of work maintaining multiple version. If you want to support multiple versions, simply publish in the earliest version you want to support. As long as you provide the diagrams (GitHub is for open source code, IIRC), it will work in newer versions.
Search LabVIEW like a graph! So in other work efforts I've begun work on a serialization framework and have utilized the JWT library I wrote to extend the serialization library to be able to generate JWTs from any labview class that implements the Serializable overrides. One of these days I'll get enough time to finish cleaning up these libraries I've been working on and get them posted to github like I promised... One day. As I'm typing this I think I finally figured out how to organize my dev environment and repos as these are all part of my multi-target build setup, so perhaps sooner rather than later!
@DerrickB wrote:
One of these days I'll get enough time to finish cleaning up these libraries I've been working on and get them posted to github like I promised... One day.
Yes, finishing is a pain. Last 10% can take 90% of the time. And that last 10% is much less fun then the first 90% of the work 
...
Take my advice: never do a presentation about your code!
You will find you did things you can't explain or justify, then change the code, change the presentation, and somehow you'll end up in an endless loop. I keep falling for that...
Besides, why would I finish cleaning up existing features when I could be adding new likes like refactoring half the framework to support serialization/deserialization with streams?? Now with StringStream and FileStream classes to support all of my current use cases. Would it go too far if I based an entire WebSockets / TCP streaming connection off of this now? 
