DEV Community: Daniel Griffiths

Creating a Custom UI for Ory Cloud with React/Nextjs

Daniel Griffiths — Wed, 18 Jun 2025 12:26:29 +0000

Ory is a cloud (or self-hosted) authentication and authorisation service.

Like many authentication/authorisation-as-a-service providers, it comes with minimally customisable screens to enable users to login, register, verify emails and the like.

Also like many authentication providers, if you need to do anything except the bare minimum in customisation, it is not simple. In Ory's case, you will need to self-host custom UI pages (a custom login page, custom registration page etc.).

This article will show you how you can create your own customised UI screens for a hosted ory cloud instance using React (specifically nextjs in my case, though vanilla React would be very similar).

Why am I writing this? Why not use the ory documentation?

To be blunt, Ory's documentation around custom UIs is not good.

There are links to articles that are 5 years old and out of date. There are links to packages that have been superseded by similarly named but slightly different newer packages. There are links to example codebases that use deprecated packages or are poorly documented or do not run, or any combination of the three.

It took me days to work out what I needed to do to get a custom UI up and running. My hope with this article is to give people a real starting point and save them some of my pain.

Setup

You will need:

A hosted ory network account and project
The ory CLI
Node v22.11.0 (may work with other versions of node)
A nextjs app

Within the nextjs app, these were the packages (and versions) that I used:

@ory/nextjs - 1.0.0-rc.0
@ory/elements-react - 1.0.0-rc.5
next - 15.2.4 (may work fine with other versions)
react and react-dom - 19.0.0 (may work fine with other versions)

Other packages I investigated

@ory/elements - Seems to be deprecated. A note in the readme recommends using @ory/elements-react, despite plenty of the ory documentation linking directly to this elements package.

@ory/client - This is an alternative to @ory/nextjs. It is not deprecated according to the readme, but it seems to be recommended to use @ory/client-fetch instead, a package that functions similarly but uses fetch instead of axios. The code lives here.

@ory/client-fetch - This appears to be the recommended package to use for getting flows from the client side. If I were to use vanilla React and not nextjs, this is what I would use instead of @ory/nextjs. Code can be found here.

@ory/integrations - again despite being mentioned in the official documentation, this package is marked as deprecated by the readme on github - see here.

Useful example projects

I trawled through a number of the example codebases in ory's github. Of those, only one is useful - this one:

https://github.com/ory/elements/tree/main/examples/nextjs-app-router

it uses the combination of packages I eventually used to get my custom UI working. Due to poor documentation I was not able to get this example project (nor any of the example projects) running locally, but this one came closest.

At the time of writing (17/06/2025) I would not recommend reading any of the other official ory example projects. I did, and they did nothing but confuse me with poor documentation, non-working code or references to deprecated packages.

Overview of process

Before diving into the steps in the next section, it is worth understanding what we need to do at a high level.

1. Get the custom UI and ory onto the same domain

To communicate securely with ory network, the custom UI must be hosted on the same top level domain as your ory instance.

This is because it uses a CSRF cookie to communicate between ory and the custom UI app. More can be found about this here.

In production, this will mean you need to give your ory instance a custom URL at one subdomain and then host your custom UI at another subdomain, for example ory could be given the custom url signin.website.co.uk and your custom UI could be hosted at direct.website.co.uk.

In development, the easiest way to do this is by using ory tunnel (which is available through the ory CLI). This will make your ory instance available at a localhost port. This is what we will be doing.

2. Flow IDs

The custom UI gets information from ory by exchanging flow IDs for flow objects.

These flow objects detail what UI elements to display, validation errors, current state, CSRF tokens to include when submitting data back to ory and generally everything you need to guide a user through whatever flow they've commenced.

The easiest way to exchange these is by using ory sdk libraries. In my case this was @ory/nextjs.

Note:
It is theoretically possible to exchange flows and submit login requests etc. without using libraries, however it was not clear exactly what I needed to do from the documentation and I was not able to get it to work.

An example flow object for logging in can be found below:

