DEV Community: Akbar Ali

True or false?

Akbar Ali — Fri, 04 Sep 2026 15:54:06 +0000

Someone emailed me a signed contract, and I forwarded it to myself to test something.

Outlook did what Outlook does. Re-saved the attachment on the way through. Same contract, same signatures, same everything a human would care about.

Different bytes.

My verifier, which at that point returned a boolean, looked at it and said invalid.

That's the moment I realised I had built a liar (a very confident one, which is worse).

The thing I got wrong

I'm building Putmysign, a small app for sending PDFs out and collecting signatures. At the end of it there's a /verify page: you drop a signed PDF on it, and it tells you whether the thing in your hands is real.

The obvious design is a checkbox. Valid or not valid. Green or red.

The obvious design is wrong, and it took a mail client to teach me why.

Because "these are not the exact bytes I produced" and "this is a forgery" are not the same sentence. I had been printing the second one every time I meant the first.

If you tell someone holding a perfectly real contract that it's fake, you haven't built a security feature. You've built a way to ruin somebody's Tuesday.

Two checks, not one

So the verdict comes from two completely independent checks, which fail for completely different reasons.

One. Does the SHA-256 of this file match a document we finalized? That's the strongest answer there is: these are the exact bytes we made. This is the only check that needs a database row.

Two. Is the certificate inside the file authentically ours?

That second one needs explaining. When a document is finalized, I stamp a small HMAC-signed payload into the PDF's Keywords metadata. Who signed, when, the hash of the original, the document id. Base64url, because Keywords is a flat PDF string and JSON's quotes and parentheses have to be escaped correctly by every reader that ever touches the file (one opaque token has nothing to get wrong).

export const MANIFEST_PREFIX = "putmysign-certificate-v1:";

export function encodeManifest(manifest: CertificateManifest, signature?: string) {
  const payload = manifestPayload(manifest);
  return `${MANIFEST_PREFIX}${payload}${signature ? `.${signature}` : ""}`;
}

The point of that: the document can speak for itself.

My retention job deletes files on a schedule, by design. Someone downgrades, records age out, a mail client re-saves an attachment. In every one of those cases the byte-for-byte lookup finds nothing, and the only thing left in the world that can still say we issued this, for this document, with these signers is the certificate riding along inside the file.

A verifier that only recognises documents you still hold a row for will fail on everything you promised to delete.

Five outcomes

So there are five, strongest first:

verified: the bytes match a document we finalized. Nothing has changed.
certified: the certificate is authentically ours, but the bytes aren't the ones we made. The signings happened. This particular file just isn't the artifact we issued. This is my Outlook contract.
self-signed: signed with the free browser-only tool. Nothing witnessed it, so the file's account of itself is all there is.
tampered: carries a certificate that does not check out.
unknown: no certificate, no matching record. Not one of ours.

The middle three are the whole post. Collapsing any of them into "invalid" would be the wrong answer more often than the right one, and I have the receipts (one receipt, from my own inbox, but still).

There's a smaller decision in there I'm oddly proud of. A certificate with no signature at all is reported as unknown, not tampered, because that's what a document looks like when it was finalized while no signing key was configured. A signature that's present and wrong is a different matter entirely. Saying "forged" to someone holding a real contract is the worst mistake this endpoint could possibly make, so it only says it when it's actually sure.

if (!signature) return { verdict: "unknown" };
if (!certificateIsAuthentic(payload, signature)) return { verdict: "tampered" };
return { verdict: "certified" };

The self-signed one

The free tool on the landing page signs a PDF entirely in the browser. The file never touches my server. That's the promise, and I'm not breaking it to make my verifier's life easier.

Which means: nothing witnessed it. Nothing could have witnessed it.

I still write a certificate into it. Unsigned, marked kind: "self", and worth exactly nothing as proof.

But it means /verify can say "this was signed with Putmysign, by this name, on this date, and we were deliberately not involved", instead of reporting my own product's output as a stranger.

A claim about a file isn't proof, but it beats a shrug.

(The verify page keeps the same promise, by the way. Your PDF is read with File.arrayBuffer() and never uploaded. What goes to the server is a 32-byte one-way digest and the certificate that was already in the file. Neither of those is content.)

The bit I'd do differently

HMAC was the cheap choice. One environment variable, no key distribution, no ceremony.

The cost is that the check has to run on my server. A sceptical counterparty, the exact person this feature exists for, cannot verify a certificate without asking me to confirm my own honesty, which is a hilarious thing to build into a trust product.

A public key fixes it. That's the better end state and I haven't done it yet (I will, right after the eleven other things).

