DEV Community: Simon Martyr

Too Good To Go Go

Simon Martyr — Fri, 13 Oct 2023 12:51:40 +0000

In my previous article I created a command line version of one of my favourite mobile application, Picnic. This made me consider what other apps do I use on a regular basis which I could enhance for my personal use? I am not sure if this is going to be an ongoing series, but lets continue with Too Good To Go.

Too Good To Go

The Too Good To Go application is a great initiative that allows businesses which typically produce food waste to offer food they can no longer sell at a reduced rate to the public.
The application works by scanning your surroundings and listing the businesses that have products which can be purchased that day. It a win for the businesses and consumers as well as a reduction in waste.

The API

The application has straightforward API, once authenticated users can do the following:

Search for items
Manage items (save them as favourites)
Manage orders

I found it interesting that for all endpoints, responses were compressed using GZIP. This offers many benefits such as faster loading time from reducing the bandwidth, but this might also be motivated by the apps focus towards environmental impact. If your application can reduce the amount of data it transfers that can decrease the energy consumption and associated carbon emissions.

Many of the endpoints such as querying for items, leverage POST to pass content that can be used for performing a search. While this is not unusual (look at GraphQL), a dedicated QUERY keyword for HTTP requests would be highly desirable in this scenario https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-02.html.

Your options for filters are as follows:

body := ItemsQueryRequest{
  UserId:         c.userId,
  Origin:         Origin{query.Latitude, query.Longitude},
  Radius:         query.Radius,
  PageSize:       query.PageSize,
  Page:           query.Page,
  Discover:       query.Discover,
  FavoritesOnly:  query.FavoritesOnly,
  ItemCategories: query.ItemCategories,
  PickupEarliest: query.PickupEarliest,
  PickupLatest:   query.PickupLatest,
  SearchPhrase:   query.SearchPhrase,
  WithStockOnly:  query.WithStockOnly,
  HiddenOnly:     query.HiddenOnly,
  WeCareOnly:     query.WeCareOnly,
 }

I suspect if a GET was used, it would produce a pretty large URL and was deemed undesirable.

Authentication

Too Good To Go authentication process is not password based, instead they leverage a ‘magic link’ strategy. When a user wishes to authenticate, the TGTG backend produces a short lived link and sends that to the user’s email. Upon clicking the link, typically the user is re-directed to the application on their phone and they are now authenticated.

If the user however opens the link on a different device (not their phone), the device making the initial request will continue to poll the TGTG backend until it receives a signal that the authentication was successful.

The result of the successful authentication is a user identifier, access token, refresh token and cookie.

The cookie is important as it contains a DataDome value, which servers a similar purpose to recaptcha in trying to mitigate bots.

For all requests that require authentication, the user’s identity, access token and cookie are required. These access token last for four hours and require a refresh when expired.

So what did I make?

My idea was, I’ll create a script that I could load onto a Raspberry Pi that could on a scheduled interval check certain items and if those items are available send me an email.

I guess you could say the script would wake me up before it was too good to go go.

You might be curious, doesn’t their mobile application already have notifications like this?

The application does offer notifications, however you cannot opt into only availability of items. You also receive notifications regarding feature updates, promotions & ‘more’. Therefore I wanted to have more control over this.

Initialising

For the script to work I needed to capture authentication data, notification information as well as which items to track.

By using the standard lib flag I could allow the user to initialise the script with the -i flag plus their account email address.

func main() {
 initialise := flag.String("i", "", "configure notifier")
 flag.Parse()
 if *initialise != "" {
  log.Println("Starting Initialisation...")
  log.Println("You will receive an email to authenticate.")
  Initialise(*initialise)
  return
 }
}

The initialiser logic made use of the API’s Authentication flow and upon success produced a json configuration file containing the acquired authentication details, items favourited by the user and an email config

{
  "email_config": {
    "to": "example@example.com",
    "account": "gmail"
  },
  "credentials": {
    "email": "",
    "user_id": "9999999",
    "access_token": "token",
    "refresh_token": "token",
    "cookie": "cookie data"
  },
  "items": [
    {
      "name": "FEBO",
      "item_name": "Snackpakket",
      "item_id": "999999",
      "notify": true,
      "last_notified": "2023-10-09"
    },
  ]
}

Checking

The default behaviour of the script is to loop over the items which are within the config and see if they have new availability and sending all the results as an email.

I decided that a notification should only occur once per item, per day. To achieve this, the config notes the last_notified date in order to perform a notification check.