{
  "created_at": {},
  "expires_at": {},
  "id": "761fdc7a-327a-4d6c-bbb1-ba8d2cd05618",
  "issued_at": {},
  "refresh": false,
  "request_url": "http://localhost:3000/self-service/login/browser?aal=&refresh=&return_to=&organization=&via=",
  "requested_aal": "aal1",
  "state": "choose_method",
  "type": "browser",
  "ui": {
    "action": "http://localhost:3000/self-service/login?flow=761fdc7a-327a-4d6c-bbb1-ba8d2cd05618",
    "method": "POST",
    "nodes": [
      {
        "attributes": {
          "disabled": false,
          "name": "csrf_token",
          "node_type": "input",
          "required": true,
          "type": "hidden",
          "value": "csrf_value"
        },
        "group": "default",
        "messages": [],
        "meta": {},
        "type": "input"
      },
      {
        "attributes": {
          "disabled": false,
          "name": "identifier",
          "node_type": "input",
          "required": true,
          "type": "text",
          "value": ""
        },
        "group": "default",
        "messages": [],
        "meta": {
          "label": {
            "id": 1070004,
            "text": "ID",
            "type": "info"
          }
        },
        "type": "input"
      },
      {
        "attributes": {
          "autocomplete": "current-password",
          "disabled": false,
          "name": "password",
          "node_type": "input",
          "required": true,
          "type": "password"
        },
        "group": "password",
        "messages": [],
        "meta": {
          "label": {
            "id": 1070001,
            "text": "Password",
            "type": "info"
          }
        },
        "type": "input"
      },
      {
        "attributes": {
          "disabled": false,
          "name": "method",
          "node_type": "input",
          "type": "submit",
          "value": "password"
        },
        "group": "password",
        "messages": [],
        "meta": {
          "label": {
            "id": 1010022,
            "text": "Sign in with password",
            "type": "info"
          }
        },
        "type": "input"
      }
    ]
  },
  "updated_at": {}
}

3. Interpret the flow object

Given the flow object received from ory, you must interpret this into UI that the user can use to complete their flow (to login, or reset their password etc.).

The easiest way to do this is with the @ory/elements-react package.

The official ory documentation around this process can be found here.

Steps

Now we'll cover the specific steps you need to take to set up a custom UI. We'll start with a login page, but the process is similar for recovery, settings etc.

1. Set up ory tunnel

As prerequisites for this step, I am assuming you have already signed up to ory cloud and have at least one project running.

I am additionally assuming that you have the ory CLI set up, if not it can be downloaded from here.

After that, we will need to run the following command to set up the tunnel to your ory project:

ory tunnel --workspace workspace-id --project project-id http://localhost:3000

This will open up a tunnel between the project on the given workspace-id with the given project-id and your localhost.

This command assumes your custom UI will be running at http://localhost:3000, if it is running on a different port, you should use that port instead.

If you don't have your workspace and project ids, you can get them by using the following commands:

ory list workspaces

and

ory list projects --workspace [workspace-id]

then simply find the relevant workspace-id and project-id and replace the placeholders in the tunnel command above.

After you have run the command, visit http://localhost:4000/ui/login to see the default hosted ory login page.

Note: The ory tunnel runs on port 4000 by default. This can be overridden if you like, see the documentation linked here.

2. Environment setup

First, create a nextjs app satisfying the requirements as detailed at the start of this article. As a reminder, these mainly are:

node - 22.11.0
@ory/elements-react package - version 1.0.0-rc.5
@ory/nextjs package - version 1.0.0-rc.0

Aside from these, I used the following packages at the following versions:

next - 15.2.4
react and react-dom - 19.0.0

Finally you will need to add theORY_SDK_URL value to your .env file.

ORY_SDK_URL=http://localhost:4000

3. Create basic custom login page

With these all installed, add a new page at src/app/auth/login/page.tsx.

Note: I used the app router but it should work perfectly fine with the pages router too. Similarly I used typescript but it should work perfectly fine with jsx files).

This is the bare minimum required to get a custom login page:

// /login/page.tsx

import { getLoginFlow, OryPageParams } from "@ory/nextjs/app";
import { Login } from "@ory/elements-react/theme";
import { OryClientConfiguration } from '@ory/elements-react';

