DEV Community: Klee Thomas

Your stand-up is bad, and you should feel bad.

Klee Thomas — Sat, 05 Oct 2024 01:50:03 +0000

TLDR:

Stop getting status updates from the people in your standup, and start focusing your team on the highest priority so they can deliver value.

Your standup sucks!

… and you know it.

You know your standup sucks because Every day, the team gets together, you go around the room, and the people on your team say yesterday, “I worked on JIRA-123, today I’m going to continue with it, no blockers”. Every now and then, someone bucks the mould and says, “I finished a JIRA-456; I’ll pick up something new today”.

You know your standup sucks because whenever “management is away”, the team will skip the standup or move it to be an async update on Slack.

You know your standup sucks because it blows out from 15 minutes to an hour-long debate.

You know your standup sucks because no one really cares what everyone else is doing.

Standup is important!

The easy next step when you realise that your standup sucks is to cancel it. Don’t do that; standup is essential. You’re just doing it wrong. The good news is that it’s easy to fix. It’s just a matter of moving the focus from the individual to the work and the team.

Standup should not be a status update. If you need a status update, get it from the Jira/Trello/Notion/whiteboard; it will tell you where all the tasks are up to and how your velocity is tracking.

What should you do to fix it?

Standup should be a chance for the team to focus on the next highest priority. Rather than asking people what they did, look at the board, identify the next highest priority, and ask, “What can we, as a team, do to move that task to done today?”

There is a key change in language here. Instead of addressing the individual using terms like “What did you do?” or “What do you need?” the language has changed to address the team: “What can we do?”. This small change reminds the team that they’re not a collection of individuals who code near each other. They’re a team, and teams work together to solve problems.

The impact of this change won’t be immediate, but as you keep using this new question and encouraging the team to work as a team to complete the highest priority items on the board, they will start to default to working as a team. This will mean that they’re more engaged at standup because the team is always talking about the topics relevant to delivering work for that day, not just listening to a status update.

Eventually, you’ll find that working as a team leads to less work being bottled up in your board's “review” column, higher throughput for your team, and lower cycle times.

This approach might raise a few questions for you,

“Does this mean that the team can only have one task in progress at once?” The answer to that is no. You can still have multiple tasks in parallel, but the team needs to assess, every day, what they need to do as a team to get the highest priority item done. Sometimes, that means everyone is working together on a single task. Sometimes, it’s going to mean giving someone space to solve the problem or the team moving on to something else while a blocker is escalated.

Aside: The extreme version of this is Mob/Ensemble Programming, which I’ll argue is the most efficient way to deliver value. I wrote about My Experiences Mob Programming here

“I have too many priorities; how do I know the highest?” Within a sprint, the rule of thumb should be highest priority item is the one that has been on the board the longest. You’ve spent effort on this task and realised no value. Lean tells us that “work in progress is waste”. The longer you’ve let a task sit incomplete, the more it’s costing you.

Bruno: First thoughts

Klee Thomas — Sun, 24 Dec 2023 06:56:34 +0000

Bruno is an open-source, free API testing client. This post contains my initial thoughts from the first time giving it a quick test run to try out the features.

I've been a long-time user of Postman, and as they continue to push the monetisation of their product, I've been interested in an alternative. When the ChangeLog mentioned Bruno, I was excited to try it out.

TLDR: I like it, and I'm keen to go deeper on what it can offer.

Project health

The project looks to be healthy, the website lists 2 core contributors with over 100 contributors overall.
Github shows the last commit to the main branch was yesterday (at the time of writing this).

That reinforces my thoughts that this project is not going anywhere and is something that is worth looking into.

Setup

The website usebruno.com is simple and modern and gives off vibes of a project that is more than just a side thought.

Downloading and installing on my Mac was straightforward. The website also lists how to set it up using Home Brew which I thought was a nice touch.

The GUI

The GUI is pretty standard for API clients, which makes the learning curve low for me.

I was quickly able to create a collection and add requests to it without having to consult the documentation. Tests are grouped into collections in the left-hand pane. Colours are used to denote different types of requests.

Ease of use fell down when I wanted to add some assertions to verify that the response I was getting was what I expected. The good news is that a quick trip to the documentation site docs.usebruno.com was able to help me out, using by editing the file, which I could then see in the UI.

The File

This is where Bruno claims its main strength. Rather than being saved away in a proprietary file, somewhere requests are saved in a plain text, human-readable file ❤️❤️❤️❤️❤️.
This is fantastic. For developers like me, editing text files feels like home. Changes made to the file are picked up by the GUI instantly so I was able to seamlessly switch from editing the file to editing the request in the GUI.

The fact that I can store these in my git repository alongside my API has me ecstatic. I used to do this with Postman collections; the issue there was that the whole collection was stored in a single file, making it nigh on impossible to track changes, hand edit the file, and any changes made by another team member meant that I had to be announced so people could reload the collection *.

The CLI

Something that excites me about the idea of having requests saved in a file alongside the application is that I can use these requests as living documentation when changes are made. As part of Continuous Integration, the API can be spun up, and the collection of requests can be executed against the API. This ensures that the collection is still documenting valid requests.

Trying out the CLI, I ran into a couple of problems. The documentation asks me to use NPM to install it globally. Because I want to run this in CI, I'd prefer not to do that as I'd like to have the version of the CLI documented in the package.json. I installed it as a dev dependency and used Yarn to run it from the local node_modules folder. This gave me a working version of the CLI.



"scripts: {
    "bruno": "bru"
}

Running my yarn script and pointing at a file in my collection directory gave me an error: You can run only at the root of a collection. This was a bit disappointing, but adding cd ./sample-requests/ to the start of the command fixed it.

Final thoughts

For now that's as far as I've gone with Bruno. I know I've just touched the surface of what Bruno has to offer. Already, it's left me excited! I am already planning to make it my default API client.

I'm excited to go further with the testing and scripting parts of the request life cycle and see how to integrate it with CI systems.

PS

I love that they have this good boi as the mascot and chief joy officer.