func ShouldNotify(toCompare string) bool {
 if toCompare == "" {
  return true
 }
 currentTime := time.Now().Format("2006-01-02")
 current, err1 := time.Parse("2006-01-02", currentTime)
 compare, err2 := time.Parse("2006-01-02", toCompare)
 if err1 != nil || err2 != nil {
  fmt.Println("Error parsing date strings:", err1, err2)
  return false
 }
 return current.Sub(compare) >= 24*time.Hour
}

Notifying

My Raspberry Pi by default had sendmail installed, which I considered using. However all emails using this approach, emails got flagged as spam so I opted to use msmtp instead with a dedicated gmail account. I guess my Raspberry Pi could watch YouTube now if it wishes.

func (t *TgtgNotifier) SendNotification(items []*toogoodtogo.Item) error {
 log.Println("Preparing email")
 emailConfig := t.Config.EmailConfig
 emailContent, emailErr := CreateEmail(ParseItems(items))
 if emailErr != nil {
  return emailErr
 }
 emailMessage := fmt.Sprintf("To: %s\nSubject: %s\nContent-Type: text/html\n\n%s", emailConfig.To, subject, emailContent)
 cmd := exec.Command("msmtp", "-a", emailConfig.Account, emailConfig.To)
 cmd.Stdin = strings.NewReader(emailMessage)
 cmdErr := cmd.Run()
 if cmdErr != nil {
  return cmdErr
 }
 log.Println("Email sent")
 return nil
}

This also exposed me to one of Go’s best features, templates. The email I wished to send I created the HTML and produced it as a Go HTML template. This allows you to dynamically adjust it.

<table>
    <tr>
        <th>Store Name</th>
        <th>Item Name</th>
        <th>Pickup Time</th>
    </tr>
    {{range .Items}}
    <tr>
        <td>{{.StoreName}}</td>
        <td>{{.ItemName}}</td>
        <td>{{.PickupTime}}</td>
    </tr>
    {{end}}
</table>

The HTML above allows a slice to be provided which will be iterated over to populate table rows.

func CreateEmail(content *[]PickupInfo) (string, error) {
 tmpl, templateErr := template.New("emailTemplate").Parse(emailTemplate)
 if templateErr != nil {
  return "", templateErr
 }
 var output bytes.Buffer
 emailContent := struct{ Items *[]PickupInfo }{Items: content}
 exeErr := tmpl.Execute(&output, emailContent)
 if exeErr != nil {
  return "", exeErr
 }
 return output.String(), nil
}

Here is the end result

Scheduling the Check

Once I was happy with the application I needed to build targeting linux and arm so it could be ran on the pi and copied it over to device.

GOOS=linux GOARCH=arm go build -o bin/tgtg-linux . && scp ./bin/tgtg-linux pi@ip:tgtg/

After initialising it, I leveraged the crontab in order to schedule a task to be run every 15 mins to perform the check:

 */15 * * * * cd <location of script> && <script> > <location of script>/logfile.log 2>&1

For any possible errors added a log file.

Done

I now had the notifier I wanted for Too Good To Go, plus got more exposure to different parts of Go.

If you wish to checkout the complete source code, feel free to check them out:

Picnic-TUI - Where Go and Groceries Create a Command-Line Feast

Simon Martyr — Tue, 12 Sep 2023 14:27:37 +0000

During some downtime I decided I would really like to try to learn Go. It was a language I had some exposure to in past client projects, and my coworkers who used it gave it glowing reviews. Some of which were even using it for side projects, such as doing analytics on property prices in the area through the use of web scrapers. Something which is very useful in Amsterdam.

I didn’t initially have a real goal or use case for the language but that didn’t hold me back from giving it a shot.

My learning route

When learning any new programming language I like to approach it in the following steps:

Learn the basics of the syntax and get a feel for the language.
Try out some basic algorithms - solve some leet code problems.
Make a basic to-do app.
Enhance that app work to work with a database or HTTP endpoint etc.
Build more silly apps.

Like most beginners, I started with the a tour of go and got a quick feel for the language. I feel all languages should copy a tour of go as its a delightful introduction to the language which builds confidence quickly.

I continued with my learning plan

Invert a binary tree on leet code.
Made a basic to-do app.
Remade it to work with Gin and SQL.

Step 5 build more silly apps

In the words of Ben Davis: https://www.youtube.com/watch?v=OqdBixi_y1s

Just build stuff.

A web scraper

Inspired by my coworker’s web scraper project and Claud’s Article. I made a basic web scraper app to perform silly analytics on my company’s website. To answer questions such as:

Who has the longest profile description?
What is the frequency of the different job titles?

Credit to the package tgraph for giving me the ability to draw these cool graphs in the terminal with the results.

Pokemon CLI