const oryConfig: OryClientConfiguration = {
  sdk: {
    url: process.env.ORY_SDK_URL,
    options: {
      basePath: process.env.ORY_SDK_URL,
    },
  },
  project: {
    default_locale: 'en',
    default_redirect_url: '/',
    error_ui_url: '/error',
    locale_behavior: 'force_default',
    name: 'My Custom UI',
    registration_enabled: false,
    verification_enabled: true,
    recovery_enabled: true,
    registration_ui_url: '/auth/registration',
    verification_ui_url: '/auth/verification',
    recovery_ui_url: '/auth/recovery',
    login_ui_url: '/auth/login',
    settings_ui_url: '/settings',
  },
};

export default async function LoginPage(props: OryPageParams) {
  const flow = await getLoginFlow(oryConfig, props.searchParams);

  if (!flow) {
    return <div>Loading...</div>;
  }

  return <Login flow={flow} config={oryConfig} />;
}

NOTE: The @ory/nextjs package should only be used server-side, otherwise it attempts to bake environment variables into static pages at build time. This is more a quirk between nextjs app router and the @ory/nextjs package than an actual bug, but worth pointing out because it caused me pain.

Production Note: In a production environment, the @ory/nextjs package will automatically use the ORY_SDK_URL without it needing to be specified in the config, but I've found that in development you need to specify it in the oryConfig explicitly.

4. Ory console config and finishing up

Finally, go to your project in the ory cloud console, then Branding > UI Urls

Then set the login UI Url to redirect to the page we just added:

Now, if you navigate to http://localhost:4000/ui/login, you should be redirected to your new custom page.

Congratulations!

Next Steps

More Styling

Because it is within your own react app, you can obviously style everything surrounding the flow at your own discretion. Additionally, you can override specific components within the flow too, for example here we wrap a custom card component around the default ory flow.

<Login
  flow={flow}
  config={oryConfig}
  components={{
    Card: {
      Root: ({ children }) => (
        <LoginCard>
          <div className="ory-form-wrapper">{children}</div>
        </LoginCard>
      ),
    },
  }}
/>

I believe you can also override custom css classes too, though I have not needed to do this myself.

Note: You can override individual inputs by specifying components for them like above, however unless they are specified very carefully, inputs created in such a way will break form submission. I have not yet worked out how to specify these inputs such that submission is not broken.

The example above is for the login flow, but there are similar components within ory elements for each of the standard flows, for example getRecoveryFlow from @ory/nextjs to get the recovery flow and Recovery from @ory/elements-react to display it.

See the pages in the app router in this project for basic examples of other pages.

Production Deployment

As long as the custom UI is hosted on the same domain as ory, and the UI URLs are set up correctly in the ory network console, this should work similarly to the development environment.

Debugging Tips

If you hit any roadblocks setting anything up - I recommend joining the ory slack. Within it they have an AI agent on a channel which is usually able to point you in the right direction and is generally quite helpful.

Documentation - as stated previously in this article - is hit and miss. Some pages are extremely useful, some are extremely out of date, and there is no way to tell which is which except painful trial and error.

Generative AIs (chatGPT, claude and the like) are next to useless in my experience - ory is too niche for them to be able to work well. I got 50/50 hallucinations to useful information, though your mileage may vary.

Conclusion

Creating a custom UI for my ory cloud instance was a painful process of trial and error.

My hope is that this article can take away some of that pain for other developers that need to do this in future.

How to connect to an Azure-hosted managed identities postgres server from a node app using the Prisma ORM

Daniel Griffiths — Tue, 21 Jan 2025 16:52:48 +0000

Introduction

If your organisation requires enhanced security, then they may require databases to be authenticated using Azure managed identities.

If that is the case then connecting to databases through a node app using the Prisma ORM can be problematic - it is not something supported by prisma out of the box.

This article will explain how you can adapt your node/prisma app to allow it to connect to an Azure managed identities postgres database.

The Problem

Azure Managed Identities

If you enable Azure managed identities on a postgres server (as described in this documentation), then instead of connecting to postgres in the traditional way using a standard password, you will instead need to request a token from Azure and use this as a password.