Anyway. My actual take, one sentence:

A verifier that can only say yes or no will spend most of its life saying the wrong one.

Have you had a boolean like this in your own code, a flag that quietly collapsed two very different failures into one answer? I'd genuinely like to hear about it, mostly so I feel less alone about the mail client thing.

PDF Rendering in browsers

Akbar Ali — Mon, 31 Aug 2026 14:02:55 +0000

Why was the certificate blank?

A user sent me a screenshot of a signed document.

The signature was there. The certificate page behind it was empty. Not broken, not garbled. Just a clean white page with nothing on it, like the PDF gave up halfway through.

Worked fine on my machine, obviously. It always does.

How the preview works

You can't hand a browser a raw PDF and call it a day (not when the file is private and every page needs an access check). So each page gets rendered on the server into a JPEG.

pdftoppm does the render. One page, scaled to a fixed width, quality 82, into a temp dir that gets torn down in a finally block. The result goes into object storage under a cache key, and that write is best effort. If the cache write fails you still get your page.

const cached = await getObject(cacheKey);
if (cached) return cached;

const pdf = await fetchPdfAsset(path);
const jpeg = await renderPageWithPoppler(pdf, page);

Simple enough. That part was never the problem.

The problem was Alpine

PDFs have fourteen "base" fonts. Helvetica, Times, Courier and friends. The spec says every viewer must have them, so writing tools don't bother embedding them. Why ship a font everyone already has?

Everyone, except a node:24-alpine container.