It was at this point I was getting a lot of joy out of writing command line applications. I had also just learnt of the existence of spotify-tui and wanted to explore more I could build such applications. So building interfaces for APIs felt like a good way to try this out.

The PokeApi is a resource I like to use whilst getting familiar with making HTTP calls in a new language. So I threw together such a simple app to leverage all the various methods the API offered.

Time to do the groceries

In between learning Go I got curious if there was an API for the app I use for doing my groceries? I am an avid user of the Picnic, Picnic is an online supermarket who operate in Europe. Customers of Picnic do so exclusively via their mobile application.

However the thought crossed my mind, what if I could automate aspects of my weekly shop? Something like a script that pre-loads my basket in advance, that could be useful.

Fortunately for me I came across https://github.com/MRVDH/picnic-api/ an unofficial Node.js package for the picnic API. This was perfect, I made a few scripts using the node module mission accomplished.

Enter Picnic-TUI

Now that I got a taste of what I could do with the Picnic API the natural follow up was to make a wrapper for the API and terminal user interface in Go.

The goal in my mind at this point being, if at any point in the day, I want to add something to my order I could do so from the comfort of my terminal and not have to reach for my phone. This is not a bash at Picnic’s mobile app, I simply wanted to reduce the distraction which is my phone.

Picture it, you are writing code in your favourite terminal based text editor (lets say neovim) and you are configuring a new Spring bean. It is in this moment you remember you need beans. Simple you hit :term run picnic-tui add them straight to your basket and get back into the code.

The API

Using the documentation from https://github.com/MRVDH/picnic-api/ this allowed me to produce the base for a Go wrapper https://github.com/simonmartyr/picnic-api.

At this point I had the functionalities for:

Authenticating
Getting user information
Searching for products
Adjusting the cart
Selecting delivery slots

Sniffing the rest

At this point I was really satisfied with everything I could do with the API. But I wanted to try and make a more complete experience. Would it be possible to finalise an order? How would the payment flow go?

As I mentioned I had expended all the knowledge I had acquired from the Node library so that left me with one option. Intercepting all the outgoing requires from my phone to Picnic to learn all of the APIs I had not captured.

To accomplish this I used the tool https://www.charlesproxy.com. Conveniently Charles Proxy also has an iOS application which allowed me intercept all outgoing request from my iPhone.

This gave me all the information I needed to identify the endpoints and payloads I would need to succeed my goal.

A note on the authentication parts

I found it curious and would welcome any response if any Picnic developers happen to be reading. When a client authenticates with the API they send the user’s username and password as well as a client id. The detail I found interesting was the password needs to be MD5 hashed prior to being sent. I’m curious as to why, and curious if that MD5 hashed password is persisted as is or additionally encrypted.

Upon a successful authentication, a JWT is issued which can then be used as a header for endpoints which require authentication. A behaviour I did observer however is, the tokens specify an expiration time (of one day), but the server continues to accept expired tokens.

I believe the intention is that clients would persist the users credentials on device in a secure enclave. Likely storing the MD5 hashed password rather than in plain text. Each day or when it believes its token has expired the application calls the authentication endpoint to get a new one.

Ideally the tokens do not continue to live, as if a token did fall into the wrong hands, that person would continue to have access and the real user would be none the wiser.

Time to checkout

Prior to intercepting the http requests the checkout flow was unknown to me. From observing the endpoints I learnt that at the moment a user invokes a checkout request the API performs the following actions:

Request to start the checkout.
If articles in the cart produce an error (such as alcohol) prompt user (ask if user is 18+).
Upon successful confirmation a request is sent to start the checkout again with the relevant resolve key.
At this point a request for payment can be initiated which returns a payment link for the customer to complete their payment.

Due to the payment being simply an ideal link, I wanted to explore if I could render a QR code in the terminal to complete an order.

The TUI

With my API library complete, it was time to set my focus on producing a terminal UI. My inspiration was to replicate the feel of Spotify-TUI. The interface of Spotify-TUI was simple but effective in its implementation.

The interface combined multiple intractable views in which the user can navigate the core functionality of Spotify. This application adjusted my expectations on what a terminal based ui could achieve.

Additionally I had an appreciation for the detail to include vim motions in many aspects of their interface for example ‘/’ to search, the option to use ‘h’, ‘j’, ‘k’, ‘l’ in place of arrow keys. From top to bottom the developers demonstrate a lot of passion and care.

The Picnic Application

The images above show screenshots from the Picnic mobile application. Typically a user would search the application for different articles of food they wish to have delivered and add them to their basket. When they are satisfied with their selection, the user schedules a delivery date and pays for the order. When the time comes around for the oder to be delivered, the application can even show the route the driver is taking, so they are aware as to what time their delivery should arrive.