Unlike standard passwords, these tokens only have a limited lifespan (usually in the order of hours), so they will need to be refreshed periodically when making new connections to the database.

Once connections are made, they are valid until closed even if the token expires before the connection is closed, but any new connections will need a new token.

The limited lifespan of these tokens can cause issues for Prisma. It is not something it supports out of the box.

Prisma ORM

The standard way to connect to a postgres database through Prisma is via the DATABASE_URL environment variable, which typically looks like this:

DATABASE_URL="postgresql://username:password@localhost:5432/my_db?schema=public"

The PrismaClient will then use this to generate connections to the specified database and store them in a pool to be used for queries.

This works very well when connecting to a postgres server that uses standard authentication, but it is not ideal for servers that use Azure managed identities authentication.

In the latter case, the ‘passwords’ (tokens) that we use to connect expire every hour, so even if we were to generate one, set it as an environment variable and then immediately start our app, we would only be able to reliably communicate with the database for the lifespan of the token.

So how do we get around this?

Potential Solutions

There are a number of potential solutions listed in the discussions of this issue on prisma’s github page.

Most are far from perfect, with ideas like destroying/recreating the Prisma Client every time a token’s lifespan expires or simply re-requesting a token and retrying the request as soon as a connection fails.

There is one solution hinted at deep within the comments which is much cleaner, and is the basis for this entire article (so big thanks to that person!)

The Solution

The cleanest solution I have found is to give the Prisma Client a ‘password generation’ function, which will request a token from Azure whenever a new connection is made to the database.

Because we are requesting a new token with each new connection, we don’t need to worry about the token’s lifespan, and we don’t need to worry about destroying/recreating Prisma Clients (or any other similar heavy solutions).

Because connections remain valid until closed, we also don’t need to worry about tokens expiring on long-lived connections. Once they are open, they are authenticated.

The main complexity in this solution is in it’s initial implementation - The standard Prisma Client will not allow you to supply a ‘password generation’ function, so you need to create a custom adaptor to do so.

Read on to find out how.

Environment

First, these are the packages you will need. I have also listed the versions I have used in my solution. It might work with other versions but I have not tested them.

@prisma/client - version 5.22.0.
@prisma/adapter-pg - version 6.0.0.
pg - version 8.13.1.
@azure/identity- version 4.5.0.

I am also assuming you already have:

A postgres server set up with Azure managed identities authentication, and an empty database within it.
The Azure CLI, and a user that is capable of generating tokens and has permissions to connect to your chosen database.
A node app with prisma already set up, with at least an initial migration.

Optional - Connecting Manually

Before building the solution into the app, we will connect manually to the database. It is useful to verify that you can connect manually because there are a lot of moving parts if anything does go wrong, and this is a good way to rule out the connection itself being an issue.

Additionally, we will be able to set up our database with migrations by connecting manually (if required).

First, open a terminal and log in to the Azure CLI (if you haven’t already):

az login

Then we need to manually generate a token:

az account get-access-token --resource-type oss-rdbms

This should generate something like this:

{
  "accessToken": "eyJ0...7Hy1mMNRg",
  "expiresOn": "2024-12-23 12:39:53.000000",
  "expires_on": 1734957593,
  "subscription": "subscription-id-here",
  "tenant": "tenant-id-here",
  "tokenType": "Bearer"
}

We can then use this token as the password when connecting to your database from your database IDE of choice (or simply from psql).

Verify that the token is working by connecting to your database.

Next we will use this token to connect from node/Prisma and run migrations on the Azure managed identities server database.

Optional - Running initial migrations from the node/prisma app

We can copy/paste the access token generated in the previous section into our prisma DATABASE_URL (or into the password variable wherever else you might be generating the prisma client):

DATABASE_URL="postgresql://username:eyJ0...7Hy1mMNRg@your-server-name.postgres.database.azure.com:5432/my_db?schema=my_schema"

If you then run the migrations using the prisma migrate command, then the app should be able to connect and the migrations should be applied successfully.

Custom Prisma Client Generator

We have now verified the connection works and run our migrations. Next we need to give the prisma client the ability to generate tokens when it creates new connections.