This makes sense, as sharing and change tracking were part of the Postman paid offering.

OAuth 2 Overview

Klee Thomas — Sat, 11 Mar 2023 08:53:05 +0000

OAuth 2 has become the de-facto standard by which authentication and authorisation are done on the internet. An entire industry has spun around it with players like Auth0 offering SAAS solutions, every major company with a user base offering login with Google/Facebook/Twitter/etc., and companies offering to build you a better experience if you give them access to your data on these platforms.

Like with many ubiquitous things, OAuth 2 has become a building block we put in an opaque box and don’t think much about. In this post, I want to dig into some of the terms associated with OAuth 2 and shine some light on that box.

Origins of OAuth

The first thing to understand is the problem that OAuth was created to solve. Before OAuth, when a user wanted Service A to interact with Service B on their behalf, they'd need to give the username and password that they used to access Service B to Service A. They'd be trusting Service A to act as them, with the full power to do anything that the user themselves could do. In concrete terms, you'd provide your G-Mail credentials to Facebook and trust that they'd only use it to invite your friends to connect with you. Trust that Facebook wouldn't read all your data.

OAuth was invented to provide a way for a user to provide a subset of their authorisation without giving up complete control. Now you could give Facebook access to your G-Mail contacts and not any of your email contents, a win for the users.

Components of OAuth

Resource Owner

The party sharing its authorisation to access, modify or invoke an API on the Resource Server. This will often be a user but could also be a server in the case of machine-to-machine communications.

Resource Server

The party hosting the API that controls access to the data or functionality being requested. This is the party that will evaluate the granted credentials.

Client

The party that is requesting credentials.

Authorisation server

The party that is issuing the credentials. This could be the resource server, but most often is a separate system.

In the example above with G-Mail and Facebook. You, the user are the Resource Owner, G-Mail is the Resource Server, Facebook is the Client, and Google Authentication is the Authorization Server.

Tokens

The way that authorisation is represented in OAuth 2 is as a JWT, JSON Web Token. The high-level overview of these tokens is that they comprise three sections separated by a .. The first two sections (the head and body) are base 64 encoded JSON objects. The third (the signature) is a base 64 encoded signature generated from the first two sections.

The head contains information about how the token is signed and where to find the key that can be used to prove the Authorization Server issued it.

The body contains all the information transmitted in the token. There are some guidelines about what should be included in the body, but it is largely free form.

The signature is an encrypted hash of the body and the head. Signing the token means that any party presented with the token is confident that the Authorization Server issued it.

Flows

The Authorization Server and Client communicate securely by following one of the Flows outlined in the OAuth 2 specification. These Flows establish the protocol of redirects and API calls that establish trust between the parties.
Each of these flows deserves its own post. In short, there are 6 (and a half) Flows:

Authorization Code; Used when exchanging authorisation and authentication information on behalf of a user. ** Authorization Code with PKCE; Used when exchanging authorisation and authentication information when the client cannot store secrets securely. e.g. Web and Mobile clients.
Client Credentials; Used in machine-to-machine authentication. Authorising between two servers that can communicate secrets securely.
Device Code; Used when authenticating users when the user is using an input-constrained device such as a smart television.
Refresh Token; Used when exchanging a refresh token for a new access token.
Implicit Flow. Do not use. Previously used for authenticating users, it has been deprecated due to security issues.
Password Grant; Do not use. Previously used for authenticating users, it has been deprecated because it required the client to have the user enter the user's username and password.

Open ID Connect

Lastly, I want to mention Open ID Connect, commonly known by its abbreviation OIDC. OIDC is an extension to OAuth 2 that allows for the exchange of user authentication information between the Authorization Server and Client in addition to authorisation. OIDC enables OAuth to go from the use case of "Sharing your G-Mail contacts with Facebook" to "Login with Facebook".

This post has only briefly touched on a range of things in the OAuth 2 space. There is a lot of room to go deeper into each of the Flows, tokens and, of course, OIDC.

Svelte + Auth0 step by step

Klee Thomas — Sat, 07 Jan 2023 23:50:54 +0000

In this post, I run through, step by step, how I went about getting authentication into a Svelte application using Auth0. If you just want to see the full sample code for this can be found on GitHub.

Svelte is an amazing tool to use when creating interactive web apps. Pretty much any interactive web app needs to have Authentication baked in. Authentication is one of those things that you shouldn't be building for yourself. Auth0 provides a low-effort way to authenticate your users.

Get set up

Create an Auth0 account

For this post, I'm going to assume that you've already got an account on Auth0. If you don't it's as easy as heading to Auth0 and signing up for a free account.

Start a Svelte app

You could build out a Svelte app from the ground up, picking your bundler and application structure, or you can use a pre-built scaffold. For this post, I'll use a scaffold to keep things short.

Run npm create vite@latest svelte-auth --templte svelte-ts

Navigate into the cloned directory and install the dependencies by running npm install.

Start the application locally by running npm run dev this will start a server on port 5173. You can open the app by going to http://localhost:5173/.

Now that you've got a sample Svelte app running let's look at how we can add Authentication using Auth0.

Adding Authentication

Configure Auth0

Log into the Auth0 console. If you've just signed up or created a new tenant there will be an app called Default App that you can use, or you can create a new application.

Into this application, you're going to need to set the Allowed Callback URLs to http://localhost:5173/ and the Allowed Logout URLs to http://localhost:5173/. Note that the URL ends in /. Then scroll to the bottom and save the changes.

To configure the library you're going to need some values from Auth0. From the console take note of the Domain and Client ID values.

Add log in

Auth0 provides a library to make it easier to add Authentication to JavaScript applications. Add the library using npm install @auth0/auth0-spa-js.

Create a new file to be responsible for Authentication called auth.ts. To start with export a function called withAuth that returns an object with a login method.

Start by implementing the login function.
Create an Auth0 client using the values that you copied out of the Auth0 console.
You'll also need to tell the client where to redirect the user back to after login. Given that this is a single-page app we'll direct them back to window.location.origin.

