DEV Community: Thai Pangsakulyanont

A survey of JWT storage locations in client-side app SDKs

Thai Pangsakulyanont — Sat, 10 Sep 2022 09:52:16 +0000

The question about where to store JWTs (and access tokens in general) is a common one where there seems to be no consensus among developers.¹

Some believe that JWTs should never ever be stored in localStorage, while others believe that it’s okay to store them there. Each side has their own reasonings and explanations for their beliefs. It has been discussed at length, and in my opinion, to the point of unproductivity.²

Rather than adding to this never-ending debate, let’s instead take a look at popular SDKs to see how they are helping single page applications (SPA) store their JWTs. Here we go!

Auth0

For SPAs, Auth0 does not store a JWT in client-side storage at all.
Instead, Auth0 SDK embeds a hidden <iframe> which performs the Authorization Code Flow with Proof Key for Code Exchange (PKCE) in conjection with Silent Authentication. This flow is performed every time the SPA is loaded, so the JWT is not persisted at any storage location. Additionally, token requests are performed in Web Workers, providing additional layer of security.

The signed in state is maintained inside the <iframe> using HttpOnly cookies. None of the cookies are JWT.
After the authentication flow is complete, then the <iframe> is removed from the DOM.
Safari with Intelligent Tracking Protection blocks third-party cookies, which can break the Silent authentication flow. To work around this, you can set up custom domains for Auth0 (requires a paid plan) so that Auth0’s session cookies become a first-party one. Alternatively, the Refresh Token Rotation functionality can be used, but then your signed-in state would be lost when you refresh the page, unless you opt to store the tokens in localStorage.

AWS Amplify

ID tokens, access tokens, and refresh tokens are stored in localStorage
They are all JWTs. You know because they start with eyJ. They are RS256 signed.

Firebase Auth

Firebase Auth stores the access token and refresh tokens in IndexedDB by default.
The accessToken is a RS256-signed JWT. It also functions as an ID token (and are referred to as such in the documentation). Using RS256 JWT is convenient because third-party apps can verify the ID token using Firebase’s public keys without having to share any secret keys.
Meanwhile, the refresh token is an opaque string.

Supabase

Supabase stores the access token and refresh token in localStorage.
The access token is a HS256-signed JWT, while the refresh token is an opaque string.

Conclusions

In conclusion, different auth SDKs implemented different default behaviors for storing tokens.

It is important to consider the context around choices made by these SDKs. Just because a few popular SDKs store tokens in localStorage doesn’t automatically mean that doing the same in our custom implementations will give us a secure authentication scheme; we also have to look at how these SDKs help developers protect the tokens from misuse.

If you have more examples to add, feel free to comment!

Please ignore my ramblings.
Whenever the topic of token storage is tangentially touched on, it seems someone has to proclaim “never store JWTs in localStorage” and derail the conversation. Happens so frequently, and it is fascinating to see the length people will sometimes go to to prove their point. When I pointed out about our defenses against XSS and untrusted assets, I got a reply “but the user may install a malicious software that can read storage. Here I created an extension that reads the localStorage of the website. See? localStorage bad.”
↩

A workflow to generate Git patches for auto-fixable issues

Thai Pangsakulyanont — Mon, 06 Dec 2021 15:08:14 +0000

Don’t you feel frustrated when you make a trivial change in your codebase, like editing some text using the web editor…:

…or bumping some dependencies…:

…only to see your CI build failing because of reasons like these?:

Prettier doesn’t like it that you don’t wrap lines at 80 characters:

You forgot to update your test snapshots:

You didn't run yarn to update the lockfile:

Other trivially fixable errors:

I get very annoyed when issues like this happens. It’s important to put in checks to keep things tidy and ensure coding style is used consistently. But perhaps we can make it a bit less annoying…

I was once on a large codebase where running the linter and the tests takes 5 minutes. When I make simple changes that breaks any formatting or any snapshot, I lose a lot of time: 5 minutes to know that there’s a problem. 5 minutes to run eslint --fix or jest -u and commit+push the changes. And 5 more minutes to verify the fix on CI.

While it’s important to speed up the CI builds, why not also let the CI generate a patch file that you can instantly apply on your branch?

My Workflow

(Before) Instead of simply running checks and failing the build…:

- run: yarn --frozen-lockfile
- run: yarn lint
- run: yarn test
- run: yarn prettier --check .

(After) …we let GitHub Actions try to fix the auto-fixable problems…:

- run: yarn --no-immutable
- run: yarn lint --fix
- run: yarn test --updateSnapshot
- run: yarn prettier --write .

…then we stage the changed files and finally use the Patch Generator action (newly created for this hackathon) to generate a patch command:

- run: git add --update
- uses: dtinth/patch-generator-action@v1

When this workflow is run and there is any auto-fixable changes, Patch Generator will generate a shell command that you paste into your local machine to instantly apply the required changes. It also works with binary files. And if the changes are too big, you can download the patch file from the build artifacts and apply using the git apply command.