First, let’s create a function that can connect to Azure and request the access token:

import { DefaultAzureCredential } from "@azure/identity";

export default async function getAzurePostgresToken(
  azureIdentityId: string,
): Promise<string> {
  const credential = new DefaultAzureCredential({
    managedIdentityClientId: azureIdentityId,
  });

  const tokenResponse = await credential.getToken(
    "https://ossrdbms-aad.database.windows.net/.default",
  );

  if (!tokenResponse || !tokenResponse.token) {
    throw new Error(
      "Could not acquire access token for postgres",
      500,
      false,
    );
  }

  return tokenResponse.token;
}

We can then use this function to request a new token each time a connection is made. There is no way to pass in this function using the default prisma client, so we will need to create a custom adaptor:

import { PrismaClient } from "@prisma/client";
import { Pool } from "pg";
import { PrismaPg } from "@prisma/adapter-pg";

function generateNewPrismaClient(): PrismaClient {
  const pool = new Pool({
    host: config.PG_HOST,
    port: config.PG_PORT,
    database: config.PG_DATABASE,
    user: config.PG_USER,
    ssl: { rejectUnauthorized: true },
    password: async () => {
      return await getAzurePostgresToken(config.AZURE_MANAGED_IDENTITY_ID);
    },
  });

  const adapter = new PrismaPg(pool);
  return new PrismaClient({ adapter });
}

We can then call this function to generate a new Prisma Client and distribute it throughout the app.

Conclusion

Big thanks again to this comment, without which I never would have found this solution.

It took some digging to find that comment. I hope that in making an article around it, it makes the solution more visible for future developers.

Mocking with Jest and typescript - a cheatsheet

Daniel Griffiths — Thu, 19 Dec 2024 12:29:12 +0000

Jest is great at mocking imports in javascript/typescript, but I find it very hard to remember implementation specifics.

Functions and objects need to be mocked in different ways, default exports are mocked subtly differently to named exports, and Jest doesn't work particularly well with typescript. Combine all these things and it can be hard to work out, or even search for, the correct approach for your mocking scenario.

I have created this guide to answer the question "How do I mock my import?" no matter what that import might be. Default or named, function or object.

My Environment

I have tested all of these approaches using the following versions of software:

node v22.11.0
jest v29.7.0
ts-jest v29.2.5
@types/jest v29.5.14

And with a default, minimal jest.config.js file:

export default {
  testEnvironment: 'node',
  transform: {
    '^.+.tsx?$': ['ts-jest', {}],
  },
  testMatch: ['**/*.test.ts'],
};

Mocking Imports

Broadly common imports fall into two categories that we might want to mock:

functions
objects

We will tackle them both in turn, starting with functions.

Importing functions

Functions exported from modules can be named or default. We will look at both. First:

Mocking a named exported function from a module

This should be used to mock a named exported function from a module, something like this:

// ./path/to/module.ts

export function doSomething(...) {
  ...
}

It can be mocked like so:

import { doSomething } from './path/to/module';

// note: This should be the path to the module from the test file,
// NOT from the module that contains the doSomething function itself.
jest.mock('./path/to/module', () => ({
  doSomething: jest.fn(),
}));

...

it('should do something', () => {
  // We need to assert that the function is a jest.Mock
  // so that typescript will allow us to call mock methods.
  (doSomething as jest.Mock).mockReturnValue(mockValue);

  // run your test here

  expect(doSomething).toHaveBeenCalledTimes(1); // etc.
});

Mocking the default function returned from a module

This should be used to mock a function that is the default export from a module, something like this:

// ./path/to/module.ts

export default function doSomething(...) {
  ...
}

It is mocked similarly to named exports:

import doSomething from './path/to/module'

jest.mock('./path/to/module', () => ({
  __esModule: true,
  default: jest.fn()
}))

...

it('should do something', () => {
  (doSomething as jest.Mock).mockResolvedValue(mockData);

  // Run your test here

  expect(doSomething).toHaveBeenCalledTimes(5);
});

Importing objects

There are a few variations to consider when mocking an exported object (be that a class, json object or otherwise).

