DEV Community: karabo seeisa

AI Is Making Our Brains Smooth And We Are Paying For It

karabo seeisa — Thu, 07 May 2026 13:36:27 +0000

I've changed my mind about DSA's,

you've heard it every where - "leetcode is dying", "You don't need to know DSA, AI is here"

While I am a big fan of new technologies, I also like to know what I am doing and what my code is doing, that doesn't just give me peace of mind it it saves me time when I am debugging, I don't know about you but I feel lost when I use AI to change a lot of my code

Recently I've been reading more code then actually writing, diving into DSA problems, and even had to refresh my knowledge about Big O notation and more.

I really enjoy it and I feel like as devs we have forgotten how to enjoy the process and now see code as means to an end or something like that...

Personally I find joy in it and I am pretty sure I am not the only one.

The tools and frameworks didn't make us developers...our curiosity, problem solving, the drive to build, break fix and innovate did + nerding out over computers,

Cheers

Security Hardening Update for create-authenik8-app: I fixed the real issues people called out

karabo seeisa — Mon, 27 Apr 2026 15:34:46 +0000

Hey everyone,

I just pushed a bunch of fixes to create-authenik8-app after digging through the security feedback from the community. No new flashy features. Just making the Identity Engine more solid and reliable because auth is not the place to mess around.

Here is what actually changed and why I touched it:

Guest/incognito mode no longer has a fake-auth bypass. The old logic was too loose with non-temp tokens. Now it properly verifies real JWTs, only issues a signed guest token when there is truly no token, rejects invalid bearer tokens with a clean 401, and puts the user on req.user like it should.
Access token sessions are now written to Redis when signToken runs. Refresh tokens also update the session properly on refresh. This was missing before and it made things inconsistent.
IP whitelisting is safer now. I switched to req.ip by default, added optional trustProxyHeaders support for people behind proxies, and made TTLs per-entry instead of one shared value for the whole set. Raw x-forwarded-for is spoofable so that had to go.
The rate limiter no longer kills the whole app if Redis is down at startup. I made it lazy and it now returns 503 gracefully instead of calling process.exit. A library should never nuke your consumer process like that.
Admin middleware is stricter. requireAdmin now actually checks for role === "admin" and returns 403 fast. Non-admins no longer slip through.
OAuth providers (Google and GitHub) got cleaned up. Removed plaintext refresh token logging, better profile verification, and the identity resolution now goes through the Redis-backed engine first instead of raw provider data. Unverified emails on GitHub no longer create weird account states.
The Identity Engine itself now defaults to a Redis-backed adapter. No more process-local memory maps that break on restart or in multi-instance setups. Added proper locks and indexes so behavior stays consistent.

I also added new unit and integration tests for these changes and ran the full lint, typecheck, and test suite locally before publishing.

The package is updated on npm right now (latest version). The CLI and all generated code stay fully open source and inspectable. The core Identity Engine is still closed source for security reasons but the surface is small and the generated apps are yours to own and audit.

If you tried an earlier version and hit any weirdness with sessions, admin routes, OAuth, or Redis, grab the new one and test it. npx create-authenik8-app my-app still works the same, just more robust under the hood.

PS: update to the latest Authenik8-core version

Repo: https://github.com/COD434/create-authenik8-app

Example of what it generates: https://github.com/COD434/create-authenik8-app-example

npm: create-authenik8-app

Try it if you are tired of copy-pasting JWT + refresh token + Redis + RBAC boilerplate every new project:

npx create-authenik8-app my-app
cd my-app
redis-server --daemonize yes
npm run dev

I read every comment and DM. The roasting in the first threads actually helped me tighten things up. If something still feels off or you have ideas for what would make this more trustworthy for real production work, hit me with it.

If it saves you hours (or prevents a potential security headache), a ⭐ on GitHub helps the project grow .

Thanks for the honest input so far. Building in public is messy but it beats shipping fragile auth code alone.

Update: My Phone-Built Auth CLI Hit 270+ Runs in 48 Hours And Already Got Its First Contributor

karabo seeisa — Thu, 23 Apr 2026 06:27:37 +0000

Two days ago I published “I Built a CLI That Generates Production-Ready Auth Backends in 30 Seconds (While Working From My Phone)”.

At that point the project had 177 tracked runs.
Since then… things got interesting.

As of April 22 (just 48 hours later):

270+ tracked real runs (internal telemetry)
160 runs in a single day (April 21 launch day)
143 of those 160 runs came directly from the GitHub repo done by only 5 unique people