Within my application, I wanted to only support the functionality to create an order. Rendering the route information of the ongoing delivery would be very cool, but for my needs didn’t add value.

Evolution of the screens

Spotify-TUI was developed in Rust, therefore I couldn’t simply use the same UI framework. Within Go a popular choice is tview https://github.com/rivo/tview which provides many similar UI widgets which covered all my needs.

I initially started with the main screen. I wanted to explore how much I could do with the product searching and manipulating the basket.

It was surprising to me how simple it was to get the barebones going. One widget I relied on heavily in tview was flex views. They work similar to flex boxs in the web world, where you can add a collection of different views into a flex view and those widgets would be arranged and sized correctly.

func newMainPage() *MainPage {
    //reduced for simplicity    
leftFlex := tview.NewFlex().SetDirection(tview.FlexRow).
        AddItem(mainPage.Search, 3, 1, false).
        AddItem(mainPage.ArticleImage, 0, 4, false).
        AddItem(mainPage.ArticleInfo, 0, 4, false)

    flex := tview.NewFlex().
        AddItem(leftFlex, 0, 1, false).
        AddItem(mainPage.Articles, 0, 2, false).
        AddItem(mainPage.Basket, 0, 1, false)

    mainPage.Flex = tview.NewFlex().SetDirection(tview.FlexRow).
        AddItem(flex, 0, 5, false)

    return mainPage
}

When you add an item to flex view, you can instruct to tview if that item has a fixed size or the proportions of the view and if that view should be focused (meaning the screen highlights that view making it listen to interactions).

Main Page

One idea that I had with the main page that I was curious to pull off was, how would I see the products in the terminal?

tview included an image widget that required a reference to an image. So within the API I wrote a method to query the image url and pass the response body through a png decoder and see what happens.

func (c *Client) GetArticleImage(articleImageId string, size ImageSize) (*image.Image, error) {
    url, urlErr := c.GetArticleImageUrl(articleImageId, size)
    if urlErr != nil {
        return nil, urlErr
    }
    res, resErr := c.http.Get(url)
    if resErr != nil {
        return nil, resErr
    }
    if res.StatusCode != http.StatusOK {
        return nil, c.parseError(res)
    }
    articleImage, imageErr := png.Decode(res.Body)
    if imageErr != nil {
        return nil, imageErr
    }
    return &articleImage, nil
}

Success, I could see what peanut butter looks like in the terminal.

Delivery Page

I attempted initially to have the delivery slots as a dynamic element that appeared on the main page. However this felt clunky and overall a bad end user experience.

My first iteration of the delivery view was to create a list of all the slot with an item highlighted when the day changed. It felt natural at this point to move this content into its own page by leveraging the tview pages widget.

This widget allows you to set different views as a page within your application and dynamically switch to them when needed.

For the delivery page I experimented with the idea to generate content into a flex view. The idea was simple, each time there was a new day, create a new list of options and add that to a growing flex view.

The API only returned the possible delivery slots for the next seven days, so I knew it shouldn’t grow out of control.

With the experiment a success, I cleaned up the view by not having all lists look like they were being interacted with at the same time. Additionally I highlighted which slot was currently selected and which were the more environmental options.

Checkout Page

The checkout page was fun, because as mentioned above there is a sequence of events in order to complete the order.

The biggest part of the puzzle was, how would I render the payment QR code?

Luckily the library https://github.com/skip2/go-qrcode allowed for a QR code to be generated as a string allowing that string to be presented inside a text view.

func (c *CheckoutPage) renderPaymentLink(url string) {
    q, _ := qrcode.New(url, qrcode.Highest)
    c.PaymentLink.SetText(q.ToSmallString(true))
    c.Instructions.SetText("Scan QR code to complete or ESC to cancel")
}

The other challenge inside the checkout page was to present different checks and errors based on the content of the cart.

Within the API, I decided that errors produced by the checkout should be wrapped in their own error object allowing for the page to dynamically handle them.

For example, if the cart contains alcohol, the user is instructed to confirm they are 18+ or if they haven’t met the minimum order price modals are presented to the user with directions of what to do.

If all actions are successfully resolved the screen presents the QR code allowing for the completion of the order.

Final words

I reached my goal and successfully made a complete order and had my perfect cli tool to manage my groceries.

More importantly it gave me a great platform to experiment and learn more about Go. This experience really reenforced to me if you can find something that gives you joy to build your learning will go faster and you will get more out of it.

If you wish to checkout the source code of the API or TUI check them out here:

Links and references

Testing Passkeys / WebAuthn with Spring