Then use the client to redirect the user to Auth0 to log in.



async function login() {
  const client = await createAuth0Client({
    domain: "<your domain>", // e.g. "klee-test.au.auth0.com"
    clientId: "<your client id>", // e.g. "GGOFsf1eiSGvYOBkeDHAAJopE5qRpzN7"
    authorizationParams: {
      redirect_uri: window.location.href,
    },
  });
  client.loginWithRedirect();
}

export function withAuth(): {
  login: () => Promise<void>;
} {
 return { login }
}

To test this out wire it into the view in App.svelte



<script lang="ts">
  import { withAuth } from './auth';

  const auth = withAuth();
</script>
<main>
  <button on:click={auth.login}>Login</button>
</main>

Now when someone clicks on the button they'll be redirected to Auth0 and asked to log in. When they have they'll be redirected back to your app.

Add log out

Let's follow that up by adding logout functionality.
Go back to the auth.ts file and add a logout method. You'll need an Auth0 client with the same configuration you used for login and need to call the logout method.



async function login() { ... }

async function logout() {
  const client = await createAuth0Client({
    domain: "<your domain>", // e.g. "klee-test.au.auth0.com"
    clientId: "<your client id>", // e.g. "GGOFsf1eiSGvYOBkeDHAAJopE5qRpzN7"
    authorizationParams: {
      redirect_uri: window.location.href,
    },
  });
  client.logout();
}

export function withAuth(): {
  login: () => Promise<void>;
  logout: () => Promise<void>;
} {
 return { login, logout }
}

Wire this into the App.svelte file.



<script lang="ts">
  import { withAuth } from './auth';

  const auth = withAuth();
</script>
<main>
  <button on:click={auth.login}>Login</button>
  <button on:click={auth.logout}>Logout</button>
</main>

Now when the user clicks on Logout they'll be taken back to Auth0, their session will be cleared and they'll be redirected back to your app.

This is great, the user can log in and log out but... really we need to be able to show a different experience for logged-in users compared to the experience for logged-out users.

Get user details

Let's go ahead and add a welcome message for logged-in users and display their profile picture. We can also hide the login button for logged-in users and hide the logout button for logged-out users.

To share the user information with the rest of the app let's have auth.ts expose a Svelte store that provides the user details. This will allow App.svelte to respond to app.ts getting authentication asynchronously and render the logged-in UI when it's ready.

In auth.ts create a store called user by importing writable from svelte and calling it at the top level of the file.



import { writable, type Writable } from "svelte/store";

let user: Writable<User> = writable();

Then add a new function getUser(). In this function start by setting up an Auth0 client using the same config as login and logout.

In this function call getTokenSilently. This is a bit unintuitive. Without this call, the Auth0 client will not have a token it can use to call the Auth0 authentication server to get the user information.

After the client has a token call the client again to get the user's information from the authentication server. Once you've got the user's details call the set method on the user store to publish the new information.

Wrap all the calls here in a try-catch block. This is because the getTokenSilently call will throw if the user is not authenticated. Adding this catch here is important because you need to call your getUser function as part of the withAuth function. This ensures that the user will automatically see the authentication information.

You should now have added some code that looks like this to your auth.ts file.



  async function getUser(): Promise<void> {
    const client = createAuth0Client({
      domain: "klee-test.au.auth0.com",
      clientId: "GGOFsf1eiSGvYOBkeDHAAJopE5qRpzN7",
      authorizationParams: {
        redirect_uri: window.location.href,
      },
    });

    try {
      // ensure the client has a token to cal the Auth0 Authentication server.
      await client.getTokenSilently();
      // get the client to fetch the user information.
      const userDetails = await client.getUser();
      // publish the user information
      user.set(userDetails);
    } catch (e) {
      // if the user is not logged in the getTokenSilently call will fail. 
      console.warn(e);
    }
  }

  getUser();

You'll also need to remember to return the user store from withAuth so that App.svelte can subscribe to changes.



  return {
    login,
    logout,
    user,
  };

Now to update the user interface and display some information from the user returned from Auth0.

In the <script> tag in the App.svelte file you need to subscribe to changes made to the user. To do this, create a variable to hold the user object and call the subscribe method on the user object returned from withAuth. subscribe takes a callback with the updated value for the user's auth.



<script lang="ts">
  import type { User } from '@auth0/auth0-spa-js';
  import { withAuth } from './auth';

  const auth = withAuth();

  // a variable to hold the authentication details
  let user: User;
  // update the local store of auth details when they change
  auth.user.subscribe((auth) =>{
    user = auth;
  } )
</script>

