Category: Development

Microsoft Authentication Library (MSAL) – accessToken Invalid signature

I recently had to integrate a node js application with Microsoft 365 for authentication purposes. The obvious way to do this was using the MSAL node js library.

It’s somewhat tedious to use and introduces its own way of doing things, with numerous seemingly arbitrary hoops to jump through, but eventually it seemed to be working.

I became aware that sometimes users were getting logged out and struggling to log back in. After some digging, I noticed that after an unsuccessful token validation (due to expiry), calling aquireTokenSilent was returning the same token from the cache. After some further digging, I realised I was incorrectly validating the idToken instead of the accessToken.

It’s frustrating that there are no controls in place to prevent the tokens being used interchangeably. It’s frustrating that multiple tokens are exposed when I only need one of them.

It’s frustrating that Microsoft choose to do their own thing instead of either a) encapsulating the whole process or b) providing a workflow that stays true to OAuth 2.0 (e.g exposing the refresh token flow).

Switching to the accessToken led to the most annoying problem: the token verification failed due to having an invalid signature. This one had me baffled for a while until some searching on Stack Overflow led me to realise that I’m not the only mug to fall for this.

Despite being a Microsoft token, and despite verifying the signature with Microsoft keys, it fails, because, if you do not need to pass any scopes as part of your request, you still need to pass a default scope:

YOUR_CLIENT_ID/.default

So, if your client id is 1111-aaaa, then your scopes would be:

scopes = ['1111-aaaa/.default']

Once this was added, the access token signature could be verified and the problems disappeared.

Again, it’s frustrating that the error had nothing to do with the problem. It’s frustrating that the documentation is not helpful, but in my limited experience this is true of any point where Microsoft technology interfaces with non-Microsoft technology.

Learning Scala – part 2

I’ve been asked to contribute to a Scala project and I’m documenting my journey learning Scala and making that contribution. This is part two.

Here is part 1.

Test driven learning

Having started with the new company, I’ve learnt that they are using Scala with the Play Framework (link). The application already has a degree of maturity, so I’ve been thinking about how to get to the point where I can contribute effectively.

My starting point is to understand the things I feel I need to learn. These are:

Additionally, I need to understand how the team works, but that is not really the subject of these posts.

I’ve spent the last four years trying to drive more of my code via tests. I have had good success in breaking down technical problems and in learning new thing by driving my progress through tests. Because of this, my focus in learning Scala, the Play Framework and the project is to understand the existing tests and to then write new tests. Driving learning via tests feels a bit like hacking the system.

Thankfully, the project already has decent test coverage, which gives me good starting point to understand the project.

  • ✅ By running the tests I can get an overview of what the project does (tests print out indications of expected behaviour for different scenarios).
  • ✅ I can run tests individually and then look closer at the code to see how individually pieces of code work whilst already knowing what they are supposed to do.
  • ✅ The tests generally run fast, which means I can understand more complex flows faster than driving the code manually (e.g. via a browser).
  • ✅ Tests should fake dependencies (databases, 3rd party systems, etc) which means you can focus on learning one application and how it interacts with others, without being distracted by the other systems. 
  • ✅ I can make changes to tests, see them fail and then revert the code – this helps me play with the code, see how it breaks, be able to understand the effects, and then safely revert it.
  • ✅ A byproduct of running the tests is that I will likely pick up much of how the test framework works, which means I have a head start when I come to writing my own tests.

Documenting the application

Any reasonably sophisticated project will have a number of components and flows. I find it helps me to understand that better by documenting this as a diagram.

I can’t share the document that I created for the project as it is a private project, but I can give you an idea of what I do.

Essentially, I systematically work my way through the application, in this case starting with the controllers. I represent each class or module that is connected (the custom classes / modules only – I ignore 3rd party libs). I use Omnigraffle, but something like Draw.io would probably work as well. Imaginatively, each class / module is a box and these are connected with arrows. I try to get all information on to one map first and then I will work out how to best represent the information so as not to overload the reader. I create a key and will sometimes use size to indicate connectivity (bigger boxes, more connectivity). I also use colour if I can see a clear categorisation of elements and will use different line styles to represent 1 way or 2 way connections. If there are too many lines, I make connections that seem less important lighter so that they do not distract.

Once the diagram is complete, I’ll share it with team members for two reasons. One, in case it helps them and two, to get feedback.
The beauty of this type of process is that you quickly get a sense of the really important, central parts of the project. There are usually a few classes / modules that are connected to everything else. It lets you understand what you need to focus on and what you can ignore.

IntelliJ and sbt

I was compiling my code using sbt, whilst using IntelliJ as my editor. I had noticed that I was finding the code hard to follow and eventually realised that the syntax highlighting wasn’t especially effective and when I highlighted an external class or reference, IntelliJ wasn’t giving me links to those files.

In VS Code, I know this as ‘Intellisense’, so I tried Googling this and eventually found this: https://stackoverflow.com/a/47039808/1186928. Sure enough, I had the project open one level too high. Opening the project with build.sbt in the project root resolved my issues. Syntax highlighting now makes code easier to read and I can easily get information on external files and references.

Beginning Scala

I thought it might be interesting to document my journey from complete Scala beginner to contributing to a real Scala project (hopefully).

I will split this journey over a number of posts and hopefully it will end up in a good place.

(more…)

Running CPU heavy tasks on Node.js

image of code to enhance page design

TL;DR You can offload CPU intensive code using Node’s worker threads module. A demo app of the effect of this can be found here.

I thought I understood Node’s async mode. I’ve used callbacks, I’ve used promises and I’ve used async/await. I’ve dealt with unhandled promise rejections and I’ve worked out how to use try and catch with async tasks.

I thought I’d mastered the async model before and been rudely awakened by some unexpected behaviour. It has been a long time since one of those rude awakenings and by now I thought I really had mastered async.

(more…)

Debugging Vue Mocha unit tests in VSCode

View of Vscode debug pane

I have been struggling to be able to debug Vue Mocha unit tests in VSCode, but I think I might have the answer.

Running a Vue application is easy enough and debugging the running application in Chrome or VSCode is relatively straightforward.

Creating and running unit tests for Vue is also relatively straightforward, thanks to the excellent Vue Test Utils.

However, when you want to debug those unit tests, things seem to get a little trickier.

(more…)

Navigation in iTerm2 on Mac

iTerm2 preferences

Using iTerm2 for development is awesome. You can use CTRL + a to move to the start of the current line and CTRL + e to move to the end.

With long commands, it would be convenient to just jump back a few words, edit the command and then execute it. Whilst this is possible by default in iTerms2, the keys are cumbersome.

(more…)

CSS Grid and grid areas

CSS Grid example

Having played around with CSS Grid for a while, I had been very impressed with it. But having watched this excellent video on the use of grid areas, I realise that I have been holding the hammer by the head.

Despite reading about grid areas, it hadn’t sunk in just how easily they can be used to solve basic layout requirements – especially when handling responsive layouts.

(more…)

The Holy Grail: Cypress.io, Browsersync automatically rerun tests

Cypress is an amazing front-end JavaScript test runner and framework. It simultaneously simplifies the set-up and test creation whilst providing a more useful features than most alternatives.

(more…)

How to lazy load custom field images in wordpress

Lazy load text

WP Rocket is a great, paid-for module for improving the performance of WordPress. Their Lazy Load module improves perfomance further by online preloading images above the page fold.

(more…)

BDD with Visual Studio – part 2: First scenario and first test

In this second part of this series, we look at creating a first scenario and step definitions.