Finally, you can also review the diff from the actions log to see what would happen when you run the above command.

Submission Category:

Maintainer Must-Haves

Yaml File or Link to Code

Example project (example PR, workflow file)

dtinth / patch-generator-action-demo

Demo project for Patch Generator action.

Patch Generator Action (action source, marketplace)

dtinth / patch-generator-action

Frustrated by builds failing due to trivial, auto-fixable issues? Use this action to generate a shell command to apply changes.

Additional Resources / Info

patch-generator-action is created as a composite action. This approach has some benefits over JavaScript actions:

People can fork and modify the action without having to install any build tool or go through any build steps. Development for this action mostly happen in github.dev without any other build tooling.
Since composite actions uses the same syntax as a workflow, people can also yoink the action code, and put them directly in their workflow files, if they so choose.

I am using the workflow in these open source projects:

Bemuse (Rush + markdown-toc + ESLint + Prettier; workflow file)

bemusic / bemuse

⬤▗▚▚▚ Web-based online rhythm action game. Based on HTML5 technologies, React, Redux and Pixi.js.

Fresh App Factory (Yarn + Prettier; workflow file)

fresh-app / factory

We produce freshly-baked apps every midnight

Patch Generator Action (Itself!) (Prettier; workflow file)

dtinth / patch-generator-action

Frustrated by builds failing due to trivial, auto-fixable issues? Use this action to generate a shell command to apply changes.

The action is released under the Unlicense, i.e., into the public domain.

Embracing gradual typing — Strategies for adopting TypeScript into a large project (Talk)

Thai Pangsakulyanont — Thu, 14 Jan 2021 11:26:45 +0000

There are many challenges when trying to adopt TypeScript into your JavaScript project. Your project may already have tons of untyped files, changing your build system can sound risky, and your colleages may ask if the cost of investing in migrating all the code to TypeScript would be worth the effort or not.

Some may argue that they wouldn’t need types because they already have tests. Some may question whether the benefit would really outweigh the TypeScript tax. Some may have had bad experience with earlier versions of TypeScript before. And there are many outdated opinion pieces everywhere.

But adopting TypeScript doesn’t have to be a big, all-or-none effort.

There are strategies for incrementally introducing pieces and bits of TypeScript into your JavaScript project, each little step immediately improving the developer experience, without having to install extra dependencies or make any changes to the build system.

This is what I discuss about in this talk. It also contains real-world examples which is kinda hard to convey just in text.

Topics discussed

How you may already be using TypeScript in your JavaScript project.
TypeScript the language, the compiler, and the language service.
Using JSDoc to improve type inference, code completions, and IntelliSense.
Configuring jsconfig.json for improved code actions and automatic refactoring.
Using // @ts-check to type-check JavaScript files (with examples on dealing with a few type-checking errors).
Enabling checkJs to type-check JavaScript files project-wide.
Creating a .d.ts file next to a JavaScript file to keep the .js file unmodified.
Creating a global .d.ts file to declare modules and global variables.
Discussion on strategies for improving developer productivity, improving code documentation, and reducing chance of runtime errors.

Note: The talk is in Thai language but I added English captions, and all slides are in English.

Hope you find it useful, and thanks for watching! Also, please consider subscribing to my YouTube channel for more content.

A local file storage for the web and interopearability layer for web-based apps (submission)

Thai Pangsakulyanont — Sun, 10 Jan 2021 17:11:23 +0000

What I built

I built tmp.spacet.me, a web-based local file storage application. Basically, you can put files into it, and you can get files out of it. It aims to support every possible methods that browsers allow web apps to work with files.

It also comes with an extensions system. Users can add extensions to enhance the functionalities of the app. The goal is to improve operability between web-based applications that work with files.

For example, the tmp-webrtc extension lets me send files from one device to another using peer-to-peer technology WebRTC.

The tmp-photopea extension lets me edit image files in Photopea.

Users can build their own extensions to suit their needs.

For example, I built an extension to upload images to my static file hosting.

Although tmp.spacet.me is built using React and Next.js, this is just an implementation detail and extension authors don’t need to know any React. That’s because extensions run on their own page and communicate with tmp.spacet.me via the postMessage API only.

Category Submission

Random Roulette

App Link

https://tmp.spacet.me/

Screenshots

Description

A web-based local file storage. You can put files into it, and you can get files out of it. More functionalities can be added through extensions.

Link to Source Code

dtinth / tmp

Web-based local storage

tmp.spacet.me

tmp.spacet.me is a web-based local file storage application. Basically, you can put files into it, and you can get files out of it. It aims to support every possible methods that browsers allow web apps to work with files.

It also comes with an extensions system. Users can add extensions to enhance the functionalities of the app.

For example, the tmp-webrtc extension lets me send files from one device to another using peer-to-peer technology WebRTC.

The tmp-photopea extension lets me edit image files in Photopea.