Simon Martyr — Thu, 06 Jul 2023 13:26:08 +0000

Passkeys are a technology that have gained a lot of traction, which is understandable given the promise of having more convenience without sacrificing security.

Now we are seeing companies such as CVS and Best Buy shipping implementations, I believe the adoption rate will continue to accelerate fast and users will start to expect passkeys more.

After experimenting with https://webauthn.io I was quickly convinced I wanted to implement them also.
So I got to work, reading up the specification, and implementing the library - Webauthn4j - github
As soon as I got a basic implementation going it dawned on me, how am I going to test this?

Monday rolled around, and as fun as it was opening a browser and testing the registration and authentication flow manually, I much prefer to cover this flow via integration tests.

Terminology

Relying Party - Is an entity which controls access. They determine the rules or checks in order to grant access.

Challenges - In order to prevent replay attacks, WebAuthn utilise challenges during the registration and authentication ceremonies. A challenge is a payload, greater than 16 bytes randomly generated. The challenge is created by the relying parties in a trusted environment (the server). The challenge exists until the operation is complete.

Attestation Object - The content of this object could be compared to a certificate or blue print that an authenticator provides to prove it’s trustworthy. The content typically includes details such as a signature, credential IDs, and a public key. When received by the relying party the content is checked to determine if the client can be trusted.

Client Data JSON - This JSON object contains contextual information relating to the relaying party, it contains information such as the challenge issued, the origin and what type of process is being performed (webauthn.create or webauthn.get).

What are we testing?

WebAuthn has two main flows, registration and authentication.

Registration - or the registration ceremony is where a user and a relying party (the server) communicate in an effort to create and exchange authentication information. The end goal is the server receives the user’s public key to be used for authentication in later authentication attempts.

Authentication - follows a similar pattern to registration in that the client and relying party exchange information in a structured manner. However the goal this time being, can the server verify if the user is who they claim to be. This is achieved by the client producing a signature using the servers issued challenge with their private key. The server verifies the signature using the public key it acquired during the registration phase.

Registration flow:

The client requests permission to store their authentication details (1.1).
The server provides the options for the client to achieve this as well as a challenge (1.3).
The client generates an attestation object and returns it to the server (2.1).
The server verifies the response and if satisfied stores the authentication data (2.2 - 2.6).
The server returns a success, registration is complete (2.7).

Authentication flow

The client sends their username requests permission to authenticate (1.1).
The server locates the keys associated with that user and generates a challenge (1.2 - 1.5).
The client uses its private key to create a signature from the challenge and sends it back to the server (2.1).
The server verifies the user and grants access (2.2 - 2.8).

The challenge for both of these flows is that they have a physical element, the client’s device.

The device is responsible for safeguarding the clients private key and other cryptographic activities. Typically this device is the user’s computer, USB stick or phone.

How can we test this?

WebAuthn4j provides a library for testing: mvnrepository link

The library contains a emulator utility which can act simulate authenticators such as FIDO U2F Keys. Emulator Github

My setup

JUnit
Spring Boot test
MockMvc
Liquibase
Testcontainers - (for dependencies such as databases)

Note
The example code below gives a general direction, but be sure to add more tests cases.

Firstly I have a base abstract class which is helpful for the general setup of all my integration test as well as configuring things such as test containers in one place:

@Testcontainers
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureMockMvc
@ActiveProfiles({"test", "console"})
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
public abstract class AbstractIntegrationTest {
    private static final MySQLContainer<?> MYSQL_SQL_CONTAINER;

    static {
        MYSQL_SQL_CONTAINER = new MySQLContainer(DockerImageName.parse("mysql"))
                .withDatabaseName("mydb")
                .withUsername("user")
                .withPassword("secret");
        MYSQL_SQL_CONTAINER.withImagePullPolicy(PullPolicy.alwaysPull());
        MYSQL_SQL_CONTAINER.withReuse(true);
        MYSQL_SQL_CONTAINER.withEnv("MYSQL_ROOT_PASSWORD", "secret");
    MYSQL_SQL_CONTAINER.start();
    }

    protected final ObjectWriter ow = new ObjectMapper()
            .setSerializationInclusion(JsonInclude.Include.NON_NULL)
            .disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)
            .findAndRegisterModules()
            .writer()
            .withDefaultPrettyPrinter();

    @DynamicPropertySource
    static void overrideTestProperties(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", MYSQL_SQL_CONTAINER::getJdbcUrl);
        registry.add("spring.datasource.username", MYSQL_SQL_CONTAINER::getUsername);
        registry.add("spring.datasource.password", MYSQL_SQL_CONTAINER::getPassword);
    }
}