Is it a named or default export?
Does it have methods we also wish to mock, or just properties?

Mocking default objects with no methods

If you just need to mock properties (a config file for example), not methods, then this is how to do it:

import config from '../config';

jest.mock('../config', () => ({
  __esModule: true,
  default: {
    apiKey: '123MockKey',
    ...
  },
}));

...

it('Should do something', () => {
  ...
});

And if the mocked properties need to vary per test:

import config from '../config';

const mockConfig = {
  apiKey: '123MockKey',
  ...
};

jest.mock('../config', () => ({
  __esModule: true,
  default: mockConfig,
}));

...

beforeEach(() => {
  // restore defaults before each test
  mockConfig.apiKey = '123MockKey';
  ...
});

it('Should do something', () => {
  mockConfig.apiKey = 'new value';

  // rest of the test
});

// more tests

Mocking named export objects without methods

Very similar to mocking default export objects:

import { config } from '../config';

const mockConfig = {
  apiKey: '123MockKey',
  ...
};

jest.mock('../config', () => ({
  config: mockConfig,
}));

// the rest is exactly the same as when mocking a default export object.

Mocking an object with methods

When an object with methods is exported (named or default) from a module and we need to mock the output of those methods, the approach is slightly different.

Given a class:

// ./path/to/module.ts

class ComplicatedThing {
  // properties, fields, constructor etc. go here

  getData() {
    ...
  }

  ...
}

// note: I don't necessarily recommend exporting an instance
// of a class like this - purely illustrative for testing purposes.
// https://medium.com/@lazlojuly/are-node-js-modules-singletons-764ae97519af
export const complicatedThing = new ComplicatedThing(...);

And to mock our exported object:

import { complicatedThing } from './path/to/module';

jest.mock('./path/to/module', () => ({
  complicatedThing: {
    getData: jest.fn()
  }
}));

...

it('Should do something', () => {
  (complicatedThing.getData as jest.Mock).mockReturnValue(mockData);

  // run the test here

  expect(complicatedThing.getData).toHaveBeenCalledWith(...);
});

Mocking a default export object is exactly the same except when we define the mock:

jest.mock('./path/to/module', () => ({
  __esModule: true,
  default: {
    getData: jest.fn()
  },
}));

Bonus: Mocking methods on an object passed directly to a test function/class as a parameter

This is for mocking an object that is not directly imported into a module you're testing, but is instead passed in as a parameter to a class/function.

Note: If you are mocking a class, you might instead wish to create an interface and create a mock implementation of that to pass into your function/class. This will save you needing to do inelegant type assertion shenanigans as below.

// ./path/to/module

export class ComplicatedThing {
  // properties and constructor etc.

  getData(...) { ... }

  updateData(...) { ... }
}

// .path/to/doSomething
import { ComplicatedThing } from './path/to/module';

export function doSomething(myComplicatedThing: ComplicatedThing) {
  ...
}

import { ComplicatedThing } from './path/to/module';
import { doSomething } from './path/to/doSomething';

const mockGetData = jest.fn();
const mockUpdateData = jest.fn();

// typescript shenanigans - asserting that it IS a given type will
// allow us to pass that into functions as a parameter of that type.
const mockComplicatedThing = {
  getData: mockGetData,
  updateData: mockUpdateData
} as unknown as ComplicatedThing;

...

it('Should do something', () => {
  mockGetData.mockReturnValue(mockData);
  mockUpdateData.mockReturnValue(moreMockData);

  const response = doSomething(mockComplicatedThing);

  expect(mockUpdateData).toHaveBeenCalledWith(...);
});

Mocking global functions

I encountered this again shortly after writing this article and felt it important enough to cover here.

Some commonly used functions and objects are available globally within javascript - console, process and fetch, for example.

In order to mock a function within this global scope (specifically fetch in this case):

global.fetch = jest.fn();

describe("When testing", () => {

  beforeEach(() => {
    jest.clearAllMocks();
  });

  it("Should do something", async () => {
    (global.fetch as jest.Mock).mockResolvedValue({ ok: true, status: 200 });

    const response = await somethingThatCallsFetch(...);

    expect(global.fetch).toHaveBeenCalledTimes(123);
  });
});