Finally to get the display to update add an {#if} block to the tsx code to switch between showing the log in button or showing log out button and user profile information.



    {#if !user}
    <button on:click={auth.login}>Login</button>
    {:else}
    <button on:click={auth.logout}>Logout</button>
    <h1>Hello {user.nickname}</h1>
    <div class="profile">
      <img class="profile" src={user.picture} alt="User profile">
    </div>
    <p>User:</p>
    <pre>
      {JSON.stringify(user, null, 2)}
    </pre>
    {/if}

With this, you've got an app that you can run to log a user in and see some profile information.

Getting an access token

The other thing you may want to do is get an access token to call an API.

For this, you'll need to go back over to the Auth0 console and add an API. You can find the APIs section under the Applications menu. Add a new API give it a name and pick an identifier. Take note of the identifier, you'll need to add it to your code.

Back in your code add the API's identifier to the code as part of the authorizationParams object when creating the client.

Now when you call client.getTokenSilently() it will return a valid JWT access token. Add a new store for the token, set it's value once the getTokenSiliently call has completed and return the store as part of the withAuth response so the rest of your application can make use of it when calling APIs.



const accessToken = await client.getTokenSilently();
token.set(accessToken);

The full sample code for this can be found on GitHub

CloudFlare Workers - some functionality can only be performed while handling a request

Klee Thomas — Sat, 22 Oct 2022 08:51:34 +0000

Have you encountered this error when trying to upload a CloudFlare Pages function?

Error: Failed to publish your Function. Got error: Uncaught Error: Some functionality, such as asynchronous I/O, timeouts, and generating random values, can only be performed while handling a request.

I ran into it recently when tying to deploy what I thought should be a relatively simple function.

Directions to tell me that the issue was at worker.mjs:11:28 didn't really help me with where to find the issue in my TypeScript code.

Through a process of trial and elimination I ended up finding that it was down to how I was creating Response objects for my error cases.

const errorResponse =  new Response("Error message", {
    status: 400,
  });

I had this at the top level of a module I was importing.

Turns out this is not allowed. Instead I just need to create the responses during the execution of the function by turning the assignment statements in to anonymous factory functions.

const errorResponse = () => new Response("Error message", {
    status: 400,
  });

This keeps the code looking the way I want and CloudFlare is happy to deploy it to a worker.

In retrospect the error message makes sense, but without the context of having solved it I had a really hard time.

My experiences mob programming

Klee Thomas — Fri, 23 Sep 2022 05:38:27 +0000

What is mob programming?

Mob programming is a radically different way to approach building software as a team. Rather than focusing on each developer maintaining their own parallel work stream. It brings a group of people together to focus on delivering a single task.

At its core this may sound like wasted effort. If there are 4 people in the team they could potentially have 4 pieces of work being actively developed, surely that would be faster. The short answer is no, which makes the obvious next question “why?”

It’s because rather than focusing on work in progress we’re minimising queuing time. In a typical development process there are several points where the developer is waiting in someone else’s queue. Do you need help from someone? Do you need a code review before you can complete your task? if you do then you’re in the queue. What do you do while you’re in the queue? You pick up something else. This is either context switching to a new task or proceeding with the current task making an assumption that when you get to the top of your colleagues queue you wont need to make changes.

Let’s play out the code review:

You finish some work, create a PR and assign it to your colleague C.
C is busy so it goes into C’s queue
You start something new.
C finishes their work and picks up your review. They see some changes they’d like made and let you know it’s done
You finish the other task, assign a second review to C
You address the work on the first review assign it back to C
… so on

It’s this sort of queue build up, constant context switching and waiting, that mob programming seeks to address. Mob programming is all about making sure you have the right people in the room to eliminate queue time. A mob is able to take a task from kickoff all they way through to merging in one steady line. The kickoff is done as soon as the team is ready because everyone who needs to be there is already in the mob. There is no waiting for code review, the team has been actively working together and effectively reviewing the code as they go along. When the task is complete they are able to merge the code and move onto the next task. We have minimised context switching and all but eliminated queue time.

How does it work

The guides for mob programming set out two roles.

The Driver: Plays the role of the Human Machine Interface. Their role is to be the typist. The difficult part of this role is that the driver is not allowed to add their own understanding into the picture. They are just doing what they’re told to do by the navigators.
The Navigators: The navigators are everyone else in the mob. The navigators are busily researching and understanding the problem so that they can direct the driver to the best solution. The difficult part of being a navigator is that in order to get your idea to happen you have to be able to explain it to the driver. The navigator will be tempted to take control and just type in what they want to see. That must be avoided. This ensures that there is at least two people who have some understanding of any changes that are being made.

In order to ensure that everyone is involved the driver role is rotated through the team quickly. Historically when teams were co-located the driver role was rotated every 3-5 minutes. In remote teams the change over tends to be more costly so 10 to 20 minutes is a more common cadence for remote mobs.

Inevitably the navigators will come up with multiple ideas that are not able to be worked on simultaneously there are two strategies that come into play to address this.

Most junior idea wins. When there are multiple competing ideas the mob should follow the idea expressed by the most junior team member first. This maximises the learning and helps to grow the junior members.
Follow an intent through to completion. When a team member has expressed an intent (aka that they would like to try a solution) the team then takes that on and follows it through to completion. Stopping half way through because someone (almost certainly a senior) can see an issue robs the rest of the team of the learning gained from following it through.

These two strategies help the team to practice active experimentation and adopt a built measure learn mindset rather than getting stuck in analysis paralysis as people argue for their optimal solution while nothing gets done.

How we’re doing it

All of that is how the guides suggest that you do mob programming. Now I want to talk about how Media Experience has been practicing it.

We have split the team into two concurrent steams of 4 or 5 people the green stream and the yellow stream. Members are allocated randomly to each stream at the start of the sprint. A decision is made after the allocation about where any work being carried over from the pervious sprint should go.

These initial allocations are a suggestion and a starting point so we can ensure that everyone has a chance to work with everyone else on the team. That said mob programming is all about having the right people in the room, so if someone is needed or passionate about the work being done in the other stream they’re free to move between streams.

Each stream has two dedicated blocks mob blocks per day. 2 hours in the morning and 2 hours in the afternoon. These meetings are set up in the shared calendar so everyone in the team is able to access them quickly and easily. If someone is not able to make the meeting the mob is able to continue without them.

During these sessions we have adopted the driver and navigator roles as set out above. We’re rotating the driver role typically every 15-20 minutes. We track the time using the timer app in Zoom. The driver uses their development environment and shares their screen. At the end of their session the driver commits their code to the repository and the next driver pulls it down.

We tried using VS Code live share to share the control and make the change overs faster. We found that this made it easy for a non driver to “just show you what I mean” and circumvent the mobbing process. Regularly committing the code helps to ensure that the mob is able to progress independent of any member. We have experimented with mob cli (link) to expiate the handovers but have found that the complexity introduced by the tool didn’t improve the handover process.

How’s it going?

We’ve been at this for a couple of months now so it’s reasonable to ask how’s it going? What have we learned? My view of how the team is going is that overall it’s good.

What’s working?

I feel more connected to the team. Being on a call while working on things gives us a chance to have the conversations about things that are not work. During the times where we’re getting started, the down time during and handover or build we have more of those side conversations that have been lost in the world of remote working.

Along with those “non work” conversations have found that I have seen more instances of serendipitous alignment where team mates have found that they can jam on an idea. This has played out in team mates working together on 20% time projects.

These small positive interactions are important for maintaining a good working relationship with your colleagues. Studies have found that high performing teams have a ratio of 5 positive interactions to each negative interaction. Given that we have plenty of needed negative feedback interactions (e.g. requests on PRs and pushback in sparring sessions) these small positive interactions during downtime in the mob become incredibly valuable.

I have also seen an increase in the quality of solutions built by the team. We have all experienced those times where we open a pull request and decide that asking for major re-work is not worth it. When mob programming these discussions happen when it’s easy to change direction. The team is able to build software that meets a higher quality bar because they are constantly refactoring as they go. The team can fulfil the idea that “if you cant explain your solution you probably don’t have the best one”. With mob programming you’re always explaining your solution, so the code is easier to understand and easy to understand code is less error prone.

I have been impressed to see that although we made a major change to our processes we did not see our sprint velocity dip. I think this is because we are seeing the can drop the amount of time any piece of work spends in a queue. This is the PR, and help needed queues mentioned above but also the individual has been taken away from the work queue. On any given day we all have too many things to do. We’re in meetings, prepping upcoming work and more and more we’re expected to interview… a lot. During all of these things our work sits idly in our queue while we’re working on something else. With mob programming one member missing does not stop the mob. With 4 to 5 people in each stream the work is able to continue a pace while a stream member is otherwise engaged.

What’s Challenging?

This continual progress leads into the fact that any process change isn’t without its challenges. Something I wasn’t ready for was the feeling of missing out when the work that I had been putting effort into progressed without me when I was drawn into other meetings. It’s great to see the tasks being finished off but it’s an odd feeling.

I’ve also found that not all voices are equal, as much as we try to follow the advice of taking the most junior ideas we can only follow these ideas when they’re put forward. It can be hard to put forward ideas when louder people are constantly thinking out loud. This phenomenon is particularly obvious as the size of the mob grows.

It is important to shape a mob well. Mob programming talks about ensuring that the needed expertise in in the room. I have found that 9 developer with similar skillsets do not appear to generate better results than 4 and vastly increase the chances that a small percentage of participants will dominate the discussion.

If there are multiple streams that are interconnected or require access to the same person/resource in this case the streams may need to converge. This leads to larger mobs and the problems mentioned previously.

Caveat

This overview of how mob programming is going within Media Experience is my view of the world. I know not everyone in the team has enjoyed the process as much as I have. I don’t feel that I am the right person to speak to their experiences.

Should your team try?

Closing off this post. Do I think your team should try mob programming. Yes. I think it’s a net benefit to the team. You need to be prepared to give it a good try, find where the rough edges are for your team and work to improve them.

If you do that I think your team will be more productive, build better code (DFTC) , feel more engaged, with the work and also with the rest of the a team (BWHB, PAAT).

Honestly I now think that mob programming is the best way to do remote software development.

Resources

Woody Zuil’s talks on Mob Programming

Remote mob programming

Remote Mob Programming

Praise to criticism ratio

What is AuthN & AuthZ?

Klee Thomas — Wed, 02 Feb 2022 08:36:02 +0000

If you've been around the identity space for any length of time you've probably heard the terms AuthN and AuthZ thrown around. If you're like me then you've probably felt silly for not knowing what these terms mean. In this post I'll briefly explain the two terms and what they mean.

AuthN

AuthN is a contraction of Authentication.

Authentication is verifying your user is who they say they are. More often than not this is logging in with a username and password (Hopefully with MFA) or OAuth using a provider like Google or Facebook.

Authentication as a concept is fairly general there are great solutions like Auth0 that can be dropped into your application to provide authentication.

AuthZ

AuthZ is a contraction of Authorization.

Authorization is verifying that your user is allowed to perform actions of view content based on who they are (validated in Authentication).

Authorization is more application specific than Authentication. Roles and permissions are often decided by the domain that you're operating in. Custom applications typically require custom Authorization but can work quite well with general purpose Authentication.

TLDR;

AuthZ and AuthN are just contractions of Authorization and Authentication. Authentication is general purpose and can be plugged into your application. Authorization is more complex and needs to take into account your application domain.

MFA with Auth0 Actions (updated code)

Klee Thomas — Sat, 22 Jan 2022 23:44:49 +0000

I was alerted recently that the code examples in the previous two posts is now outdated. In May of 2021 Auth0 moved Actions to General Availability and with that came some significant changes to the Actions API.

In this post I'll go over the code that is needed to get MFA and conditional MFA working in the GA version of Auth0 Actions.

Forcing enable MFA

The fist step is to ensure that everyone logging in has MFA enabled before they can proceed.

For this we'll need the base Action structure.

exports.onExecutePostLogin = async (event, api) => {
// do stuff
}

Inside the structure we'll need to check if the guardian enabled flag is set on the user's app_metadata.

  const enabledMfa = event.user.app_metadata.guardian;
  if (!enabledMfa) {
  // have the user enable mfa
  }

If the user does not have the guardian flag set tell Actions to direct them through the Guardian setup flow.

    api.multifactor.enable("guardian");

Set the guardian flag so the user isn't driven through MFA every time.

    api.user.setAppMetadata("guardian", true);

The final code for setting up MFA looks like this:

exports.onExecutePostLogin = async (event, api) => {
  const enabledMfa = event.user.app_metadata.guardian;
  if (!enabledMfa) {
    console.log("MFA not enrolled. Enrolling user.");
    // Require the user to do an MFA.
    api.multifactor.enable("guardian");
    // Update the user's metadata to represent that they've enabled MFA.
    api.user.setAppMetadata("guardian", true);
  }
};

MFA on client request

For the scenario in the previous posts the goal is to have the client to request that the Authentication Server pushes the user through an MFA flow.

The first thing to do is to get the scopes from the request. These scopes are on the transaction object as the requested_scopes property. Both of these could be undefined so make sure to take that into account.

function extractScopesFromEvent(event) {
  return event.transaction ? event.transaction.requested_scopes || "" : "";
}

Once we have the scopes we need to check if they include the mfa:required scope.

  if (scopes.includes("mfa:required")) {
  // push the user to MFA
  }

If the scope is present we need to tell the Authentication Server to push the user through MFA.

      api.multifactor.enable("guardian");

Then we add the current timestamp in to the access token so that the server can known the last time the user did an MFA check.

    api.accessToken.setCustomClaim(`https://kleeut.com:mfaTime`, Date.now());

The final code for the step up MFA Action looks like this:

function extractScopesFromEvent(event) {
  return event.transaction ? event.transaction.requested_scopes || "" : "";
}

exports.onExecutePostLogin = async (event, api) => {
  const scopes = extractScopesFromEvent(event);
  if (scopes.includes("mfa:required")) {
    console.log("Requiring MFA");
    // Force the user to do a Guardian MFA.
    api.multifactor.enable("guardian");
    // Set to custom claim for when the MFA is complete.
    api.accessToken.setCustomClaim(`https://kleeut.com:mfaTime`, Date.now());
  }
};

This is the updated code for the previous posts in this series. The working code and a full example with a client and a server can be found on GitHub.

Building a zero dependency PKCE Auth client

Klee Thomas — Sat, 01 Jan 2022 08:07:27 +0000

This post goes through how to build a PKCE client for browser using TypeScript based applications with no dependencies. If you want to know more about what PKCE (Proof Key Code Exchange) is you can read my previous post, What Is PKCE.

Before I start on how do to this, as a general rule I would use a client side library provided by a reputable authentication vendor, like the React SDK provided by Auth0 for any production application I was building. If you're interested in what is going on under the hood in libraries like that, or you have a specific use case, or you're just interested in a hands on example of how PKCE works then I'll go through how I implemented this only using what is available in the browser.

The example code for this blog can be found on GitHub

A quick qualification on what I mean when I say zero. This is written in TypeScript so clearly there are some dependencies at play. There are no production dependencies and four dev dependencies,

TypeScript: for adding the wonderful development experience that is types in my code.
Prettier: because formatting should be an afterthought.
ESlint: to help catch stupid mistakes.
Parcel: To bundle the scripts together and serve the sample site.

Steps

PKCE can be broken down into a number of steps. I'll address each of those in turn.

Generate code verifier

The first step is to generate the code verifier that can be used to generate the code challenge and later used to verify that this app was in fact the app that originally requested authentication.

The code verifier is random data presented as a Base64 URL encoded string.

Generate the random data

The browser has some APIs that allow us to generate some random data. For this we need to use the web crypto API available at window.crypto or globalthis.crypto. The function to generate random values is getRandomValues this takes an ArrayBuffer and fills it with random data. For PKCE we need that ArrayBuffer to be a string. We can get this using the String.fromCharCode function. The random code generation function looks like this:

function randomCode(): string {
  let array = new Uint8Array(32);
  array = globalThis.crypto.getRandomValues(array);
  return String.fromCharCode.apply(null, Array.from(array));
}

Base64 url encoding the data

The final step in generating a code verifier is to base64 url encode the random string. To turn our string into base64 we can use the btoa function available in the browsers global scope. To make this base64 string base64 url encoded we need to replace all the "+", "/" and "=" with "-", "_" and "" (empty string) respectively, we can replace these values using a chain of String.replace functions and regular expressions.

The code to base64 url encode a string looks like this:

function base64URLEncode(str: string): string {
  const b64 = btoa(str);
  const encoded = b64.replace(/\+/g, "-").replace(/\//g, "_").replace(/=/g, "");
  return encoded;
}

Generate the challenge

The second step in PKCE is to generate the code challenge. This is derived from the code verifier generated in the previous step. To derive it we need to apply the SHA256 hash function to the code verifier string.

Hashing the code verifier with SHA256

To hash the code verifier string we can use the web crypto api provided to us by the browser. The digest function on crypto.subtle will create a hash for us, but we need to pass in the algorithm we want to use and the data as something that implements the BufferSource interface.

For the first argument we want a SHA256 algorithm so we pass in { name : "SHA-256" }. For the second argument we need to change our code verifier string into a TypedArray we can do this using an instance of the TextEncoder class new TextEncoder().encode(s).

const sha256Hash = await crypto.subtle.digest(
  { name: "SHA-256" },
  new TextEncoder().encode(str)
);

Finally we need to base64 url encode our hash which has been created as an ArrayBuffer. To do this we need to jump through a couple of hoops to convert the ArrayBuffer containing our hash to a string that we can base64 using the same mechanism as previously.
Let's start by taking our ArrayBuffer and making it into a TypedArray specifically a Uint8Array: new Uint8Array(hash). From here we can convert that into a number array: Array.from(uint8Array). This can be converted into a string using the String.fromCharCode function String.fromCharCode.apply(null, Array.from(numberArray)). This string can be passed through the same base64 and url encoding functions as were used in the code verifier creation. The final sha256 function looks like this:

const sha256 = async (str: string): Promise<string> => {
  const hashArray = await getCryptoSubtle().digest(
    { name: "SHA-256" },
    new TextEncoder().encode(str)
  );
  const uIntArray = new Uint8Array(hashArray);
  const numberArray = Array.from(uIntArray);
  const hashString = String.fromCharCode.apply(null, numberArray);
  return base64URLEncode(base64(hashString));
};

Store the verifier

We'll need the code verifier after redirecting off to the authentication server so it needs to be stored in between renders. To do this I'll store it in the local storage. The store verifier function looks like this:

export function storeVerifier(verifier: string) {
  localstorage.setItem("verifier", JSON.stringify({ verifier }));
}

Generate the login url

The next to do is to generate the url tha we need to redirect the user to so that they can authenticate.

For this example I'm using Auth0 as the authentication server. Some configuration will need to be done in the authentication server and some of the parameters that we need to include in the url will need to be sourced from the Auth0 dashboard.

We'll be directing the user to login using a url so any information that we need to pass to the authentication server must be passed as a query parameter to do that I'll use the URLSearchParams object to make things easier.

The values I'll be appending as query parameters are:

parameter	variable in example	notes
`client_id`	`auth0ClientId`	The ID of the Auth0 application / client the user is logging into. Copy from Auth0
`audience`	`auth0ApiAudience`	The ID of the API that the token will be issued to access. Copy from Auth0
`response_type`	Hard coded `"code"`	This has to be code in order to use PKCE.
`scope`	`scope`	The scopes (space delimited) that are being requested. These need to be configured in Auth0 or they'll be ignored
`recirect_uri`	`authCallbackUrl`	This is the url that will be redirected back to. This must be explicitly configured to be allowed in Auth0. In this case it's the same URL as the web app is being served from.
`code_challenge`	`challenge`	The challenge generated previously
`code_challenge_method`	Hard coded `"sha256"`	Auth0 only supports SHA 256 as the challenge method

These values are then appended as a query string to the auth0BaseUrl that is the url for the Auth0 tenant (e.g. https://tenantname.au.auth0.com).

function authLoginUrl(): string {
  const params = new URLSearchParams();
  params.append("client_id", auth0ClientId);
  params.append("audience", auth0ApiAudience);
  params.append("response_type", "code");
  params.append("scope", scope);
  params.append("redirect_uri", authCallbackUrl);
  params.append("code_challenge", challenge);
  params.append("code_challenge_method", "S256");
  const url = new URL(`${auth0BaseUrl}/authorize?${params.toString()}`);
  return url.toString();
}

Now when the user clicks on or is redirected to the URL generated by the authLoginUrl they will be directed to Auth0 as the authentication server. They will the be redirected back to the redirect_url. The next thing to do is to handle that redirect and get an access token.

Handling the redirect

Once the user had completed authenticating at the authentication server then they're redirected back to our app and we have to pick up the code flow in order to get an identity token and access token.

Get the code

The first stage once the user has been redirected back to the client is to get the code. The code is passed back as a query parameter in the url. I'll do this by passing the query string to the URLSearchParams object constructor and checking for the presence of a code parameter. If the code object is there we can exchange it for access and identity tokens. The code to get the code looks like this:

const queryParams = new URLSearchParams(window.location.search);
if (queryParams.has("code")) {
  const code = queryParams.get("code");
  handleAuthorizationCodeExchange(code);
}

Retrieve the code verifier

In order to exchange the code for an access token we are going to need to have the code verifier that was used to generate the code challenge previously. Before redirecting to the authentication server I stored this in local storage so we'll need to retrieve that; localStorage.getItem("verifier")

Exchange the code

To exchange the code for an access token we need to make a POST request back to the authentication server on the <authentication-server-url>/oauth/token endpoint.

The request body needs to include some information to prove that this client should be granted an access token.

parameter	variable in example	notes
`grant_type`	`"authorization_code"` hard coded	For PKCE this has to be `"authorization_code"`
`client_id`	`auth0ClientId`	The client id for the Auth0 client/application. This has to be the same as was used when requesting the code
`code_verifier`	`codeVerifier`	The code verifier that was used to generate the code challenge in the previous step. This is retrieved from local storage.
`code`	`code`	The code extracted from the query string
`redirect_uri`	`authCallbackUrl`	The same callback url that was passed when requesting the user authenticate

The request body is going to look like this:

const res = await fetch(`${auth0TokenUrl}`, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    grant_type: "authorization_code",
    client_id: auth0ClientId,
    code_verifier: codeVerifier,
    code,
    redirect_uri: authCallbackUrl,
  }),
});

Read the response

A successful response from the authentication server will include a JSON response body that matches this signature:

type TokenResponse = {
  access_token: string;
  refresh_token: string;
  id_token: string;
  token_type: "Bearer";
  expires_in: number;
};

The last thing to do is to parse the fetch response. Here I'm writing it out to the tokens to the DOM, just to show that they've been received.

if (response.ok) {
  const resJson = (await response.json()) as TokenResponse;
  writeToDom(`<p>Got tokens ${JSON.stringify(resJson)}</p>`);
  return;
}

Summing up

In this article I've gone through the steps to authenticate a user using PKCE using only the API's available in the browser. I said it at the top but I'll say it again, unless there is a solid reason to implement your own PKCE I'd strongly suggest using a library to take care of it for you. It's not worth committing to maintaining your own implementation when the libraries are fantastic.

The example code for this blog can be found on GitHub

The dev trivia question everyone got wrong

Klee Thomas — Sat, 06 Nov 2021 03:41:53 +0000

Every year I run a tech trivia game for the local tech community. We can bring together multiple meetups from the community together and have a fun end of year event. It's meant to be fun so I aim to have everyone get most of the questions right.

In 2019 I asked this one question that I didn't expect to catch as many people out, it turns out everyone on the night got it wrong. I've shown the question to a lot of developers since then. To this day less than 5 of the developers I've asked have been able to give me an answer to the question.

The Question

When this JavaScript snippet is run what gets logged, and why?

(Why is important because outside of the trivia night anyone can just run it in the console).

const out = () => {
var one = "1"
var two = 2
var three =
one / two
var four = three == true
var five = !!four ===
false ? "true" : false
return
five;
}

console.log(out());

Caution spoilers below

The Answer

The answer is
...
...
Are you sure you want to know?
...
...
O.K. The answer is :

undefined

Why

You may have thought that it should be true or specifically the string "true". But you'd be wrong. You'd be wrong because JavaScript is helping out and identifying the end of a statement, effectively automatically adding semi colons. In this case it's adding a semi colon after the return statement and returning undefined.

Why do people get it wrong?

There are a few tricks at play here that make this questions hard.

No semicolons

Lets tackle the obvious one first. The lack of semi colons in the code. If we add semicolons at the end of every statement what's happening becomes a bit more clear.

const out = () => {
var one = "1";
var two = 2;
var three =
one / two;
var four = three == true;
var five = !!four ===
false ? "true" : false;
return;
five;
}

console.log(out());

Terrible formatting

The code has also be formatted in a way to make it confusing as to what is going on. This code looks a lot busier than it is because the statements have been broken over multiple lines and there is not formatting to help tie those statements together and make it legible.
If the formatting is improved it looks like this:

const out = () => {
  var one = "1";
  var two = 2;
  var three = one / two;
  var four = three == true;
  var five = !!four ===
    false ? "true" : false;
  return;
  five;
}

console.log(out());

With those changes (and some syntax highlighting) it becomes more obvious that the code is going to show some unexpected behaviour.

Making your code safe

There are some steps that can be added to a project to help prevent this kind of unexpected behaviour.

Fortunately for us we live in an age of amazing developer tooling that can be added to a project with a few keystrokes.

Use an development environment like Visual Studio Code. This can highlight that five in this example is unreachable code.

Add an automatic code formatter like Prettier. Prettier can be hooked into your code editor and configured to run every time you save a file.

Use a linter like eslint to alert you when there is unreachable code. Linters can also be hooked into your dev environment so you can see issues.

Linters and code formatters can also be hooked into git so that if they're not happy with the code the code can't be committed. For JavaScript projects consider husky and lint-staged.

Use TypeScript. TypeScript is all the rage, and for good reason. If you were to add TypeScript and require type signatures on functions it would be clear that this function was always going to return undefined or TypeScript would throw a compilation error saying that the expected string return value was not getting returned.

Finally, writing unit tests would help to show this code was behaving in an unexpected way. Unit testing is a great way to ensure correctness in your software. It's even better if you write the tests first and follow a TDD (Test Driven Development) workflow.

Trivia 2021

Thanks for reading all the way to the end. If you're around Newcastle NSW Australia or can be on the 15th of December we'll be hosting the 2021 trivia event. RSVP on Meetup https://www.meetup.com/Newcastle-Coders-Group/events/278720624/

Cloudflare workers Continuous Deployment with Github Actions

Klee Thomas — Tue, 02 Nov 2021 20:33:36 +0000

In the previous post I went through using Cloudflare's wrangler tool to set up Clouflare Workers using a config as code approach. This approach needed to be run from a local machine. While this allows changes to be tracked in version control it leaves room for what's running and what's in version control to be out of sync.

A better solution is to have changes pushed into the main branch automatically deployed into the production environment.

This post will go through taking the example from the previous post and setting it up to deploy to Cloudflare on each push to the main branch. I will do this using Github Actions.

Cloudflare have provided a base action that can be used to deploy workers from Github Actions.

To get this functioning I'll add a new file to the repository. .github/workflows/buildAndDeploy.yml. This file will include the following text taken from the actions readme.

name: buildAndDeployWorker
on: push
jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    steps:
      - uses: actions/checkout@v2
      - name: Publish
        uses: cloudflare/wrangler-action@1.3.0
        with:
          apiToken: ${{ secrets.CF_API_TOKEN }}

The ${{ secrets.CF_API_TOKEN }} subs in a secret value that needs to be provided in the Github API. Before I can put that into Github I have to get it from Cloudflare.

To create a new token I need to:
Log in to Cloudflare, open the workers tab and then select Manage Workers.

Select API tokens.

Create a new API token

Start with the cloudflare workers template

Give the token a meaningful name

Limit the resources the token has to my account and the saladsimulator zone.

Continue to the summary

And create the token

Now Cloudflare will display the API token. Once this page is closed the token is gone so I need to immediately copy it into Github. (I can re-run through the steps above to generate a new one if I need to.)

Over in github I've opened the settings tab and secrets section.

And added my secret copied from Cloudflare

Now when I push the action code it runs and deploys to Cloudflare

The logs show the successful deployment output from wrangler.

Downloading release from https://workers.cloudflare.com/get-npm-wrangler-binary/1.19.3/x86_64-unknown-linux-musl
wrangler has been installed!
+ @cloudflare/wrangler@1.19.3
added 22 packages from 9 contributors in 2.082s
 No build command specified, skipping build.
 Successfully published your script to
 foo.saladsimulator.com/* => stayed the same
 https://foo-stage-auth.kleeut.workers.dev

What is PKCE?

Klee Thomas — Sat, 23 Oct 2021 07:04:13 +0000

PKCE or Proof Key Code Exchange (often pronounced "Pixie") is an acronym you may have seen around when looking into how to authenticate users in modern web apps.

So what is PKCE?
PKCE is an extension to the Authorization Code Flow grant that is part of the OAuth 2.0 spec. The problem that PKCE solves is that native mobile applications and Single Page web apps are not able to securely store a client secret in order to prove it's identity.

What problem are we solving by ensuring that a client can prove it's identity?
The problem is with the way that Authorization Code Flow works. It works by:

The Client Application redirecting the user to the Authentication Server
The user logs into the Authentication Server
The user is redirected back to the Client Application with a code as a query parameter
The Client Application sending a POST request to the Authentication Server with the code.
The Authentication Server responding with an Identity Token an optionally an Access Token and Refresh Token.

So where is the problem?
The problem is that anyone who gets the code from that query string can exchange it for tokens.

And how does PKCE address this?
PKCE adds an extra parameter into both the initial redirect and the code exchange POST request. This request takes the form of a challenge in the initial call and a verifier in the subsequent one. The verifier is a string of randomly generated characters. The challenge is a SHA 256 hash (Base64 Url Encoded) of the verifier. The Authorization Server receives the challenge with the initial login request and stores the challenge along side the code. When the request comes in to exchange that code the for a token the original verifier string must be sent along with the request. The Authorization Server then performs the same hashing function on the verifier that has been passed by the client. If the generated hash matches then the challenge sent in the initial request server returns the tokens, otherwise the request is rejected.

This means that by using PKCE the client provides a Key that can be used as Proof that it was the requester of the authentication during the Code Exchange.

How do you implement PKCE?
I plan to post a follow up to this with code examples of how to implement the client side of of PKCE. That is really just for anyone who is interested in how it works under the hood.
The reality, like anything in Identity and Security, you should use a library to take care of it for you. Auth0 provide fantastic and easy to use libraries that are known to work.