Testing Registration Flow

To test the registration flow, we can start out simple, lets verify that our registration options are returned and that it contains a challenge:

class PasskeyRegistrationControllerIntegrationTest extends AbstractIntegrationTest {
    private static final String PASSKEY_URL = "/passkey";
    private static final String PASSKEY_REGISTER_URL = PASSKEY_URL + "/register";
    private static final String PASSKEY_REGISTER_VERIFY_URL = PASSKEY_URL + "/register-verify";
    private final ObjectMapper om = new ObjectMapper();
    @Autowired
    private MockMvc mockMvc;

    @Test
    @WithMockCustomUser(userName = "billybob@bill.com") 
    void passkey_registration_verify_options() throws Exception {
        final String rpName = "finaps";
        mockMvc.perform(post(PASSKEY_REGISTER_URL)
                        .content(ow.writeValueAsString(PasskeyRegisterRequestDto.builder().build()))
                        .contentType(MediaType.APPLICATION_JSON)
                        .accept(MediaType.APPLICATION_JSON)
                ).andExpect(status().isOk())
                .andExpect(jsonPath("$.rp.name", is(rpName)))
                .andExpect(jsonPath("$.challenge", is(not(emptyString()))));
    }
}

From the registration diagram this should cover steps 1.1 - 1.3.

During the registration and authentication the server issues challenges. These challenges are kept on the server and typically have a short lifespan of a couple minutes. In my example scenario I simply keep the challenge in an in memory list.

@Test
@WithMockCustomUser(userName = "billybob@bill.com")
void passkey_registration_flow() throws Exception {
    String regRes = mockMvc.perform(post(PASSKEY_REGISTER_URL)
                    .content(ow.writeValueAsString(PasskeyRegisterRequestDto.builder().build()))
                    .contentType(MediaType.APPLICATION_JSON)
                    .accept(MediaType.APPLICATION_JSON)
            ).andExpect(status().isOk())
            .andReturn().getResponse().getContentAsString();

    PasskeyRegisterResponseDto res = om.readValue(regRes, PasskeyRegisterResponseDto.class);
    ClientPlatform client = EmulatorUtil.createClientPlatform();

    mockMvc.perform(post(PASSKEY_REGISTER_VERIFY_URL)
            .content(ow.writeValueAsString(createPasskeyVerifyRequest(client, res)))
            .contentType(MediaType.APPLICATION_JSON)
            .accept(MediaType.APPLICATION_JSON)
    ).andExpect(status().isNoContent());
}

For my complete flow test, I call the first endpoint to get the registration settings from the server and parse the content and pass it into the ClientPlatform which is the emulator provided by WebAuthn4j

The method createPasskeyVerifyRequest is a helper method for transforming my data transfer object into the format expected by the emulator and generating a verification request.

public class PasskeyEmulatorUtilities {

    public static PasskeyRegisterVerifyRequestDto createPasskeyVerifyRequest(
            ClientPlatform clientPlatform,
            PasskeyRegisterResponseDto registerResponseDto) {

        PublicKeyCredential<AuthenticatorAttestationResponse, RegistrationExtensionClientOutput> key =
                createPasskey(clientPlatform, registerResponseDto);

        PasskeyRegisterVerifyRequestResponseDto responseObj = PasskeyRegisterVerifyRequestResponseDto.builder()
                .attestationObject(Base64UrlUtil.encodeToString(key.getAuthenticatorResponse().getAttestationObject()))
                .clientDataJSON(Base64UrlUtil.encodeToString(key.getAuthenticatorResponse().getClientDataJSON()))
                .build();

        return PasskeyRegisterVerifyRequestDto.builder()
                .id(key.getId())
                .rawId(new String(key.getRawId()))
                .response(responseObj)
                .build();
    }

  public static PublicKeyCredential<AuthenticatorAttestationResponse, RegistrationExtensionClientOutput> createPasskey(
            ClientPlatform clientPlatform,
            PasskeyRegisterResponseDto registerResponseDto) {
        return clientPlatform.create(createPublicKeyCredentialCreationOptions(registerResponseDto));
    }

  private static PublicKeyCredentialCreationOptions createPublicKeyCredentialCreationOptions(
      PasskeyRegisterResponseDto registerResponseDto) {
        Challenge challenge = new DefaultChallenge(registerResponseDto.getChallenge());
        return new PublicKeyCredentialCreationOptions(
                parseRp(registerResponseDto.getRp()), 
                parseUser(registerResponseDto.getUser()),
                challenge,
                parsePubKeys(registerResponseDto.getPubKeyCredParams()),
                6000L,
                Collections.emptyList(),
                parseAuthenticatorSelection(registerResponseDto.getAuthenticatorSelection()),
                null,
                null
        );
    }
}

