DEV Community: Georgel

The 403 Error That Was Quietly Hiding In Plain Sight

Georgel — Tue, 21 Jul 2026 13:45:45 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The Setup

Five months ago I shipped a feature I was genuinely proud of: anonymous auth for ReCode, so people could get persistent history and cross-device sync without ever creating an account. No signup friction, no passwords, just show up and your work is there next time. It worked. It kept working, quietly, for months.

Then one day I noticed something small and strange: my Firebase Auth console had 694 anonymous users. For an app with a handful of real daily sessions. That's not a rounding error — that's a ghost town of accounts nobody ever used, and somewhere in there, mine kept multiplying too.

The First Fix (That Wasn't)

The symptom was simple to describe and infuriating to pin down: after being idle for a while — tab closed, laptop asleep overnight — reopening the app sometimes handed me a brand new identity. Not an error. Not a crash. Just... a different UID than the one I'd been using an hour before, with all my saved history sitting orphaned under the old one.

My IndexedDB drafts never budged, not once in months — which was the first real clue. Whatever was breaking wasn't storage getting wiped. It was identity quietly splitting.

I found bug #1 fast: my initializeAuth() function registered a new onAuthStateChanged listener every time it was called, and never unsubscribed. If it got called twice before the first anonymous sign-in resolved — which happened routinely between app mount and my API client's lazy fallback — both listeners could see user: null and both fire their own signInAnonymously(). Two calls, two accounts, from one visit. Textbook race condition.

I fixed it: cache the in-flight promise so every caller shares one attempt, unsubscribe immediately so a listener can never double-fire. Deployed it. Watched the Firebase console. Felt very good about myself for about an hour.

Going Back to Basics

Then it happened again. Same day. Both dev and production got fresh, uninvited users — after the fix was confirmed live.

That's the moment a bug stops being annoying and starts being interesting. I made myself rule things out one at a time instead of guessing:

Not React Strict Mode double-invoking effects — it happened in production too, where Strict Mode doesn't run.
Not Vercel serving a different preview domain — checked the exact URL each time.
Not a dev server port mismatch silently changing my browser origin.
Not incognito, not a cookie-autodelete extension, not a Chrome privacy setting (I actually went and found the exact toggle I suspected — it only handles permission revocation, not storage).
Not Firebase's own anonymous-account cleanup — that setting wasn't even switched on in my project.

Every single lead was a dead end. Which meant the real cause was somewhere I hadn't looked yet — and the only way to find it was to stop theorizing and start logging.

The Reveal

I ripped out the bare catch {} blocks that had been quietly swallowing the real error this whole time, and logged everything: every onAuthStateChanged transition, every signInAnonymously failure code, with timestamps.

Then I waited for it to happen again.

When it did, the console handed me the answer in one line:

Failed to load resource: the server responded with a status of 403 ()
securetoken.googleapis.com
[authState] null — no user

securetoken.googleapis.com. Token Service. Not sign-in — refresh.

I went and checked my Firebase browser API key's restrictions in Google Cloud Console. Months earlier, doing the responsible thing, I'd locked it down to only the APIs I thought my app actually used: Cloud Firestore, Identity Toolkit, Gemini. Reasonable. Except Firebase's SDK refreshes your session by calling Token Service on your behalf, silently, in the background — a dependency that never appears anywhere in my own code, so I never thought to allow it.

Every session worked fine right up until the SDK actually needed to refresh it. Then: 403. Silently rejected. onAuthStateChanged reports no user. My own code — reasonably, given what it could see — decides nobody's signed in and mints a fresh identity. Rinse, repeat, every single morning, for five months.

The Fix

Two lines of actual insight, in the end:

The code fix — cache the auth promise, unsubscribe properly:

+ let authReadyPromise = null;

  export const initializeAuth = () => {
+   if (authReadyPromise) return authReadyPromise;
+   authReadyPromise = new Promise((resolve, reject) => {
-   return new Promise((resolve, reject) => {
-     onAuthStateChanged(auth, (user) => {
+     const unsubscribe = onAuthStateChanged(auth, (user) => {
+       unsubscribe();
        if (user) resolve(user);
        else {
          signInAnonymously(auth)
            .then(({ user }) => resolve(user))
-           .catch(reject);
+           .catch((error) => { authReadyPromise = null; reject(error); });
        }
      });
    });
+   return authReadyPromise;
  };

The actual root cause — no code at all. Just adding Token Service API to my key's allowed list, right next to Firestore and Identity Toolkit.

The Cleanup

Fixing the leak doesn't un-orphan the 694 accounts it already left behind. I wrote a small Admin SDK script to page through every user in batches of 1000, filter down to the anonymous ones, and bulk-delete everything except the two UIDs I actually use — clearing five months of accidental sprawl in one run instead of clicking through 14 pages of a console table by hand.

What I Learned

The bug that actually mattered here was never in my JavaScript. It was in a security decision I was proud of — locking down an API key to "only what my app calls" — that quietly broke a dependency I never knew existed, because I never call it directly. Firebase does.

The bigger lesson: when something breaks intermittently and every obvious cause checks out clean, that's not a sign to guess harder. It's a sign to stop guessing and start logging the thing you assumed couldn't be the problem. The 403 had been sitting right there in the network tab the entire five months. I just hadn't been watching for it.

The 403 That Was Quietly Cloning My Users Every Morning

Georgel — Tue, 21 Jul 2026 13:41:54 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

ReCode is a web-based AI code tool — conversion, analysis, and SQL/language transforms — built so people can just show up and use it without creating an account first. Under the hood, every visitor is authenticated anonymously through Firebase so their run history, per-tool drafts, and settings persist across sessions, and there's a 6-character code-based sync flow so someone can pick up an in-progress session on a second device.

Bug Fix or Performance Improvement

For about 5 months — since I first shipped the anonymous-auth and sync feature — the app had a bug that never threw a visible error, never showed up in any log I was watching, and quietly fragmented users' identities anyway.

Symptom: after leaving the app idle for a while (closing the tab, stepping away, letting a laptop sleep overnight), reopening it would sometimes show a brand new anonymous user. The old saved history was still sitting in Firestore — just unreachable, because the currently signed-in UID had silently changed underneath it. Local IndexedDB drafts, which don't key off the user at all, were always intact, which is actually what pointed me toward "this is an identity problem, not a storage problem."

By the time I went looking, my Firebase Auth console had 694 anonymous user accounts for an app with a tiny handful of real daily sessions.

There turned out to be two separate bugs stacked on top of each other:

1. A race condition in the client-side auth bootstrap. initializeAuth() registered a fresh onAuthStateChanged listener on every call and never unsubscribed. If it was called more than once before the first anonymous sign-in resolved — which happened routinely, since it's invoked both on app mount and lazily by the API client — each firing that still saw user === null kicked off its own signInAnonymously(). Two calls in quick succession meant two brand-new Firebase accounts, from a single visit.

2. A misconfigured GCP API key restriction. The bigger one. My Firebase browser API key had its allowed APIs deliberately locked down (good security practice) to Cloud Firestore, Identity Toolkit, and Gemini — but not Token Service API. Identity Toolkit covers sign-in itself, but refreshing an existing session is a separate call to securetoken.googleapis.com, and it was getting rejected with a flat 403 every time. The cached session worked fine short-term, but the moment the SDK actually needed to refresh it — exactly the "came back after being idle" case — the refresh silently failed, onAuthStateChanged reported no user, and my own code (reasonably, given what it could see) treated that as "nobody's signed in" and minted a fresh anonymous account.

Code

PR / commit: https://github.com/Georgel0/ReCode/commit/69511539d07793956c37abb57e9e49513ba98911

The race-condition fix, in lib/firebase/client.js:

+ let authReadyPromise = null;

  export const initializeAuth = () => {
+   if (authReadyPromise) return authReadyPromise;
+
+   authReadyPromise = new Promise((resolve, reject) => {
-   return new Promise((resolve, reject) => {
-     onAuthStateChanged(auth, (user) => {
+     const unsubscribe = onAuthStateChanged(auth, (user) => {
+       unsubscribe(); // only ever resolve once per attempt
        if (user) {
          resolve(user);
        } else {
          signInAnonymously(auth)
            .then(({ user }) => resolve(user))
-           .catch((error) => {
-             console.error("Auth Error:", error);
-             reject(error);
-           });
+           .catch((error) => {
+             console.error("Auth Error:", error);
+             authReadyPromise = null; // allow a retry on next call
+             reject(error);
+           });
        }
      });
    });
+   return authReadyPromise;
  };

The API-key fix wasn't a code change at all — it was adding Token Service API to the key's allowed API list, in Google Cloud Console → Credentials → API restrictions, alongside Firestore and Identity Toolkit.

My Improvements

Because the symptom was intermittent and two separate bugs were compounding, I worked through it by ruling out causes one at a time rather than guessing:

Confirmed it wasn't React Strict Mode double-invoking effects in dev, since it reproduced in production too, where Strict Mode doesn't apply.
Confirmed it wasn't Vercel's multiple preview/production domains, by checking the exact URL each time it happened.
Confirmed it wasn't a dev-server port mismatch (Next.js silently bumping ports changes the browser origin, and therefore the IndexedDB scope).
Confirmed it wasn't a browser privacy setting, a cookie-autodelete extension, or an incognito session.
Confirmed it wasn't Firebase's own anonymous-account auto-cleanup — that setting wasn't even enabled on the project.

Once I logged every onAuthStateChanged transition and every signInAnonymously error code instead of swallowing them in a bare catch {}, the real cause showed up immediately in the network tab: a 403 from securetoken.googleapis.com. That's what led me to the API key restriction.

Fixing the root cause stops new orphans from being created, but it doesn't clean up the ones already there — so I also wrote a small Admin SDK script to bulk-delete the ~694 anonymous accounts that had piled up over 5 months, in batches of 1000 via listUsers/deleteUsers, explicitly excluding the UIDs I'm actively using.

The interesting lesson: locking an API key down to "only what the app calls" is good practice, but Firebase SDKs make calls on your behalf that never appear anywhere in your own code — token refresh being the obvious one in hindsight, invisible until you actually watch the network tab for long enough to see a session go stale.

600 Commits Later: I Built an AI Developer Workbench, but Do Someone Actually Need This?

Georgel — Thu, 02 Jul 2026 17:21:10 +0000

For the last 6 months, I’ve been head-down building a project called ReCode.

But when you build in a silo for half a year, it’s easy to get tunnel vision. I am at a crossroads where I need to step back and ask the community for a brutal reality check.

What is ReCode?
At its core, ReCode is a development ecosystem and AI workbench. My goal was to create a hybrid platform—bridging a SaaS dashboard with a self-hosted, "Bring Your Own Model" setup for developers and teams who cannot legally (or safely) paste proprietary code into public AI endpoints.

Instead of building another generic chat interface(which im really trying NOT to), I focused doing the basic boring tasks and the problem of forgetful AI web tabs interfaces. Of course there are things like Cursor and Claude Code, but i dont use them.

Here is what the engine actually handles right now:

1. The Enterprise Mock Data Factory

Generating realistic, interconnected mock data is usually a massive headache. ReCode parses your SQL DDL, Prisma schema, or TypeScript interfaces and generates production-ready, relational mock data. It automatically maps foreign keys to primary keys across multiple tables and applies chronological/mathematical behavioral rules.

2. AI Code Analysis & Security Auditor

It runs a full-spectrum health report covering:

Security Audits, Complexity, Architecture Review and more.

3. Universal Translation & Refactoring

Migrating logic across languages (e.g., Python to TypeScript, C++ to Rust).

The Reality Check I Need From You

The tooling market right now is heavily dominated by inline IDE AI (Cursor, Windsurf, GitHub Copilot). I know that developers hate breaking their flow to open a browser tab.

So, here is the question I am wrestling with before I write another line of code:

Does a dedicated, privacy-focused workbench solve a friction point you actually hit in your daily workflow? Or is having an AI chat tab right inside your IDE genuinely enough for you?

Would you use a standalone tool for heavy-lifting tasks like generating relational database seeds or running a deep architectural audit?

Would local-model self-hosting actually get you to use this, or is that still not enough?

I’m looking for cold, honest feedback. If I need to pivot this into an IDE extension, or if I should double down on the self-hosted privacy angle, I want to hear it.

Tear it apart in the comments. Thanks for your time!

ReCode: The AI-Powered Workspace for Web Development

Georgel — Fri, 26 Dec 2025 14:45:35 +0000

This is a submission for the DEV's Worldwide Show and Tell Challenge Presented by Mux

What I Built

ReCode is an AI-powered productivity hub designed specifically for web developers or any other person interested. It solves the "tab-overload" and "overwhelmed" problems by centralizing essential development tools into one organized interface, helping developers stay focused and write better code faster.

My Pitch Video

🎥 Click here to watch the video on Mux

stream.mux.com

Demo

Live Demo: recode-alpha.vercel.app
GitHub Repo: Georgel0/ReCode

Tools:

Code Generator:

It's basic AI generated code but stripped of all comments, explanation and other things AI might output.

Code Convertor:

There are 11 coding languages you can choose to convert between.

AI Analysis:

Here the AI can explain to you what a piece of code dose, can help you if you didn't catch something.

CSS Frameworks Convertor

You can choose between Tailwind, Bootstrap, SASS and LESS to convert your CSS to something you prefere more.

ReCode has more tools but it's up to you to explore and use them!

The Story Behind It

As a beginner in web development, I often found myself overwhelmed. I would have dozens of tabs open—documentation, Stack Overflow, AI chats, and tutorials—leading to unorganized code, feeling overwhelmed and a fragmented workflow.

I built ReCode to be the "all-in-one" assistant I wish I had when I started. By bringing these tools together, ReCode helps developers transition from being "scattered" to being "structured."

Technical Highlights

To ensure the app was fast, scalable, and modern, I chose a powerful tech stack:

Frontend: React + Vite for a lightning-fast user interface and modular component architecture.
Backend: Node.js for efficient server-side logic.
Database & Auth: Firebase for real-time data handling and secure user authentication.
AI Engine: Grok API to power the intelligent coding assistance features.
Video Hosting: Powered by Mux, ensuring high-quality, seamless video delivery for the platform's demo.

I designed the architecture to be highly modular, making it easy to implement new features and maintainable for future growth.

About the Developer

I am a solo developer on a mission to make ReCode the ultimate tool for developers at all levels—from beginners taking their first steps to pros looking for a more streamlined workflow.

Ready to improve your workspace?

Stop Letting Your "Useless" Side Projects Die on Your Hard Drive 📦

Georgel — Thu, 25 Dec 2025 14:34:14 +0000

Why I built The Digital Junk Drawer and why I want your tiny apps to live there.

We’ve all been there.
You have a weird idea for a mini-game, a niche calculator, or a CSS experiment. You spend four hours coding it, you get it working, you smile at the screen... and then you close the editor.
That project never sees the light of day because it feels "too small" for a dedicated repository or a full domain.
I decided to change that.

Introducing: The Digital Junk Drawer

The Digital Junk Drawer is a curated, community-driven collection of micro-web apps, classic games, and digital oddities, literally anything. Some are helpful, some are time-wasters, and all are built out of pure curiosity.

Why go Open Source?
I realized that my "junk drawer" of code isn't unique. Thousands of developers have these "digital dust-collectors" sitting in their /projects folder.
I wanted to create a place where we can all toss our tiny experiments into one big, interactive pile. By turning this into an open-source project, I'm hoping to:

Provide a home for projects that don't "fit" anywhere else.
Help beginners get their first-ever Pull Request merged in a friendly, low-pressure environment.
Build a nostalgic gallery of what web devs can do with just a bit of HTML, CSS, and JS.

How You Can Contribute (It’s easy!)
I’ve streamlined the process so you don't have to spend hours setting up a dev environment.

Fork the repo.
Drop your HTML (keep CSS/JS internal for simplicity) into the /HTMLs folder.
Add a thumbnail to /Images. Link it in the index.html.

That’s it. Submit a PR, and your app is suddenly part of a global collection hosted on Vercel.

The Goal
I want this to become the internet’s most interesting drawer. I want people to click around and find things they didn't know they needed (or definitely didn't need, but enjoyed anyway).

Check out the live site: https://the-digital-junk-drawer.vercel.app/
Contribute on GitHub: https://github.com/Georgel0/The-Digital-Junk-Drawer-

What's sitting in your /projects folder right now that deserves a spot in the drawer? Let me know in the comments!