Posts tagged ‘authentication’

OAuth2 and LabVIEW — Part Three, Improving the Example

This is part three of a three four nine part blog post where I describe how to use OAuth2 with LabVIEW. See also:

• 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

In part one, we created a web service that the authentication process is going to use to call us back with an authentication code. In part two, we wrote code to go through the authentication process and call an example Google web service. Here in part three, we’re going to start writing some tests, replace the JSON parser, and think about what we else we could do to improve the example.

Improvements for Testing

I’m usually not a Test-Driven Development (TDD) kind of guy.  That’s where you write unit tests first, show that they fail, and then write the code that passes the tests.  I’ll sometimes use TDD when I clearly know what the right answer for a function ought to be.  For example, I once used TDD for figuring out a SQL query to a database—I could look at the database and deduce what I wanted the query to return, so I wrote a test for that.  Then I iterated until I got a SQL query that returned the right answer, and then iterated until it was efficient.

In our OAuth2 case, I decided from the start not to use TDD.  I wasn’t as confident that I knew the “right answer” to each step.  But I still kept testability in mind as I went along, and I wasn’t afraid to go back and write tests (and refactor for testability) after the first pass of the app was “done”.

It’s worth talking about the structure of the C# example that I started from.  It was badly structured for testability.  Here’s a high-level pseudo-code overview of this structure:

OAuth2 and LabVIEW — Part Two, The Authentication Process

This is part two of a three four nine part blog post where I describe how to use OAuth2 with LabVIEW. See also:

• 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

In part one, we created a web service that the authentication process uses to call us back with an authentication code. Here in part two, we’ll write code to actually go through the authentication process and call an example Google web service.

Calling the Authentication Server

Okay, with the callback ready, we can now call the authentication server and request a code.  Fortunately, Google has conveniently set up example servers and client codes to make testing with their endpoints easy.  That’s what we’ll use for this example.

We will call https://accounts.google.com/o/OAuth2/v2/auth as our authorization endpoint.  It takes several parameters that are part of the OAuth2 standard which we’ll pass with the URL:

• response_type=”code”
• scope=”openid profile”
• redirect_uri=<our redirect endpoint>
• client_id=<client id registered in advance>
• state=<state>
• code_challenge=<code challenge that’s part of the PKCE extension hashed with SHA256>
• code_challenge_method=”S256″

The “redirect_uri” is what we created in part one of this blog post. The “client_id” for our example belongs to an “AppAuth Example” which Google created for testing. The “state” is a random string used to discriminate between calls. “code_challenge” and “code_challenge_method” are part of the PKCE extension.

We’re also going to need some helper VIs…

OAuth2 and LabVIEW — The Evolution of an Example

This is part one of a three four nine part blog post where I describe how to use OAuth2 (and PKCE) with LabVIEW. OAuth2 is used to authenticate with web services such as Google, Twitter, Facebook, and almost every major cloud-based service today.

See also:

• 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

Introduction

I own a slightly faulty beverage refrigerator. What makes it slightly faulty is that it sometimes wants to be a beverage freezer—it starts cooling, and doesn’t stop. It only does this rarely, and is otherwise a nice enough refrigerator that fits conveniently in a spot in our laundry room, so I’m hesitant to replace it. Instead, being the engineer I am, I decided to address the issue with more technology!

I purchased a Wireless Sensor Tag and a Wemo Mini Smart Plug to solve the problem.  The Wemo Wifi plug controls power to the refrigerator.  The Wireless Tag monitors temperature and humidity in the fridge. I use an IFTTT recipe to turn on the power when the temperature is too high, and turn off the power when the temperature is too low.  I ask it to keep the temperature within a four Fahrenheit degree temperature range.  On average, it is on for one hour, off for four hours, and then repeats.

It works surprisingly well. I set the Wireless Tag to send its data to the cloud every five minutes. I can view temperature and humidity graphs over the last several months and know it’s working. IFTTT is imperfect as a control system, but has worked out more reliably than expected. It’s only missed the too-high/too-low alarm twice in the few months since I’ve had this setup, and I work around this by having the alarm continue to trigger every fifteen minutes until the temperature is back in range.

All in, I’ve spent about $90 to avoid buying a new, inexpensive refrigerator—but it was way more fun to do it this way!

I can’t help but wonder about using LabVIEW to replace IFTTT as the controller, or to use LabVIEW to analyze my months of temperature and humidity data—and that’s where this journey begins…