These two tests cover the ‘happy flow’ outlined in the sequence diagram above. But its good to add unhappy flows such as - what if the challenge is changed? If this were to occur it should violate the registration ceremony.

@Test
@WithMockCustomUser(userName = "billybob@bill.com")
void passkey_registration_flow_fails_due_to_challenge() throws Exception {
    String regRes = mockMvc.perform(post(PASSKEY_REGISTER_URL)
                    .content(ow.writeValueAsString(PasskeyRegisterRequestDto.builder().build()))
                    .contentType(MediaType.APPLICATION_JSON)
                    .accept(MediaType.APPLICATION_JSON)
            ).andExpect(status().isOk())
            .andReturn().getResponse().getContentAsString();

    PasskeyRegisterResponseDto res = om.readValue(regRes, PasskeyRegisterResponseDto.class);
    res.setChallenge("reallyWrongChallenge");
    ClientPlatform client = EmulatorUtil.createClientPlatform();

    mockMvc.perform(post(PASSKEY_REGISTER_VERIFY_URL)
                    .content(ow.writeValueAsString(createPasskeyVerifyRequest(client, res)))
                    .contentType(MediaType.APPLICATION_JSON)
                    .accept(MediaType.APPLICATION_JSON)
            ).andExpect(status().isBadRequest())
      .andExpect(jsonPath("$.detail", is(REGISTRATION_FAILED)));
}

Testing Authentication flow

As we stated, for authentication to work, we need the client and server to register information about each other before they can perform an authentication. However having to make a request each test to register a key and then perform a login would get messy and more importantly make our tests slower.

However the emulator from webauthn4j makes this easy, when performing the clientPlatform.get the emulator uses the identifier from the allowed credentials as a seed to generate the key pair needed.

public static @NonNull KeyPair createKeyPair(@Nullable byte[] seed, @NonNull ECParameterSpec ecParameterSpec) {
    KeyPairGenerator keyPairGenerator = createKeyPairGenerator();
    SecureRandom random;
    try {
        if (seed != null) {
            random = SecureRandom.getInstance("SHA1PRNG"); // to make it deterministic
            random.setSeed(seed);
        }
        else {
            random = secureRandom;
        }
        keyPairGenerator.initialize(ecParameterSpec, random);
        return keyPairGenerator.generateKeyPair();
    } catch (NoSuchAlgorithmException | InvalidAlgorithmParameterException e) {
        throw new UnexpectedCheckedException(e);
    }
}

Therefore, if we seed our database with a key id and public key we’ve previously generated using the emulator we should be good.

For the authentication scenarios I leverage liquibase to pre-seed the database with a user and key credentials acquired from the emulator.

This allows me to keep my authentication tests simple:

class PasskeyAuthenticationControllerIntegrationTest extends AbstractIntegrationTest {
    private static final String PASSKEY_URL = "/passkey";
    private static final String PASSKEY_LOGIN_URL = PASSKEY_URL + "/login";
    private static final String PASSKEY_LOGIN_VERIFY_URL = PASSKEY_URL + "/login-verify";
    private final ObjectMapper om = new ObjectMapper();
    private final PasskeyAuthenticationRequestDto userWithPasskeyRequest = PasskeyAuthenticationRequestDto.builder()
            .username("passkey@smh.com")
            .build();

    private final PasskeyAuthenticationRequestDto userWithoutPasskey = PasskeyAuthenticationRequestDto.builder()
            .username("nomates@billy.com")
            .build();
    @Autowired
    private MockMvc mockMvc;

    @Test
    void passkey_login_verify_options() throws Exception {
        final String rpName = "localhost";
        mockMvc.perform(post(PASSKEY_LOGIN_URL)
                        .content(ow.writeValueAsString(userWithPasskeyRequest))
                        .contentType(MediaType.APPLICATION_JSON)
                        .accept(MediaType.APPLICATION_JSON)
                ).andExpect(status().isOk())
                .andExpect(jsonPath("$.rpId", is(rpName)))
                .andExpect(jsonPath("$.challenge", is(not(emptyString()))));
    }