Alpine ships with basically no fonts (that's the whole point of Alpine). So pdftoppm opens the PDF, reads "draw this in Helvetica", goes looking for something to substitute with, finds absolutely nothing, and draws nothing at all. Correctly, by its own logic.

No error. No warning. Exit code 0. A perfectly successful render of a blank page.

That's the worst kind of bug. It didn't fail. It agreed with me.

The fix is one line in the Dockerfile: install Liberation fonts. They're metric compatible with the base-14 families, so nothing shifts around.

The other font problem

While I was in there I found something worse, and this one didn't crash either.

The app shows typed signatures in Dancing Script, the loopy face that reads like handwriting. The generated PDF was drawing them in Helvetica Oblique.

So you type your name, watch it appear in nice script, click sign, download the file, and get slanted Helvetica. Not wrong exactly. Just not what you agreed to.

For an app whose entire pitch is "the document is exactly what you saw", that's not a cosmetic bug.
So Dancing Script got vendored into the repo and embedded straight into the PDF with fontkit, subsetted so only the glyphs you actually used come along for the ride.

export async function embedSignatureFont(pdf: PDFDocument): Promise<PDFFont> {
  pdf.registerFontkit(fontkit);
  return pdf.embedFont(bytes, { subset: true });
}

The font is inlined as a data URI at build time instead of read off disk. The production image only copies build/, so a runtime file read would have found nothing (the blank page bug again, wearing a different hat).
Embedding fixed both ends at once. The download matches the screen now, and the renderer doesn't need the font installed anywhere, because the font is sitting inside the file.

What I actually learned

Fonts are a deployment concern. I'd have filed them under "design" on any list you handed me, right up until a container with no fonts quietly produced legal documents with nothing written on them.

And a renderer that exits 0 will lie to you. Check the pixels, not the exit code.

The certificate page got rebuilt in the same pass. Three big signer cards became compact rows, seven to a page, readable timestamps, a pointer to /verify at the bottom. It's the page almost nobody opens, right until the one day somebody really needs it.

That's most of what building Putmysign has been, honestly. Polishing things people will hopefully never have to look at.

Anyone else been bitten by a slim base image quietly dropping something? I want to hear the worse ones.

I built an e-signature app that charges you for storage, not signatures

Akbar Ali — Sat, 22 Aug 2026 14:06:54 +0000

The bill that made no sense

A signature is about 400 bytes of JSON and a hash.

Every big e-signature product will charge you somewhere between $1 and $4 to store those 400 bytes. They call it an "envelope". Run out of envelopes on the 22nd of the month and your deal waits until the 1st. I have watched a real contract sit still because a counter hit zero.

The expensive part is the other thing. A 4 MB PDF sitting in storage for seven years, backed up and replicated, costs real money every month. That part is free. It is a checkbox on the feature list.

So the pricing is backwards. It charges for the cheap thing and gives away the expensive one.

I built Putmysign the other way around. Unlimited documents, unlimited recipients, unlimited signatures, on every plan. You only pay if you want the files kept.

Free keeps your PDFs for 5 days. Pro is $19 a month and keeps them forever. The audit trail is kept forever on both, because it is a few kilobytes and it is the whole point of the product.

That one pricing decision shaped almost every technical choice underneath. That is the interesting part.

1. Deleting files is a feature, so it has to actually happen

If I promise free files are gone in 5 days, "we will get to it eventually" is not good enough. A scheduled job walks every document past its expiry date and removes the file from storage, along with every cached page image made from it.

But it deletes the file, not the record. The row stays. The audit trail stays. The hashes stay:

const originalHash = sha256(originalBytes);
// signatures applied, certificate page added
const finalHash = sha256(finalBytes);

So five days later the PDF is gone from my storage and I still cannot lie about what happened. If you kept your own copy, you can hash it and check it against a record I cannot quietly change.

Throwing away the file while keeping the proof turned out to be a nice property. I did not design it. It fell out of the pricing.

The worst bug in this area was a quiet one. A signing link can outlive the file it points to. The recipient clicks a link that is perfectly valid, and lands on nothing. So link expiry is capped to the retention window:

/**
 * A share link must never outlive the file it points to, otherwise a recipient
 * opens a valid token and finds nothing to sign.
 */
export const MAX_EXPIRY_DAYS = PLAN.retentionDays;

Two separate clocks on the same object will drift apart sooner or later. Make one of them depend on the other.

2. Recipients never make an account

Unlimited recipients means a recipient cannot be a user record I charge for.

A signup wall in the middle of someone else's contract is the biggest reason paperwork stalls. It mostly exists so vendors can count seats.

So the signing link is the login. It is an HMAC over the document and the recipient, built from a server-only secret. Only the hash of the token is stored:

const secret = process.env.SIGNING_TOKEN_SECRET ?? process.env.SESSION_SECRET;
if (secret.length < 32) throw new Error("must be at least 32 characters");
return createHash("sha256").update(token).digest("hex");

Store the hash, not the token. If my database leaks tomorrow, nobody gets a working signing link out of it. Same idea as hashing passwords, applied to a URL.

3. One row per document

A signing session is a burst of tiny writes. Opened. Viewed page 3. Signed field 2. IP recorded. All of it against one document that is only ever read as a whole.

Splitting that across six tables buys me joins I never run. So each document is one JSONB column holding everything, with the fields I actually filter on copied out into real indexed columns: owner, status, updated date, expiry date, purge date. A GIN index on the JSON handles signing-link and "shared with me" lookups.

The real risk with a single row is two people signing at the same moment. Last write wins, one signature disappears. I fixed it the boring way, with SELECT ... FOR UPDATE inside a transaction.

Postgres has been a fine document database for years, and it still hands you row locks when you need them.

4. Thumbnails without a thumbnail service

Page previews come from pdftoppm, part of poppler. It is a 25 year old C program. I shell out to it, render the page when someone asks for it, and cache the image back into the bucket next to the PDF. Delete the PDF and the cached pages go with it.

No render service, no queue, no third party API with a per page price on it. Storage is what I charge for, so anything that turns compute into a monthly bill works against the model.

The stack, quickly

React Router 7, TypeScript, Postgres with Prisma, any S3 compatible bucket (MinIO locally, so the whole thing runs on a laptop with one docker compose up), Firebase Auth for owners only, Resend for email with bounce handling, Paddle for billing.

Nothing fancy. The interesting decisions are all about what is missing.

Things worth stealing

You do not have to care about e-signatures to use any of this:

Charge for what actually costs you money. If your pricing unit and your cost are different things, people feel it as unfair long before they can explain why.
Delete the file, keep the proof. Hashes and audit rows are tiny. They let you delete aggressively and still stay accountable.
Two clocks on one object will drift. Derive one from the other.
A signup wall in someone else's workflow is a tax on your own customer. They pay it in deals that stall.
JSONB, plus a few copied-out indexed columns, plus FOR UPDATE covers a lot of "we need a document database" situations.

It is live at putmysign.com. Free tier, no card. Upload a PDF you already have and send it to someone who will never make an account.

If you can break the signing link logic, I would genuinely like to hear about it in the comments.

What is the most backwards pricing unit you have run into? I will start: per seat pricing on a read only viewer.

Translate apps in one command

Akbar Ali — Wed, 13 Aug 2025 06:04:17 +0000

Check out the package first:
@pulimoodan/localiser

Features

Translate i18n locales with one command
Translate only required languages (only the ones we changed)
Translate only the required namespaces (yeah, same as above: only the ones we changed)
Translate any language, with any iso codes: like pt or pt-BR (because, we're using AI. Not a flex btw)

Concerns to be addressed

Optimise the Open AI requests with the only the required keys, instead of whole json file
An init command to generate the project configuration
Doesn't support different types of folder structures, only: lang/namespace.json
Configure different types of models

Contribute (or detract)

If you've got an idea to improve or play around with this:

Fork the repo
Work your magic, cook well
Slam a PR
And I will think about it (kidding, we need those contributions)

Link to GitHub repo: Localiser

Code pollution

Akbar Ali — Sun, 03 Aug 2025 06:04:11 +0000

The list of PRs to be reviewed, getting long and long each day in numbers.

The dashboard, looking at me with that weird devil laugh every time I open the Github.

It's not me, being lazy and stubborn to keep reviewing everything consistently (maybe).

It's some dry dreaded lines of waste, of code changes being written in those files that make the stubborn I am.

The AI slop, waiting on those changes to get refuge in our codebases are becoming a nightmare day by day.

The Cause

Developers being lazy to write code. They're not here for passion (or they lost it), just for money.
They don't care about what they (or the agent) write, they're just focused on completing the task due to work pressure.
They're not good at this, maybe they're some product managers who focus on the app but not technology under the hood.
The FOMO of using AI to get tasks move quickly and wasting time (most of the medias are responsible for this, the me before a few months would assure this).
People being developers instead of poets (The art of beautiful code is long gone).

The Solution

Review PRs effectively (I used to rewrite some my own, instead of educating the PR author)
Talk to your teammates and motivate them (there had been one of my friends who quoted about a fellow's code: I got goosebumps reading it)
As a developer, think about a problem before asking it to the agent. Share your thoughts and get feedback.
Try to use AI for automation, not to be dumb day by day (The ability to think will fade away, aware of that).
Proofread the code written by the agent, and instruct how to make it well written.
Sometimes writing with your own hands feels like greatness being achieved (don't listen to the FOMO creators).
Learn to code or learn to prompt (be good at it, sometimes it is easier to express in code than in natural language).

I could have become a project manager 20 years ago if I didn’t care to write code myself and I just wanted outcomes.
-- DHH

Common JS library import in ES Module

Akbar Ali — Mon, 21 Jul 2025 07:15:13 +0000

Spent a lot of time debugging this.

I was using react color library from NPM in a project and my project was in ES module scope.

Problem

import reactColor from "react-color";

TypeError: Cannot read properties of undefined (reading 'displayName')

Fix

import * as reactColor from "react-color";

const { SketchPicker } = reactColor;

Prisma: Could not parse schema engine response

Akbar Ali — Thu, 19 Dec 2024 08:13:48 +0000

Problem

Recently encountered this error while deploying our app to production:

Error: Could not parse schema engine response: SyntaxError: Unexpected token E in JSON at position 0

There is no more explanation why this occurred, just this line. In the recent merge commit we had only changed a couple of locale keywords, that's it.

Figuring out

Searched all over the internet and found nothing.

Then, I noticed a warning a couple lines of above the error, like this:

prisma:warn Prisma failed to detect the libssl/openssl version to use, and may not work as expected. Defaulting to "openssl-1.1.x".

I searched about this on GitHub and found this:
Prisma fails to find openssl 3.0.x on new bookworm

I realised that for some reasons, the new version of the alpine docker image I was using doesn't come with the openssl package - Which was required for Prisma engine.

Solution

The issue discussion I shared above said that use node version 18.5.something and we can temporarily resolve this or use a different docker image.

But, I don't have to use a different version of node and make conflicts to other packages.

So, I should install the package manually.

This is the docker image I was using:

FROM node:18-alpine

I added these lines to it:

# install openssl
RUN apk update && apk upgrade
RUN apk add --no-cache openssl

And, that solved the problem.

Importing from GitLab to GitHub

Akbar Ali — Fri, 17 May 2024 07:19:17 +0000

In GitLab:

Profile -> Preferences -> Access tokens -> Add new token
Name it, select all permission that apply, click create.
Now you get a token, copy it.

In GitHub

Create new repository.
On the create page, right below the heading there is a text saying import a repository.
Click it, copy the repo url from Gitlab and paste it there.
Add your gitlab username and the access token.
Name the repository.
Click begin import.
It will take some time, sit tight.

Object memory reference in JS

Akbar Ali — Tue, 12 Mar 2024 20:05:52 +0000

const person1 = {
    name: "Alex",
    address: "Toronto"
}

const person2 = person1;
person2.name = "John";

console.log(person1);

What would be the output of the above code?

Does that look like this:

{
    name: "Alex",
    address: "Toronto"
}

You're wrong. It would look like this:

{
    name: "John",
    address: "Toronto"
}

Yes, that's the correct output. But that was not what we ought to do. We need the name of the person1 to stay like whatever it was before. We changed the name of person2.

Then, where did it go wrong?

The problem is with the JavaScript's object memory reference. We only assigned the person1 variable to the person2 variable. Javascript keeps the memory reference of the variable in the place for both of them. That's why when we changed the name of person2, it affected person1.

How to overcome this bug?

Even, I had spent a full day debugging a commercial app and banged my keyboards due to frustration to find out it's just a memory reference bug.

Here's a solution:
Spread operator

const person1 = {
    name: "Alex",
    address: "Toronto"
}

const person2 = {...person1};
person2.name = "John";

console.log(person1);

Here, we are spreading the person1 variable to create a new one. Now it would work fine as we expected. But, it has an exception.

What if our code was like this:

const person1 = {
    name: {
        first: "Alex",
        last: "Telles"
    },
    address: "Toronto"
}

const person2 = {...person1};
person2.name.first = "John";

console.log(person1);

This is our expected output:

{
    name: {
        first: "Alex",
        last: "Telles"
    },
    address: "Toronto"
}

But, what we get:

{
    name: {
        first: "John",
        last: "Telles"
    },
    address: "Toronto"
}

The person1 also got changed even if we used spread operation to create a new object.

This is because, the spread operator only affects the first level properties and it won't clone the deep level key values. So, the first in the name property still has the memory reference to its parent.

Here is the solution to deep clone JS objects:

JSON stringify

const person2 = JSON.parse(JSON.stringify(person1));

Converting the object to string and then into JSON resolves the problem.

But still, we have a problem.

function test() { console.log("This is a Test") }

const person1 = {
  name: {
    first: "Alex",
    last: "Telles"
  },
  f: test,
  address: "Toronto"
}
person1.f()

const person2 = JSON.parse(JSON.stringify(person1));

person2.f()

This code will return an error saying TypeError: person2.f is not a function. This is because, we had a memory reference to the function in the parent object and when we converted it into string for cloning, that reference got lost.

thanks to @efpage for the feedback.

So, there are some ways to overcome this:

Using loadash

const _ = require('lodash');

function test() { console.log("This is a Test") }

const person1 = {
  name: {
    first: "Alex",
    last: "Telles"
  },
  f: test,
  address: "XYZ"
}

const person2 = _.cloneDeep(person1);
person2.f();

lodash library has a cloneDeep function which will help to deep clone object with all memory reference.

Structured clone function

const person2 = structuredClone(person1);

The structuredClone function will be available in the new version of JavaScript and it will deep copy the parent object.

Hope this articles helped you. Drop your feedbacks in comments.

This or that?

Akbar Ali — Wed, 06 Dec 2023 09:07:49 +0000

Have you ever ended up in a situation where you have many images of something but hard to choose the perfect one?

Like, if we have two images, it's easy to choose the best one. But when it's 5 or 10 or 50 images, the process becomes more difficult.

The solution is to take the first two pictures, find the best one. Now take the third picture and cross check with the best one and it continues.

I made a simple web app which helps to do this. Simply, we upload a bunch of images and click start. The program shows us a pair of images and we have to choose the best one. It repeats until the best one finally being found.

Dot-poll is a simple web app with basic html and js which delivers this solution. See the live version here: Demo

There is a lot of features we can add to this app and I am looking for developers who are interested working on this. Leave a comment or a pull request if you find this worth a try.

An alternative for Render?

Akbar Ali — Tue, 05 Dec 2023 09:17:32 +0000

I have been using Render for hosting my side projects. It's flawless, easy to connect GitHub projects and deploy with just a click.

I switched to render because I was fed up with the hard and weird deployment process of Heroku. Render has some amazing features and easy to use.

But recently, I faced this problem of services getting suspended if they are in free tier. Somehow, it's hard to afford some side projects in a paid plan. I share my side projects with my friends and they say it's not loading. I ask them to wait for couple of minutes and they usually stop trying after some time.

Currently, I am searching for a better alternative which provide full time serving of the web app we deploy. I really liked the workflow of Render and hope to find something similar.

A platform to share jokes

Akbar Ali — Mon, 04 Dec 2023 09:00:39 +0000

I was totally inspired by the dev.to and twitter platforms due to their engagements and user interactions.

So, sharing jokes and reacting to them is a pretty entertaining medium and thought about building a platform for that.

I am planning to add more interactive features to the app and expecting more public opinions.

Feel free to try the app here: Chali App and share your feedbacks.

View the source code if you are interested to know how I built it: GitHub

Also, I am trying to work on the android and IOS apps.