Users can build their own extensions to suit their needs.

For example, I built an extension to upload images to my static file hosting.

For more information, including the Extensions API, take a look at the documentation.

Devlog

This project is participating in the DigitalOcean App Platform Hackathon on DEV and is deployed to DigitalOcean® App Platform as a static site.

Part…

View on GitHub

dtinth/tmp — the main app
dtinth/tmp-webrtc — extension to send/receive files over WebRTC
dtinth/tmp-photopea — extension to edit pictures in Photopea
dtinth/tmp-uploader — extension to let me upload pictures to my static files hosting
dtinth/tmp-dtinth — extension for my personal use cases

Permissive License

All code is MIT Licensed

Background

There are so many great web-based tools. From Markdown editors to file sharing services to diagramming tool to design tool to image editor and compressor to voice and screen recorder to myriad of cloud storage services, etc.

Many of these tools work with files. But they tend to be its own silo and do not interoperate with other tools.

There has been attempts to solve this from the web platform side. There was an experimental Web Intents API which failed. More recently, there are also the Web Share API and the Web Share Target API which integrates natively with the system’s Share dialog. Unfortunately Desktop devices don’t have them and so it’s only available on Android right now.

So, as I become more reliant on web-based tools, I want to try my take at a userland solution. So the missing piece, I think, is a central hub, where files can be sent to, which would then be forwarded to other web-based app or saved to disk. I want it to have an extension system, so anyone can build more integrations without having to modify the main app. Furthermore, deeper integrations with existing web-based apps can be implemented via browser extensions.

How I built it

For the main app, tmp.spacet.me, I used DigitalOcean App Platform to host the app, which is a static web application. The main application is built using React and Next.js. Deployment to DigitalOcean App Platform is very straightforward and I’m impressed by how easy it is to set up. I’m looking forward to support for deployment previews in the future.

For the extension system, when the extension URL is entered, the main app fetches the manifest file, which contains the information about the extension, as well as which file types can be handled. Then, when the extension is activated, it opens a separate browser window and communicate with the main app via a JSON-RPC-based protocol. This gave me opportunities to put cross-site messaging and micro-frontend concepts into practice.

For the tmp-webrtc extension, at first I wanted to create a backend service to implement peer discovery. That would also give me an opportunity to try out DigitalOcean’s paid services (like running backend apps and using a managed database). Unfortunately due to time constraints I didn’t get around to doing that and used the P2PT library for peer discovery instead. P2PT uses public WebTorrent trackers as a WebRTC signaling server, and so no backend services have to be deployed. So it ended up being another static app. This is my first time using P2PT and WebRTC for file transfers though, so I still think I learned a lot.

I really like that DigitalOcean’s App Platform makes setting up CORS very straightforward (can be set up via the console), while Netlify, Vercel requires creating a configuration file. Having CORS is crucial for the extension system to work, because tmp.spacet.me needs to fetch the manifest file to discover the extension's functionalities.

The tmp-webrtc extension is built using Vue 3 and Vite. I have never used Vite before, so that’s another thing I learned. By the way, I don’t like running commands to generate new projects, so I took the opportunity to shave that yak, and created the Fresh App Factory.

I also used other other cloud services other than DigialOcean. The documentation site is just a Jekyll site hosted on GitHub Pages, which I chose for simplicity. I like that DigitalOcean App Platform allows multiple static apps (or “components”) to be hosted on the same domain, but I could not get Jekyll to work on it.

The application’s UI is not polished at all and could use a lot of improvements. But I think it’s good enough for a proof-of-concept. Since I started building this, I have been using it a lot in my own personal workflow. Sending pictures and videos between my 4 devices, now I just use tmp.spacet.me.

Some areas for future improvements include:

Improving the user experience, accessibility and performance.
Allowing files to be stored temporarily in the in-memory storage first before committing to PouchDB.
Allowing other web apps to directly postMessage to tmp.spacet.me (without an extension), reducing the irony.

I hope you find the tool useful, and thanks for reading!

tmp.spacet.me devlog part 4

Thai Pangsakulyanont — Fri, 08 Jan 2021 15:14:11 +0000

I implemented a few more integrations.

Sending and receiving files via WebRTC. I used P2PT for peer discovery and simple-peer-files for file transfer. They are based on the simple-peer library. I’ve never used them, and a hackathon is a great time to try out things I’ve never tried before.

After adding the extension, the “New item” button will have a option to receive files via WebRTC. And every file will also has a new option to send them over WebRTC.

On first use, tmp-webrtc must be configured with a unique channel name. While active, each “sender” will distribute the file to every receiver on the same channel. Also, a single receiver can receive multiple files at once.

This makes it easier for me to beam files between my Windows, Mac, iPadOS and Android devices.

While tmp.spacet.me is built using Next.js, tmp-webrtc is built using Vue 3 with Vite, mainly because I’ve never used Vite before, so why not! I don’t like running commands to generate a new project though, so I shaved that yak and created the Fresh App Factory.