    @Test
    void passkey_login_flow() throws Exception {
        String regRes = mockMvc.perform(post(PASSKEY_LOGIN_URL)
                        .content(ow.writeValueAsString(userWithPasskeyRequest))
                        .contentType(MediaType.APPLICATION_JSON)
                        .accept(MediaType.APPLICATION_JSON)
                ).andExpect(status().isOk())
                .andReturn().getResponse().getContentAsString();

        PasskeyAuthenticationResponseDto res = om.readValue(regRes, PasskeyAuthenticationResponseDto.class);
        ClientPlatform client = EmulatorUtil.createClientPlatform(new FIDOU2FAuthenticator());
        mockMvc.perform(post(PASSKEY_LOGIN_VERIFY_URL)
                        .content(ow.writeValueAsString(createPasskeyAuthVerifyRequest(client, res)))
                        .contentType(MediaType.APPLICATION_JSON)
                        .accept(MediaType.APPLICATION_JSON)
                ).andExpect(status().isOk())
                .andExpect(cookie().exists("refreshToken"))
                .andExpect(jsonPath("$.loginStatus", is(LoginStatusDto.SUCCESS.getValue())))
                .andExpect(jsonPath("$.accessToken", is(not(emptyString()))))
                .andExpect(jsonPath("$.expiresIn", any(Integer.class)));
    }
}

And here is the logic for createPasskeyAuthVerifyRequest


public class PasskeyEmulatorUtilities {

    public static PasskeyAuthenticationVerifyRequestDto createPasskeyAuthVerifyRequest(
            ClientPlatform clientPlatform,
            PasskeyAuthenticationResponseDto authenticationRequestDto) {
        final String id = authenticationRequestDto.getAllowedCredentials().get(0).getId();
        final PublicKeyCredential<AuthenticatorAssertionResponse, AuthenticationExtensionClientOutput> authenticatePasskey =
                authenticatePasskey(clientPlatform, authenticationRequestDto);

        final PasskeyAuthenticationVerifyRequestResponseDto response = PasskeyAuthenticationVerifyRequestResponseDto.builder()
                .signature(Base64UrlUtil.encodeToString(authenticatePasskey.getAuthenticatorResponse().getSignature()))
                .authenticatorData(Base64UrlUtil.encodeToString(authenticatePasskey.getAuthenticatorResponse().getAuthenticatorData()))
                .clientDataJSON(Base64UrlUtil.encodeToString(authenticatePasskey.getAuthenticatorResponse().getClientDataJSON()))
                .build();

        return PasskeyAuthenticationVerifyRequestDto.builder()
                .id(id)
                .rawId(id)
                .type("public-key")
                .response(response)
                .build();
    }

    public static PublicKeyCredential<AuthenticatorAssertionResponse, AuthenticationExtensionClientOutput> authenticatePasskey(
            ClientPlatform clientPlatform,
            PasskeyAuthenticationResponseDto authenticationRequestDto) {
        return clientPlatform.get(createPublicKeyCredentialRequestOptions(authenticationRequestDto));
    }

    private static PublicKeyCredentialCreationOptions createPublicKeyCredentialCreationDefaultOptions(
              PasskeyRegisterResponseDto registerResponseDto) {
        Challenge challenge = new DefaultChallenge(registerResponseDto.getChallenge());
        return new PublicKeyCredentialCreationOptions(
                parseRp(registerResponseDto.getRp()),
                parseUser(registerResponseDto.getUser()),
                challenge,
                parsePubKeys(registerResponseDto.getPubKeyCredParams())
        );
    }

    private static List<PublicKeyCredentialDescriptor> parsePublicKeyCredentialDescriptors(
              List<PasskeyCredentialsDto> allowedCredentials) {
        return allowedCredentials.stream()
                .map(m -> new PublicKeyCredentialDescriptor(
                        PublicKeyCredentialType.PUBLIC_KEY,
                        Base64UrlUtil.decode(m.getId()), //Don't forget to decode
                        null
                ))
                .toList();
    }
}

This approach allows us to quickly build up confidence in our passkey implementation. I’m keen to see if I can take it up a notch and leverage something like playwright to control a browser and perform the flows in that sort of manner. But for now this was a good first step.

If you have an suggestions of improvement of observations feel free to let me know.

DEV Community: Simon Martyr

Too Good To Go Go

Too Good To Go

The API

Authentication

So what did I make?

Initialising

Checking

Notifying

Scheduling the Check

Done

Picnic-TUI - Where Go and Groceries Create a Command-Line Feast

My learning route

Step 5 build more silly apps

A web scraper

Pokemon CLI

Time to do the groceries

Enter Picnic-TUI

The API

Sniffing the rest

A note on the authentication parts

Time to checkout

The TUI

The Picnic Application

Evolution of the screens

Main Page

Delivery Page

Checkout Page

Final words

Links and references

Testing Passkeys / WebAuthn with Spring

Terminology

What are we testing?

Registration flow:

Authentication flow

How can we test this?

My setup

Testing Registration Flow

Testing Authentication flow

Links and References