Conclusion

I hope this will be useful to you, and to my future self when I next struggle to remember the details for how to mock imports in typescript.

I hope that it can cover all of your simple mocking needs, and give you a place to begin when mocking more complex imports.

Thanks for reading.

Upload large files to AWS S3 using Multipart upload and presigned URLs

Daniel Griffiths — Fri, 22 Mar 2024 15:16:37 +0000

If you need to upload large files to AWS S3 from the client, the best way to do this is with multipart uploads and presigned URLs.

There are some articles out there that cover this process already, so why am I writing this?

None of the existing articles are written specifically for node with typescript (or at least none that are up to date). I had to trawl the AWS documentation for the specific functions, methods and types I needed to perform an upload in node. Hopefully this article will save you some of my pain.

Big thanks to the author of this article, which I was able to use as an overview of the steps I needed to take in this process.

Why presigned URLs?

This article is a nice introduction to why you might want to use presigned URLs.

Prerequisites

Basic familiarity with AWS
An AWS account with an existing S3 bucket and an environment with access and permissions to access and upload to that bucket.
Basic familiarity with a node server-side framework and client-side framework.
The AWS-SDK v3 configured on your local machine.

These are the specific AWS-SDK library versions I used in node:

"@aws-sdk/s3-request-presigner": "3.534.0",
"@aws-sdk/client-s3": "3.534.0",

Steps

Start a multipart upload on the server side.
Generate presigned URLs on the server side.
Split your file into chunks and use each presigned URL to upload each chunk.
Complete the multipart upload on the server side.

Step 1: Start a multipart upload

This should be run on the server side in whatever back end node framework you're using.

import {
    S3Client,
    CreateMultipartUploadCommand
} from '@aws-sdk/client-s3';

...

const client = new S3Client({ region: yourRegionHere });

const createMultipartUploadCommand = new CreateMultipartUploadCommand({
    Bucket: yourBucketNameHere,
    Key: yourNewS3KeyHere,
});

const startUploadResponse = await client.send(createMultipartUploadCommand);

const uploadId = startUploadResponse.UploadId;

This instructs S3 to start an upload. The response will return an uploadId, which will be used in generating presigned URLs in the next step to tie them all together.

NOTE: This CreateMultipartUploadCommand is where you set the ACL for the uploaded object, amongst other things. See the AWS-SDK documentation for more details.

Step 2: Generate Presigned URLs

This should be run on the server side in whatever back end node framework you're using.

import { getSignedUrl } from '@aws-sdk/s3-request-presigner';
import { UploadPartCommand } from '@aws-sdk/client-s3';

...

// Calculate the number of parts to split the file into.
// I am going to split the file into ~10mb chunks.
// AWS requires it to be above 5mb, for all but the last part.
const numberOfParts = Math.ceil(fileSize / 10000000);

let presignedUrls: string[] = [];

for (let i = 0; i < numberOfParts; i++) {
    const presignedUrl = await getSignedUrl(
        client,
        new UploadPartCommand({
            Bucket: bucketName,
            Key: s3Key,
            UploadId: uploadId,
            PartNumber: i + 1,
        }),
        {},
    );

    presignedUrls.push(presignedUrl);
}

This will generate a presigned URL for each chunk of the file to upload.

These will need to be returned to the client to be used to upload the file chunk by chunk.

Step 3: Split your file and use presigned URLs to upload

This part should be run on the client side.

async function uploadPart(
    fileChunk: Blob,
    presignedUrl: string,
    partNo: number,
): Promise<ApiResponse<CompletedPart>> {
    const uploadResponse = await fetch(presignedUrl, {
        method: 'PUT',
        body: fileChunk,
    });

    return { value: { ETag: uploadResponse.headers.get('ETag') ?? '', PartNo: partNo } };
}

...

const numberOfParts = Math.ceil(file.size / 10000000);

const uploadsArray: Promise<ApiResponse<CompletedPart>>[] = [];