Then I deployed this to DigitalOcean App Platform as another app. I got hit by CORS issue, but thankfully DigitalOcean App Platform has the CORS setting right inside the tool. It is very straightforward to configure (unlike S3 where I had to write a JSON configuration).

Photopea integration: Thanks to Photopea's API I can now edit images imported to tmp.spacet.me in Photopea. The whole extension is a single index.html file.

Improved extensions UI: It’s now possible to delete added extensions 😂.

With only two days left I think what I have now is good enough for a proof-of-concept, although I think it’s not polished at all. I will spend the remaining two days on documentation and writing up the submission post.

Freshly-baked apps every midnight

Thai Pangsakulyanont — Wed, 06 Jan 2021 20:26:08 +0000

I hate running commands to generate new projects because it is relatively cumbersome compared to jumping into an existing project.

Whenever I want to work on an existing project, I just jump right in and begin developing it, either on my local machine, or using many cloud-based development tool. Codespaces, Gitpod, CodeSandbox, etc. which can launch a development environment right from a GitHub repository.

On the other hand, when generating projects using a CLI, there is no repository to begin with. So I must start from my machine. Furthermore, I had to install dependencies twice — once for the project generator, and once more for the project itself.

So I created the Fresh App Factory which in turn creates self-updating project templates. Every midnight UTC, it runs popular project scaffolding commands and pushes the resulting project to GitHub repositories. All of this is powered by GitHub Actions.

fresh-app / factory

We produce freshly-baked apps every midnight

factory

This repository generates various fresh apps every midnight (UTC time).

Why?

Instead of having to run a script to generate a new project each time, you can just fork the templates and begin coding.

Use Codespaces, Gitpod or CodeSandbox to work on the project right away.
Unlike many boilerplates, our fresh apps are regenerated daily, so you get up-to-date dependencies by the time you clone them.

View on GitHub

React

Create React App

I initially experimented with this idea since late 2019, so you can take a look at how a freshly-generated React app's README file evolves over the years.

Vite

Next.js

Vue

Vanilla

https://github.com/fresh-app/fresh-vite-app

etc.

Further template projects may be added in the future. Check out https://github.com/fresh-app.

tmp.spacet.me devlog part 3

Thai Pangsakulyanont — Tue, 05 Jan 2021 20:55:46 +0000

I added support for external extensions. The settings panel now has an area where extension URLs can be added.

The first external extension I will write will be for uploading files to a custom endpoint. This helps make it easier for me to upload files to my static files hosting.

I put in the extension URL: https://raw.githubusercontent.com/dtinth/tmp-uploader/master/. This effectively installs the extension. The "Uploader" menu now shows up in the files list.

When I click on it, it opens a new browser window and uploads the file to my static files hosting. Then it returns the URL to the image, ready to be copied.

Under the hood

Extension installation

When I put in the extension's URL, tmp.spacet.me goes ahead and fetches manifest file by appending /tmp-manifest.json to the URL. The JSON looks like this:

{
  "name": "dtinth's uploader",
  "description": "Upload files to cloud storage",
  "contributes": {
    "integrations": {
      "uploader": {
        "title": "Uploader",
        "accept": ["*"],
        "url": "https://tmp-uploader.glitch.me/"
      }
    }
  }
}

This caused the "Uploader" to appear in the file's menu. And when clicked, tmp will launch the URL specified.

Uploading process

The first time I go to https://tmp-uploader.glitch.me/, I am shown the Configuration screen, and asked to enter an Upload URL request endpoint. This makes the tool generic and can theoretically but with any host that implements the specified interface.

Now having to configure the URL on every computer may feel cumbersome, but I normally store credentialed URLs like these in my password manager, I know exactly where to recall them should I ever need to.

Now, when a file will be uploaded, the configured endpoint will be called with the filename and MIME type. It returns a JSON that looks like this:

{
  "uploadUrl": "https://s3.ap-southeast-1.amazonaws.com/static.dt.in.th/uploads/2021/01/05/tmp-uploader-result.png?AWSAccessKeyId=...",
  "downloadUrl": "https://static.dt.in.th/uploads/2021/01/05/tmp-uploader-result.png"
}

Then the tmp-uploader will make a PUT request to uploadUrl. Once done the downloadUrl is displayed.

Endpoint implementation

My uploaded files are hosted on Amazon S3. So I created a Lambda function according to the above specification. For uploadUrl, it returns a signed URL that can be used to upload a file to S3 directly from the web browser.

const AWS = require('aws-sdk')
AWS.config.update({ region: process.env.AWS_REGION })
const s3 = new AWS.S3()