Yes, you read that right.
Five strangers landed on the repo, read the README, and between them ran npx create-authenik8-app 143 times in one day.

That kind of repeat usage from a tiny group of early visitors is the best validation I could ask for.
And yesterday something even better happened.

I created a few small “[Good First Issue]” labels, including one for adding a clean production-ready /health endpoint to the generated Express + TypeScript templates.
Within hours, snakefood3232
replied saying:

“I’d handle this by implementing a middleware… Can have a PR up in the next 24 hours. I’ve built similar endpoints for multiple production-level applications…”

That was my first external contributor.

I’m still pinching myself.
This whole project started over two years ago as a full auth app, evolved through an SDK and the Identity Engine, and finally became the CLI I built entirely on my Android phone after my laptop died and I quit retail to go full-time.

Every single run still gives me a little notification, and seeing real people actually using it (and now contributing to it) keeps me going.
What changed in the last 48 hours:

• Added full SECURITY.md + private vulnerability reporting
• Enabled GitHub Sponsors (the button is now live)

Created realistic good-first-issues so others can jump in
First community PR is coming in the next day

If you tried the CLI after my last post , thank you.
If you haven’t yet, here’s the one-command way:

npx create-authenik8-app my-app

Repo: https://github.com/COD434/create-authenik8-app

Example generated app: https://github.com/COD434/create-authenik8-app-example

Discussions (come say hi): https://github.com/COD434/create-authenik8-app/discussions

There are still open good-first-issues if you want to be the second contributor 😉

Would love to hear what you think , drop a comment below with any feedback, what’s missing, or what you built with it.

This phone-built project is just getting started.

— Karabo (COD434)

I Built a CLI That Generates Production-Ready Auth Backends in 30 Seconds (While Working From My Phone)

karabo seeisa — Tue, 21 Apr 2026 10:58:42 +0000

Introduction

Two months ago I quit my retail job to go full indie.
Then my laptop died.

Since then, I’ve been building create-authenik8-app entirely on my phone , and it just crossed 177 runs with a new daily record of 51 yesterday.

The idea was simple: I was tired of starting every new backend project by copy-pasting the same JWT + refresh token + Redis + RBAC code… and often getting parts of the security wrong.

So I built a CLI that does it correctly from day one.

npx create-authenik8-app my-app

30 seconds later you have a production-ready Express + TypeScript backend with secure authentication already solved.

The Problem Most Developers Face

Every backend needs authentication. Yet most of us waste days (sometimes weeks) on:

Setting up secure JWT access + refresh tokens with proper rotation
Implementing replay protection and secure token storage (usually in Redis)
Handling OAuth account linking without creating duplicate users
Adding RBAC middleware that actually works
Wiring up production concerns (rate limiting, Helmet, PM2, memory guards, etc.)

Even with Passport.js or Lucia, you still end up gluing everything together and hoping you didn’t introduce subtle security flaws.

I wanted something better.
The Solution:
create-authenik8-app

create-authenik8-app is not another auth library.
It’s a focused auth system generator that scaffolds a clean, opinionated, production-ready starter.

What you get instantly:
✅ JWT (access + refresh tokens) with secure rotation and JTI replay protection
✅ Redis-backed stateful sessions
✅ Built-in RBAC middleware (auth.requireAdmin, etc.)
✅ Google & GitHub OAuth handled intelligently
✅ Prisma support (optional)
✅ Clean scalable folder structure + TypeScript
✅ Auto-generated .env with secure defaults
✅ Production extras (PM2 cluster mode, Helmet, rate limiting, memory guards)

The Identity Engine: The Real Differentiator

At the core is the Authenik8 Identity Engine (inside authenik8-core).

Instead of treating auth as separate login flows, it treats authentication as an identity resolution problem.

It intelligently:

Unifies credentials (email/password) and OAuth providers
Prevents duplicate identities
Handles smart account linking
Normalizes provider profiles into your app’s schema
Applies consistent security rules across all methods
This design makes the whole system cleaner, more secure, and much easier to extend (MFA, WebAuthn, etc. are coming).

See Exactly What You Get

I published a real generated example so you can inspect the output without running anything:

create-authenik8-app-example

You’ll see clean code, proper middleware usage, and how the Identity Engine is integrated.

Security & Trust

I know the biggest concern many developers have: “It has a closed-source core , why should I trust it?”
Valid point. Auth is critical.

Here’s my stance:

The CLI is 100% open source ,you can see exactly how everything is wired.
The Identity Engine is closed-source by design (common in security tooling) to protect sensitive implementation details like exact replay protection and token lifecycle logic.