for (let i = 0; i < numberOfParts; i++) {
    const start = i * 10000000;
    const end = Math.min(start + 10000000, file.size);
    const blob = file.slice(start, end);

    uploadsArray.push(uploadPart(blob, presignedUrls[i], i + 1));
}

const uploadResponses = await Promise.all(uploadsArray);

This splits the file up into ~10mb chunks (you can split files into smaller or larger chunks to your preferences) and then uses each presigned URL to upload it to S3.

Note that I have collected the ETag and PartNo from each upload because we will need to pass these to the server to use when completing the multipart upload in the next step.

Note: Make sure that the presigned URLs are used in correct part number order otherwise S3 will not be able to construct the file properly.

Aside: CORS Settings for AWS S3

The ETag, which is returned from the presigned URL PUT requests as a header, is required to complete the multipart upload.

Your browser will probably block access to the header due to CORS. If this is the case, you will need to expose it explicitly in your S3 CORS settings, using the ExposeHeaders property.

In the AWS console, these are found on the permissions tab, and will look something like this:

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET",
            "PUT",
            "POST"
        ],
        "AllowedOrigins": [
            ...
        ],
        "ExposeHeaders": [
            "ETag"
        ]
    }
]

NOTE: You may also need to add the PUT method in AllowedMethods as above.

Step 4: Complete the multipart upload

This part should be run on the server side.

import {
    S3Client,
    CompleteMultipartUploadCommand,
} from '@aws-sdk/client-s3';

...

const client = new S3Client({ region: yourRegionHere });

const completeUploadInput = {
    Key: s3Key,
    Bucket: bucketName,
    UploadId: uploadId,
    MultipartUpload: {
        Parts: completedParts.map((x) => {
            return { ETag: x.ETag, PartNumber: x.PartNo };
        }),
    },
};

const completeMultipartUploadCommand = new CompleteMultipartUploadCommand(completeUploadInput);

await client.send(completeMultipartUploadCommand);

Once you have uploaded the file from the client side using all of your presigned URLs, you'll need to complete the command on the server side.

You'll need the uploadId returned from the CreateMultipartUploadCommand request in part 1, and you'll need the part numbers and corresponding ETag values from all of the uploaded parts.

The presigned URL upload happened on the client side so you will need to send the ETag/PartNumber pairs from the client so that you can complete the upload.

With the command finished, you're done! The file should be available in your S3 bucket.

Conclusion

You should now have a working multipart file upload using presigned URLs.

Hopefully this saves somebody the pain of trawling through the leviathan of AWS-SDK documentation trying to find the specific types and functions required to perform this multipart upload!

DEV Community: Daniel Griffiths

Creating a Custom UI for Ory Cloud with React/Nextjs

Why am I writing this? Why not use the ory documentation?

Setup

Other packages I investigated

Useful example projects

Overview of process

1. Get the custom UI and ory onto the same domain

2. Flow IDs

3. Interpret the flow object

Steps

1. Set up ory tunnel

2. Environment setup

3. Create basic custom login page

4. Ory console config and finishing up

Next Steps

More Styling

More Pages

Production Deployment

Debugging Tips

Conclusion

How to connect to an Azure-hosted managed identities postgres server from a node app using the Prisma ORM

Introduction

The Problem

Azure Managed Identities

Prisma ORM

Potential Solutions

The Solution

Environment

Optional - Connecting Manually

Optional - Running initial migrations from the node/prisma app

Custom Prisma Client Generator

Conclusion

Mocking with Jest and typescript - a cheatsheet

My Environment

Mocking Imports

Importing functions

Mocking a named exported function from a module

Mocking the default function returned from a module

Importing objects

Mocking default objects with no methods

Mocking named export objects without methods

Mocking an object with methods

Bonus: Mocking methods on an object passed directly to a test function/class as a parameter

Mocking global functions

Conclusion

Upload large files to AWS S3 using Multipart upload and presigned URLs

Why presigned URLs?

Prerequisites

Steps

Step 1: Start a multipart upload

Step 2: Generate Presigned URLs

Step 3: Split your file and use presigned URLs to upload

Aside: CORS Settings for AWS S3

Step 4: Complete the multipart upload

Conclusion