exports.handler = async (event) => {
  if (event.queryStringParameters.code !== process.env.API_KEY) {
    return { statusCode: 401, body: 'Unauthorized' }
  }
  const date = new Date().toJSON().slice(0, 10).replace(/\W+/g, '/')
  const key = `uploads/${date}/${event.queryStringParameters.filename}`
  const s3Params = {
    Bucket: 'static.dt.in.th',
    Key: key,
    Expires: 3600,
    ContentType: event.queryStringParameters.type,
  }
  const uploadUrl = await s3.getSignedUrlPromise('putObject', s3Params)
  const downloadUrl = `https://static.dt.in.th/${key}`
  return JSON.stringify({ uploadUrl, downloadUrl })
}

I need to grant the Lambda function essays to the S3 bucket by attaching this policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::static.dt.in.th/*"
    }
  ]
}

and finally I need to allow file uploads from the browser:

[
  {
    "AllowedHeaders": ["*"],
    "AllowedMethods": ["GET", "PUT"],
    "AllowedOrigins": ["https://tmp-uploader.glitch.me"],
    "ExposeHeaders": []
  }
]

Other things done

Also implemented rudimentary Rename functionality.

tmp.spacet.me devlog part 2

Thai Pangsakulyanont — Fri, 01 Jan 2021 09:03:47 +0000

Now that the core is usable, I want to tackle a first use case — opening a file in an external viewer.

To simplify this task, for now I will use a hardcoded list of external integrations. Making this list customizable will come later.

postMessage protocol: The messaging protocol I decided to use is based on JSON-RPC specification, following how Microsoft also uses it in its Language Server Protocol Specification.

Results

I implemented integrations for these:

json.spacet.me - JSON viewer
vdo.glitch.me - Video player

How it works: When opening a file with an external viewer, tmp.spacet.me opens up a new window, passing along a session ID. Once the viewer loads and detects the session ID, it makes a JSON-RPC call to the opener to obtain the file contents.

Implementation and refactoring

I started by doing the simplest thing that could possibly work and hardcoded the postMessage handling code. Here the code is infested with type assertions just to make TypeScript compiler happy. When experimenting, I think this is a good thing to do, just don't forget to clean it up later, which is coming up right next.

You don't need to understand the whole code here, just look at the code around the comments:

window.addEventListener('message', async (e) => {
  const fromWindow = (e.source as unknown) as Window

  // Check for a method call.
  if (e.data.method === 'tmp/getOpenedFile') {
    // In this block, `e.data` is `any`, so no IntelliSense.

    // (hovertip) const sessionId: any
    const sessionId = e.data.params.sessionId
    const session = sessionStorage[`session:${sessionId}`]
    if (!session) return
    const sessionState = JSON.parse(session)
    const db = getFilesDatabase()
    const doc = await db.get(sessionState.openedFile, {
      binary: true,
      attachments: true,
    })
    fromWindow.postMessage(
      // Send a reply.
      {
        // Right now this object can be arbitrary payload;
        // there's currently no type-checking here.
        // So I might introduce a bug at some point...
        jsonrpc: '2.0',
        id: e.data.id,
        result: {
          blob: (doc._attachments.blob as any).data,
          file: {
            _rev: doc._rev,
            _id: doc._id,
            name: doc.name,
            type: doc.type,
          },
        },
      },
      e.origin
    )
  }
})

Now while this works, I can see that this way of writing code can cause trouble soon. Right now to answer these questions you would need to read how the code is implemented, because it has never been explicitly stated, nor documented, in the code base:

Which methods are available?
What kind of parameters do these methods take?
What do the results look like for each method?

This makes the interface prone to break, and I don't want that. I think in this case static typing could help here. So I went ahead and created a TypeScript interface as a way to document the RPC interface. I wrote it in a way that I want to read it in the future.

interface RpcInterface extends JsonRpcDefinition {
  'tmp/getOpenedFile': {
    params: {
      sessionId: string
    }
    result: {
      blob: Blob
      file: {
        _rev: string
        _id: string
        name: string
        type: string
      }
    }
  }
}

Now, the message handler looks like this:

const rpc = new JsonRpcPayloadChecker<RpcInterface>()

window.addEventListener('message', async (e) => {
  const fromWindow = (e.source as unknown) as Window
  // Changed
  if (rpc.isMethodCall(e.data, 'tmp/getOpenedFile')) {
    // In this block, `e.data.params` shall have type
    // `RpcInterface['tmp/getOpenedFile']` which is `{ sessionId: string }`

    // (hovertip) const sessionId: string
    const sessionId = e.data.params.sessionId
    const session = sessionStorage[`session:${sessionId}`]
    if (!session) return
    const sessionState = JSON.parse(session)
    const db = getFilesDatabase()
    const doc = await db.get(sessionState.openedFile, {
      binary: true,
      attachments: true,
    })
    fromWindow.postMessage(
      // Changed
      rpc.replyResult(e.data, {
        // In here, the type should flow to this object.
        // So any deviations from the declared interface
        // would cause a type-checking error.
        blob: (doc._attachments.blob as any).data,
        file: {
          _rev: doc._rev,
          _id: doc._id,
          name: doc.name,
          type: doc.type,
        },
      }),
      e.origin
    )
  }
})

To make the type flow, here is the rest of that code. This is, IMO, one of the very few places where I would write advanced types. IMO advanced types hurt the readability of code, so it is best used in an isolated place, where it will make types flow better to the code that uses it. TypeScript tax is a thing, but let's manage it instead of avoiding it.

A litmus test I use for when to use advanced types is this: Does it reduce the amount of type annotations in other files? Don't let advanced types infect the rest of your codebase!

export class JsonRpcPayloadChecker<T extends JsonRpcDefinition> {
  isMethodCall<K extends keyof T>(
    message: unknown,
    method: K
  ): message is JsonRpcMethodCall<K, T[K]['params']> {
    return isJsonRpcMethodCall(message) && message.method === method
  }

  replyResult<K extends keyof T>(
    message: JsonRpcMethodCall<K, any>,
    result: T[K]['result']
  ) {
    return {
      jsonrpc: '2.0',
      id: message.id,
      result: result,
    }
  }
}

export interface JsonRpcDefinition {
  [methodName: string]: {
    params: any
    result?: any
  }
}

export interface JsonRpcMethodCall<MethodName, MethodParams> {
  id: string
  method: MethodName
  params: MethodParams
}

function isJsonRpcMethodCall(
  message: any
): message is { method: string; params: any } {
  return message && message.method
}

Let's deploy the simplest URL redirection service to Netlify!

Thai Pangsakulyanont — Tue, 29 Dec 2020 11:49:34 +0000

Sometimes it's a good idea to post links under your own domain, so that you can change the link's target when needed¹.

For example, I have a Ko-Fi page at https://ko-fi.com/dtinth but I never link to that URL directly; I use http://link.dt.in.th/coffee instead. Should I ever decide to use something else², I only need to change the link destination.

One simple, low-code way to accomplish this is use Netlify's redirect feature.

Create a GitHub repo and create a file public/_redirects:

 /youtube   https://www.youtube.com/channel/UClKPjyxFSkk_dPg6YzN0Miw/   302
 /coffee    https://ko-fi.com/dtinth                                    302

Create a Netlify site linking to the GitHub repo and set up your domain.
There is no step 3.

The _redirects file has a simple, machine-and-human-readable, plain-text format. To add or change links, just update the file on GitHub. I find this approach powerful because I can also update this file programmatically using GitHub's API, and teams can collaborate on this file like how they collaborate on code. One downside is that this approach doesn't track how many people used the link, we you'd have to track from the destination instead.

Some URL shortener services doesn't allow you to change the link's destination unless you pay them money ↩
like Patreon or GitHub Sponsors (the latter of which is not available in my country yet) ↩

tmp.spacet.me devlog part 1

Thai Pangsakulyanont — Sun, 27 Dec 2020 15:04:45 +0000

This is part of DigitalOcean App Platform Hackathon. The project I want to build is a web-based local file storage.

Why? Nowadays, there are so many web-based tools that work with files, such as:

Squoosh image compressor
Photopea photo editor
gifcap screen recorder
Diagrams.net diagram and flowchart maker
vox.spacet.me voice recorder (I made this one)
json.spacet.me JSON viewer (I made this one too)
instant.io streaming file transfer over WebTorrent
ShareDrop file transfer over WebRTC
StackEdit and Dillinger Markdown editor
Carbon code image generator
other specialized tools that I create for specific situations

Now comes my pain point: When I want to use multiple apps together, I have to go through a lot of Download-then-Upload experience, and thus my Downloads folder fills up with many temporary files.

Many apps are inconsistent in how they handle input/output. To get data into a web app, you can use the usual File open dialog (via <input type="file">), the Drag and Drop API, the Clipboard API, and the Share Target API. To get data out, there's <a>'s download attribute, DownloadURL DataTransfer type for dragging files out of the browser, the Clipboard API, the Web Share API, and the classic "Save Link As", "Save Image As" and "Copy Image" menu items.

Most apps support only a subset of these APIs. Some apps also have integrations with cloud storage services like Google Drive, but many don't. Paul Kinlan (2017), Web sites as unintended silos: The problem with getting data in and out of the web client is an interesting read.

Now the web has the postMessage API that lets web applications throw data around among different websites. So, I'm pondering about the idea of having a web-based portal, a hub of sort, that takes care of importing/exporting files using all the available Web APIs...

...and integrates with all the different apps.

It should be extensible. Of course I'm lazy and I won't be integrating all the different apps myself. Instead, integrations will be provided through an extensions system. (In the above picture, the text in blue are to be implemented as an extension rather than as a core feature.)

If all goes according to the plan, extensions will be HTML pages and communicate with this app through the postMessage API. This way new extensions can be written using any tool, and added to the app without having to touch the main app. This is a nice opportunity to learn about "micro-frontends."

Deployment structure: The main app will be deployed as a Static Site application, while extensions may be deployed as separate apps, and some of them might require a database. This is also an opportunity to try out App Platform services such as DigitalOcean Managed Databases.

Project name: This is one of the hardest thing in computer science. I intended it to be a place where I temporarily put files in. For the lack of better name, I just called it "tmp".

Project setup: I applied for a DigitalOcean credit, created a Next.js static app, set up Tailwind, TypeScript and next-pwa. I deployed the app to DigitalOcean App Platform and it just works (except the part where I waited for the spinner to finish. By the way everyone, please don't add a spinner if you will not also automatically refresh it.)

Implementating the core features: I then implemented the basic import/export functionalities using various Browser APIs and npm packages:

File data and all other data will be stored inside IndexedDB, through the help of PouchDB. Querying data from the local database in the React app is done using React Query.

After a few days of coding, most of the core features are implemented.
Now, for example, I can share photos from Google Photos directly to tmp.
Within tmp, I can view the image (using the browser's built-in image viewer) and share it to other apps.

Right now the UI is very unpolished, and the rename functionality has not yet been implemented. But there are more important stuff to do first. The elephant in the room -- postMessage-based integrations.

Open source contributions: Along the way I sent some quick PRs:

shadowwalker/next-pwa#132 improves error messages

Next up: I will probably be implementing a first iteration of a postMessage-based integration system. It will integrate with an external tool I have already created. Meanwhile, the source code is on GitHub at dtinth/tmp.

Test your frontend knowledge with this little fun quiz

Thai Pangsakulyanont — Fri, 20 Nov 2020 17:56:40 +0000

In February 2019, I created this little quiz for a Code in the Dark event¹ in Chiang Mai, Thailand. Now I’m making this quiz available online.

This quiz tests for general knowledge of HTML and CSS, as well as topics related to frontend development such as colors, typography and animation. It does not include JavaScript though.

It’s just for fun and is not indicative of skill (even skilled developers may get only half of them correct) but rather experience².

Here is it (direct link to quiz):

I created this quiz while I was preparing to run the 3rd Code in the Dark event in Thailand.

I recalled that in the past events, many people would register as an observer (not a contestant), even though I see them as very good developers. When I asked why, some friends said that they are not confident enough to compete.

So in the 3rd event I changed the registration process. Now everyone registered as a participant, and before each round, we’d run a quiz and offer the top scorers a chance to be a contestant in that round.

This way, the truly skilled and experienced would get a better chance to compete, regardless of their self-confidence. That’s also why the quiz is separated into 3 rounds — people who did not make it in the first round are given 2 more chances.

Anyways, hope you enjoyed it, and thanks for reading!

It is a competition where contestants are asked to create a webpage according to the design within 15 minutes. Contestants must stay in text editor the whole time and no preview is allowed. ↩
I wouldn’t expect anyone to memorize all the little things. However, with experience, the chance of recalling obscure details increase. It’s like how one may have been doing web design and development for so long that at one point they realized they now posses the ability to mix RGB colors in their head. Anyways, this quiz would be a very bad way to assess someone’s web development skills. ↩

Building a personal but multi-tenant web page screenshotting service with Puppeteer and Vercel

Thai Pangsakulyanont — Tue, 03 Nov 2020 17:56:41 +0000

In the past 2 years I found myself having to install and configure Puppeteer to capture webpage screenshots on so many occasions.

So I thought it would be great to have a generic API that captures webpage screenshots that I can reuse across multiple projects. The existence of serverless platforms like Vercel made it all the more easier to do this, even for personal projects.

The need for screenshotting web pages

I regularly find need to programmatically take screenshots of web pages.

In each of these use cases I installed Puppeteer and wrote similar code: Go to the web page, take a screenshot, output the image. But Puppeteer is quite a heavy dependency, weighting over 100 MB in node_modules.

In cases where the code is used in dynamic sites, I would had to set up a Google Cloud function or an AWS Lambda function for that use cases.

Wouldn’t it be great if, instead of setting up Puppeteer every time, there is an API that I can immediately use? Well, there is a plenty of ~~existing~~ offerings, but most of them are paid and the free ones went down. Even some of the paid ones went down (the links that are struck out are now dead).

Since I wanted to re-use it across multiple projects, spanning multiple years to come, I want some degree of control. The service should:

Run on my own domain name. I don't want to have to go through all my projects and migrate to a new service, just because the old service is sunsetted.
Be affordable or free. It’s for personal use and is non-commercial. I don’t want to spend too much money on it.
Personal yet multi-tenant. I may use it on a project that is shared with others. In a rare case that I need to revoke an access to one project, it should not disrupt other projects. Therefore, it should support multiple keys.
Secure. Others should not be able to use the service to screenshot arbitrary web pages without my permission.
Single-shot API. Service consumers should be able to construct the image URL without having to make any extra API requests.

Introducing personal-puppeteer

So this is what I created. Here’s how it works:

First, let’s say I want to generate a social card image for the URL at https://capture.the.spacet.me/. As an API consumer, I would:

Generate a request.
Cryptographically-sign the request into a JWT and construct an image URL.
Send the image URL to client (in a <meta property="og:image"> tag).

The browser would then make a request to the service, which would, on request, take a screenshot
…and return the image back to the browser.

The service maintains a list of tenants which are allowed to use the service. This allows the service to be reused in multiple projects without them having to share the same secret key.

Under the hood

I was able to quickly build the first version of this service thanks to Vercel’s Edge Network and Serverless Functions.

The first time a request is received:

It would enter Vercel’s network.
Since this was the first time the request was processed, it would be a cache MISS.
Vercel would then call the underlying serverless function.
Which in turn validates the request and captures a screenshot of the webpage.

The image is returned from the serverless function with a very aggressive caching header.
Vercel would return the response and put it into its cache.

The next time the request is received, it would be served by Vercel’s cache.

Use cases unlocked

Automatic social image generation for all my web projects

If I create a web project or a blog post, but don’t want to spend the time crafting an og:image for each page, I can just use personal-puppeteer to generate a default og:image from the webpage’s screenshot.

Now when I share my article on Facebook, people would see the webpage’s screenshot.

Although it may not look as good as a handcrafted image, I think this is still way better than using a generic image or a profile picture as a default preview image.

So far, I am doing this for:

https://dt.in.th/ — My personal website
https://notes.dt.in.th/ — This website where I publish notes
https://capture.the.spacet.me/ — personal-puppeteer’s landing page

Sending procedurally generated images in chat rooms

By using data: URLs, an HTML page can be embedded in the JWT.
This can be useful when I want to create a chat bot that can generate infographics.

Adding web page screenshot to `README.md`

The URL can be embedded into other websites to provide an auto-updating screenshot.

Open source

This project is open source, so you can run your own instance too!

dtinth / personal-puppeteer

A personal web page screenshotting service. Basically, it exposes an API that I can use to generate screenshot of any URL.

personal-puppeteer

This is a personal web page screenshotting service. Basically, it exposes an API that I can use to generate screenshot of any URL By personal I mean that only I can use it. It is secured with JWT. But it is open source, and you can run your own instance.

It is deployed to Vercel and is inspired by Vercel’s Open Graph Image as a Service The main difference is that this service is designed to be reusable across many use cases. It can capture arbitrary URLs and run arbitrary code. It is multi-tenant. I can reuse this service without having to share secrets.

→ Read the project introduction post for more info.

Usage

See the website for usage information.

Adding a new tenant

Note: Do not send pull requests to this repository to add a new tenant. Instead, please deploy personal-puppeteer to your own account.

Generate…

View on GitHub

DEV Community: Thai Pangsakulyanont

A survey of JWT storage locations in client-side app SDKs

Auth0

AWS Amplify

Firebase Auth

Supabase

Conclusions

A workflow to generate Git patches for auto-fixable issues

My Workflow

Submission Category:

Yaml File or Link to Code

dtinth / patch-generator-action-demo

Demo project for Patch Generator action.

dtinth / patch-generator-action

Frustrated by builds failing due to trivial, auto-fixable issues? Use this action to generate a shell command to apply changes.

Additional Resources / Info

bemusic / bemuse

⬤▗▚▚▚ Web-based online rhythm action game. Based on HTML5 technologies, React, Redux and Pixi.js.

fresh-app / factory

We produce freshly-baked apps every midnight

dtinth / patch-generator-action

Frustrated by builds failing due to trivial, auto-fixable issues? Use this action to generate a shell command to apply changes.

Embracing gradual typing — Strategies for adopting TypeScript into a large project (Talk)

A local file storage for the web and interopearability layer for web-based apps (submission)

What I built

Category Submission

App Link

Screenshots

Description

Link to Source Code

dtinth / tmp

Web-based local storage

tmp.spacet.me

Devlog

Permissive License

Background

How I built it

tmp.spacet.me devlog part 4

Freshly-baked apps every midnight

fresh-app / factory

We produce freshly-baked apps every midnight

factory

Why?

React

Vue

Vanilla

etc.

tmp.spacet.me devlog part 3

Under the hood

Extension installation

Uploading process

Endpoint implementation

Other things done

tmp.spacet.me devlog part 2

Results

Implementation and refactoring

Let's deploy the simplest URL redirection service to Netlify!

tmp.spacet.me devlog part 1

Test your frontend knowledge with this little fun quiz

Building a personal but multi-tenant web page screenshotting service with Puppeteer and Vercel

The need for screenshotting web pages

Introducing personal-puppeteer

Under the hood

Use cases unlocked

Automatic social image generation for all my web projects

Sending procedurally generated images in chat rooms

Adding web page screenshot to README.md

Open source

dtinth / personal-puppeteer

A personal web page screenshotting service. Basically, it exposes an API that I can use to generate screenshot of any URL.

personal-puppeteer

Usage

Adding a new tenant

Adding web page screenshot to `README.md`