Everything generated is fully inspectable and uses battle-tested patterns.
I added full CI on every push/PR with a live status badge.

I’m actively working on more transparency: detailed threat model, SECURITY.md, and future third-party audit.

My goal is to give solo devs and small teams a much better starting point than copy-paste boilerplate ,while being honest about the trade-offs.

My Journey So Far

Building this on a phone has been chaotic but rewarding.
Every time someone runs the CLI, I get a little notification and it keeps me motivated. The growth has been surprising, from 0 to 177 runs in under two weeks, with strong spikes after sharing updates.

I’m iterating daily based on feedback (thank you to everyone who’s commented!).

Who Is This For?

Solo developers and indie hackers
Small teams that want to ship fast
Anyone tired of repeating the same auth setup on every project

If you’re building something real and want auth done correctly without the usual headache, give it a spin.

Try It Now
npx create-authenik8-app my-app
cd my-app
redis-server --daemonize yes
npm run dev

Repo: https://github.com/COD434/create-authenik8-app
Example output: https://github.com/COD434/create-authenik8-app-example
npm: create-authenik8-app

If it saves you time, a star would mean a lot to this phone-built project ⭐

I’d love your honest feedback ,what’s missing? What should I improve next?

Building a Secure Auth System in Express (JWT, Redis, Refresh Tokens, and RBAC) and Automating It with a CLI

karabo seeisa — Sat, 04 Apr 2026 07:46:19 +0000

Authentication in Express applications is often underestimated.

Most implementations stop at “generate a JWT and verify it,” but real-world systems require much more:

• Refresh token rotation

• Token invalidation

• Concurrency safety

• Role-based access control (RBAC)

• Stateful tracking (usually via Redis)

After building this stack multiple times, I decided to formalise it into a reusable system and eventually a CLI that scaffolds it in seconds.

This post breaks down the architecture behind it and how you can use it.

The Problem with Typical JWT Auth

A basic JWT setup usually looks like this:

TypeScript

const token = jwt.sign(user, secret, { expiresIn: "15m" });

This works for simple cases, but breaks down quickly:

No Token Revocation

Once issued, a JWT is valid until it expires.

You can’t easily invalidate it.

Stateless Refresh = Security Risk

If refresh tokens are not tracked, they can be reused indefinitely.

Concurrency Issues

If two refresh requests happen at the same time:

both can succeed

multiple valid tokens are created

This leads to token duplication and potential session abuse.

The Architecture I Settled On

To solve these issues
, the system uses:

Access Tokens (JWT)

• Short-lived (e.g. 15 minutes)

• Used for API authentication

• Stateless verification

Refresh Tokens (Stateful)

• Stored in Redis

• Rotated on every use

• Old tokens are invalidated

This gives you control over sessions.

Redis as a Token Store

Redis acts as the source of truth for refresh tokens:

• Track active sessions

• Invalidate tokens instantly

• Enforce single-use refresh tokens

Refresh Token Rotation

Every refresh request:

• Verifies the token

• Checks Redis for validity

• Deletes the old token

• Issues a new refresh token

This ensures:

A refresh token can only be used once.

Concurrency Safety

A key problem is handling simultaneous refresh requests.

Solution:

• Atomic operations in Redis

• Only one request can invalidate + rotate

• The second request fails with 401

This prevents replay attacks and token duplication.

RBAC (Role-Based Access Control)

Authentication is not enough , you also need authorization.

Example middleware:

TypeScript

app.get("/admin", auth.requireAdmin, (req, res) => {

res.json({ message: "Admin only" });

});

This ensures only users with the correct role can access protected routes.

Putting It Together
The system exposes a simple interface:

TypeScript:

const auth = await createAuthenik8({

jwtSecret: process.env.JWT_SECRET!,

refreshSecret: process.env.REFRESH_SECRET!,

});

From there:

signToken() → access tokens

generateRefreshToken() → refresh tokens

Refresh token() → rotation logic

requireAdmin → RBAC middleware

Automating the Setup
After building this repeatedly, I created a CLI to remove the setup step entirely:

Bash

npx create-authenik8-app my-app

This generates:

• Express + TypeScript project

• JWT + refresh token system

• Redis integration

•RBAC middleware

• Preconfigured routes

You can go from zero → running auth server in minutes.

Why Redis is Required
A common question is: “Why not keep everything stateless?”

Because:

• You can’t revoke tokens

• You can’t prevent reuse

• You can’t track sessions

Redis enables:

• Immediate invalidation

• Session tracking

• Single-use refresh tokens

Trade-offs

This approach introduces:

• External dependency (Redis)

• Slight complexity increase

• Network latency for token validation

But in exchange, you get:

• Proper session control

• Stronger security guarantees

• Predictable auth behavior

Final Thoughts

Authentication is one of those systems that seems simple until it isn’t.

The difference between a basic implementation and a production-ready one is:

• handling edge cases

• controlling state

• preventing abuse

This project started as a way to standardize those decisions and avoid rewriting the same logic repeatedly.

If you’ve built auth systems before, I’d be interested in how you approach:

refresh token handling
revocation strategies
concurrency edge cases

Links:
Authenik8 site:https://authenik8.vercel.app/

Gitlab: https://gitlab.com/COD434/create-authenik8-app

Tiktok: https://www.tiktok.com/@thesbd8?\_r=1&\_t=ZS-9577WVfucT4

Try It

Bash

npx create-authenik8-app my-app

Closing

If you’re working with Express and need a solid starting point for authentication, this should save you a significant amount of setup time.

Feedback is welcome.

RabbitMQ: The Superhero My API Didn’t Know It Needed

karabo seeisa — Mon, 28 Jul 2025 13:20:16 +0000

The Problem: Hanging Requests, Delivered Emails

In my Node.js API, users register and receive a verification email. Simple, right?

But something strange kept happening:

The email would be sent
But the HTTP request would hang
The client got no response
My logs showed timeouts
And eventually… crashed sockets

After digging, I realized:

The SMTP email-sending process was blocking the main thread just long enough to let the HTTP connection time out.

This was a race condition: my API was waiting for the SMTP server to respond, while the client’s connection was waiting for me.

The Insight: Decouple the Work

I realized I was making the email-sending part synchronous, tying the API response to something slow (SMTP).

That’s when I remembered the concept of queuing so I did some research and found that personally I liked RabbitMQ.

How I Fixed This Issue

Here’s what I did:

The /register route publishes a message to a RabbitMQ queue (emailQueue)
A separate email worker subscribes to the queue
The worker handles the SMTP email process asynchronously
Meanwhile, the API responds immediately to the client

Here's What Achieved:

No more hanging sockets
Emails still go out
Race condition avoided
Clean separation of concerns

Why I Chose RabbitMQ?

I could’ve tried background threads or retry logic. But RabbitMQ gave me:

Message durability
Retry control
A proper job queue
A decoupled architecture I can scale later

And now, I can apply this same technique for:

Password resets
Event logs
Audit trails
Even SMS messages or 2FA

Call me a nerd but I think that's cool.

Implementation:

This is the publisher - gets the request to send a verification email, drops it into a queue, and the worker handles the rest . simple, fast, and scalable.

export const publishToQueue = async (queue: string, message: any)=>{
if(!channel)
throw new Error("RabbitMQ channel not initialized");
channel.sendToQueue(queue,Buffer.from(JSON.stringify(message)),{persistent: true});
}

This is the worker - It consumes messages form the queue and sends the email asynchronously,without delaying the HTTP response to the client .

That means users don't wait around for an email to send = much better UX if you ask me

channel.consume("emailQueue",async (msg) =>{
if(msg !== null){
const {email,verifyToken} = JSON.parse(msg.content.toString())
await sendVerificationEmail(email,verifyToken);
channel.ack(msg)
}
})

Final Thoughts

If your API does more than just respond to users — like sending emails or talking to 3rd parties — don’t make it wait.

RabbitMQ helped me move that responsibility out of the request cycle and made my code faster, safer, and easier to maintain.

I also plan to use it in the near future.

Let’s Connect

Have you hit similar issues in your backend? let me know how you tackled async tasks or race conditons.

Here's how I implemented it might spark something in your project :Github

A Plug and Play Auth API

karabo seeisa — Sun, 13 Jul 2025 14:39:58 +0000

From "Simple Form" to Full Pure Backend Auth API—Here’s What I Learned

I thought building a form would be easy. Spoiler: I was wrong.

What started as a basic CRUD app quickly spiraled into a deep dive into:

✔️ Token-based authentication (JWT)

✔️ Password hashing & encryption

✔️ Role-based access control

✔️ Redis-rate-limiting
And some other cool features

Turns out, the "Login with Google" button I mindlessly click every day? Way more complex under the hood.

I built this Auth API to demystify the process with security, docs, and scalability in mind. Perfect for devs who:

🔹 Want to see auth workflows stripped bare

🔹 Need a reference for their next project

Check it out & roast my code: (https://github.com/COD434/Auth-System-API)

Question for you:
What’s the most "simple" feature that surprised you with its complexity?