DEV Community: Nilesh Kumar

🚀 Mock APIs Evolved: GraphQL Gateway, Fake JWT Auth, Dynamic Custom Collections & TypeScript SDKs in Playground API v3

Nilesh Kumar — Wed, 05 Aug 2026 18:23:03 +0000

Mock REST APIs like standard JSONPlaceholder are great for quick hello-world prototypes. But as soon as your frontend app grows to test GraphQL queries, JWT authentication flows, custom domain entities (like products or orders), or TypeScript auto-completion, standard mock tools quickly hit a brick wall.

A while ago, I launched Playground API—a zero-config, stateful mock API that solved the biggest flaw in mock testing: instant state loss. Playground API introduced zero-login per-session sandboxing, giving frontend developers real state persistence for POST, PUT, PATCH, and DELETE requests without databases or authentication logins.

Following our v2 update (which brought network latency simulation, error injection, and OpenAPI exports), today I’m thrilled to introduce Playground API v3.0! ⚡

v3.0 elevates Playground API from a mock REST API into a complete multi-protocol developer testing ecosystem featuring a GraphQL Sandbox Gateway, Fake JWT Auth Simulation, Dynamic Custom Collections, Dynamic SVG Avatars, and Full TypeScript SDK Definitions.

🆕 What’s New in Playground API v3.0?

🕸️ 1. GraphQL Sandbox Gateway (`/graphql`)

You no longer need to spin up a mock GraphQL server or setup Apollo Server locally just to test GraphQL queries and mutations.

Playground API now includes a native GraphQL Gateway at /graphql. Crucially, all GraphQL mutations (createPost, updatePost, deletePost) interact directly with your session sandbox overlay—giving you stateful GraphQL testing out-of-the-box!

GraphQL Query Example:

query GetUserWithPostsAndComments {
  user(id: 1) {
    name
    email
    avatar
    posts {
      id
      title
      comments {
        id
        body
      }
    }
  }
}

GraphQL Stateful Mutation Example:

mutation AddNewPost {
  createPost(
    user_id: 1, 
    title: "\"Testing GraphQL Mutations in Playground API v3\", "
    body: "Stateful GraphQL without any backend setup!"
  ) {
    id
    title
    user {
      name
    }
  }
}

🔑 2. Fake JWT Authentication Simulation (`/auth`)

Testing login screens, token storage (localStorage / HTTP-only cookies), token refresh cycles, and protected profile views is historically tedious with fake APIs.

Playground API v3 introduces a dedicated JWT Auth Simulation:

🚪 POST /auth/login: Authenticate using mock credentials and receive signed JWT access and refresh tokens.
📝 POST /auth/register: Register a new sandboxed user profile with instant JWT credential generation.
🔄 POST /auth/refresh: Test access token expiration and token rotation.
👤 GET /auth/me & PATCH /auth/me: Fetch and edit the logged-in user profile passing Authorization: Bearer <jwt_token>.

// 1. Login to get JWT tokens
const loginRes = await fetch('https://playground-api-xi.vercel.app/auth/login', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ username: 'Bret' })
});
const { access_token } = await loginRes.json();

// 2. Fetch authenticated profile
const profileRes = await fetch('https://playground-api-xi.vercel.app/auth/me', {
  headers: { 'Authorization': `Bearer ${access_token}` }
});
const user = await profileRes.json();

📦 3. Dynamic Custom Resource Collections (`/custom/:collection`)

Why limit mock testing to posts, users, comments, and todos? What if you're building an e-commerce dashboard (products, orders), a CRM (leads, contacts), or a note-taking app (notes)?

With Dynamic Custom Collections, you can hit any custom endpoint name on the fly:

POST /custom/products ➔ Creates a new product entity in your session overlay
GET /custom/products ➔ Fetches your sandboxed product collection
PUT /custom/products/local-123 ➔ Updates the custom entity
DELETE /custom/products/local-123 ➔ Deletes the custom entity

You can also seed entire mock domains in 1 click via POST /custom/seed!

🖼️ 4. Built-in Dynamic SVG Avatars & Image Placeholders (`/public/avatars/:seed`)

Say goodbye to broken external image placeholder URLs or slow Unsplash requests in your UI components!

Playground API now serves crisp, ultra-fast dynamic SVG avatar and thumbnail placeholders directly:

👤 Avatar: /public/avatars/john_doe.svg?bg=4f46e5&size=128
🖼️ Thumbnail: /public/thumbnails/product_1.svg?bg=10b981&width=400&height=200

📘 5. Full TypeScript Definitions & SDK Types (`/types/ts`)

Stop manually writing TypeScript interfaces for your mock data! Playground API now exposes native .d.ts definitions:

Download directly at /downloads/playground-api.d.ts or view live at /types/ts.
Easily import User, Post, Comment, Todo, AuthPayload, SessionStats, and endpoint response wrappers straight into your TypeScript codebase.

💾 6. Session Snapshot Export & Import (JSON)

Want to share a specific mock bug state with a teammate or seed your Playwright/Cypress test runner with pre-configured data?

📤 GET /session/export: Export your entire session sandbox overlay as a clean, shareable .json snapshot file.
📥 POST /session/import: Import a saved JSON snapshot to instantly restore pre-set data states.

🏗️ 7. Decoupled Architecture (`playground_api_fe` & `playground_api_be`)

Under the hood, Playground API has been re-architected into a fully decoupled architecture:

🎨 Frontend Portal (playground_api_fe): EJS template design system, interactive Try-It API Studio, GraphQL Explorer, and documentation UI.
⚙️ Backend API (playground_api_be): Lightweight, high-performance Node.js / Express 5 & Prisma ORM service powering session virtual merging.

⚛️ Updated React Example: Combining GraphQL, JWT Auth & Latency Simulation

Here’s a full React example demonstrating how easily you can test JWT Login, GraphQL Queries, and Stateful Mutations in a single component:

import React, { useState } from 'react';

const API_BASE = 'https://playground-api-xi.vercel.app';

export default function PlaygroundV3Demo() {
  const [token, setToken] = useState(null);
  const [user, setUser] = useState(null);
  const [posts, setPosts] = useState([]);
  const [loading, setLoading] = useState(false);

  // 1. Simulate JWT Auth Login
  const handleLogin = async () => {
    const res = await fetch(`${API_BASE}/auth/login`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ username: 'Bret' })
    });
    const data = await res.json();
    setToken(data.access_token);
    setUser(data.user);
  };

  // 2. Fetch Data via GraphQL Gateway
  const fetchGraphQLData = async () => {
    setLoading(true);
    const query = `
      query {
        posts(limit: 5) {
          id
          title
          user { name email }
        }
      }
    `;
    const res = await fetch(`${API_BASE}/graphql`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ query })
    });
    const { data } = await res.json();
    setPosts(data.posts);
    setLoading(false);
  };

  return (
    <div style={{ maxWidth: '650px', margin: '40px auto', fontFamily: 'system-ui, sans-serif' }}>
      <h2>🚀 Playground API v3 — Developer Test Rig</h2>

      <div style={{ display: 'flex', gap: '10px', marginBottom: '20px' }}>
        {!token ? (
          <button onClick={handleLogin} style={{ padding: '8px 16px', background: '#4f46e5', color: '#fff', border: 'none', borderRadius: '6px' }}>
            🔑 Test JWT Login (`/auth/login`)
          </button>
        ) : (
          <p style={{ color: 'green' }}>✅ Authenticated as <strong>{user?.name}</strong></p>
        )}

        <button onClick={fetchGraphQLData} style={{ padding: '8px 16px', background: '#059669', color: '#fff', border: 'none', borderRadius: '6px' }}>
          🕸️ Fetch via GraphQL (`/graphql`)
        </button>
      </div>

      {loading && <p>⏳ Querying GraphQL Gateway...</p>}

      {posts.length > 0 && (
        <div>
          <h3>📝 GraphQL Posts Result:</h3>
          <ul>
            {posts.map((p) => (
              <li key={p.id}>
                <strong>{p.title}</strong> — <small>By {p.user?.name}</small>
              </li>
            ))}
          </ul>
        </div>
      )}
    </div>
  );
}

📊 Complete Feature Matrix: v1 vs v2 vs v3

Feature	v1.0 Baseline	v2.0 Testing Suite	🚀 v3.0 Next-Gen Ecosystem
Stateful Per-Session Sandbox	✅ Cookie / Header	✅ Cookie / Header	✅ Cookie / Header
REST Data Endpoints	✅ 4 Baseline Collections	✅ 4 Baseline Collections	✅ Baseline + Custom Collections (`/custom/*`)
GraphQL Gateway	❌ None	❌ None	✅ Stateful `/graphql` Queries & Mutations
JWT Auth Simulation	❌ None	❌ None	✅ `/auth/login`, `/auth/register`, `/auth/me`
Dynamic Custom Entities	❌ Fixed Collections	❌ Fixed Collections	✅ `/custom/:collection` (Products, Orders, etc.)
Dynamic SVG Image Helpers	❌ None	❌ None	✅ `/public/avatars/` & `/public/thumbnails/`
TypeScript Definitions	❌ None	❌ None	✅ `.d.ts` export & `/types/ts` endpoint
Session Snapshot Import/Export	❌ None	❌ Reset Only	✅ JSON Export & Import (`/session/export`)
Network Latency & Error Injection	❌ None	✅ `?_delay` & `?_status`	✅ `?_delay` & `?_status`
Schema Downloads	❌ None	✅ OpenAPI, Postman, Bruno	✅ OpenAPI, Postman, Bruno, GraphQL SDL

🔗 Try It Out & Get Involved!

Playground API is 100% free, zero-config, open-source, and requires no account setup:

🌐 Live App & Interactive API Studio: https://playground-api-xi.vercel.app/

📖 Interactive Developer Portal: https://playground-api-xi.vercel.app/docs

🕸️ GraphQL Gateway Docs: https://playground-api-xi.vercel.app/docs/graphql

⭐ GitHub Repository: github.com/nileshcodehub/playground_api

If Playground API makes your frontend development, GraphQL prototyping, or E2E testing easier, drop a ⭐ on GitHub!

Which v3 feature are you most excited to try in your projects? Let me know in the comments below! 👇

🚀 Mock APIs Just Got an Upgrade: Network Delay Simulation, Error Testing & Postman Exports in Playground API v2

Nilesh Kumar — Sat, 01 Aug 2026 18:15:54 +0000

A few days ago, I introduced Playground API—a zero-config, stateful mock REST API designed to solve a huge frontend headache: mock APIs like standard JSONPlaceholder that instantly discard your POST, PUT, and DELETE state changes.

Playground API changed that by introducing zero-login per-session sandboxing, giving developers real data persistence in their browser without database setups or account creation.

Since then, based on awesome feedback from the community, I've shipped a massive v2.0 update packed with features designed specifically for modern frontend development, UI edge-case testing, and E2E automation! ⚡

Here is a breakdown of what's new and how you can use Playground API to level up your development workflow.

🆕 What’s New in Playground API v2.0?

⏱️ 1. Network Delay Simulation (`?_delay` & `X-Simulate-Delay`)

Testing skeleton loaders, loading spinners, and debounced inputs on local localhost is notoriously difficult because mock APIs respond almost instantaneously (10–30ms).

Now, you can force Playground API to simulate network latency directly from your code or request headers:

// Simulate a 1.5 second delay to test your UI loading spinner
fetch('https://playground-api-xi.vercel.app/posts?_delay=1500')

Or via request header: X-Simulate-Delay: 1500

🚨 2. HTTP Error Simulation (`?_status` & `X-Simulate-Status`)

Want to verify how your app handles a 500 Server Error, 404 Not Found, or 429 Rate Limit without breaking your server code?

You can now inject arbitrary HTTP error responses on-demand:

// Force the API to return a 500 Internal Server Error payload
fetch('https://playground-api-xi.vercel.app/posts?_status=500')

Or via request header: X-Simulate-Status: 404

🔗 3. Relational Sub-Resources & Nested Filtering

Building master-detail views or user profile dashboards? Playground API now natively supports relational queries and nested sub-resource routing out-of-the-box:

# Query filtering
GET /posts?user_id=1
GET /todos?user_id=1&completed=true

# Nested sub-resource routes
GET /users/1/posts       # Get all posts belonging to User 1
GET /users/1/todos       # Get all todos belonging to User 1
GET /posts/1/comments    # Get all comments for Post 1

🔍 4. Universal Full-Text Search (`?q=`) & Dynamic Sorting (`?_sort`)

Quickly search and sort through baseline data merged with your custom session sandbox edits:

# Search across all fields (title, body, name, email)
GET /posts?q=javascript

# Sort records dynamically by field and order
GET /posts?_sort=title&_order=desc

🛡️ 5. E2E Test Suite Ready (`X-Playground-Identity`) & Programmatic Reset

While cookies (pg_identity) handle state persistence smoothly in standard browsers, automated E2E test runners (Playwright, Cypress) and strict Incognito / Safari policies often block cross-site cookies.

Playground API v2 introduces Header-Based Identity Fallback and Programmatic Session Resets:

Send X-Playground-Identity: your-custom-session-key in header to maintain isolated sandbox state across test runs.
Call DELETE /session/reset to wipe all custom session mutations and revert back to a clean global baseline before each test suite!

📦 6. Multi-Format Collection & Schema Downloads

Need to import mock endpoints into your favorite API client? You can now download full specs directly from the documentation UI or API:

📄 OpenAPI 3.0 Spec (/downloads/openapi.json)
🚀 Postman Collection v2.1 (/downloads/postman.json)
🐶 Bruno API Collection (/downloads/bruno.json)
💜 Insomnia Collection (/downloads/insomnia.json)

💻 7. 9-Language Live Code Generators

The built-in documentation runner now instantly generates ready-to-use code snippets in 9 popular languages and libraries:

cURL, Node.js Fetch, Axios, Python, Go, Swift, Kotlin, Rust, and PHP.

⚛️ Updated React Example: Skeleton Loader + Error Handling + Delay Simulation

Here’s a full React component demonstrating how easily you can test loading spinners, error states, and CRUD mutations:

import React, { useState, useEffect } from 'react';

const API_BASE = 'https://playground-api-xi.vercel.app';

export default function AdvancedPostManager() {
  const [posts, setPosts] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);
  const [delayMs, setDelayMs] = useState(1000); // Test delay

  const fetchPosts = async () => {
    setLoading(true);
    setError(null);
    try {
      // Simulate network delay to test UI spinner
      const res = await fetch(`${API_BASE}/posts?page=1&limit=5&_delay=${delayMs}`);
      if (!res.ok) throw new Error(`HTTP Error: ${res.status}`);
      const data = await res.json();
      setPosts(data);
    } catch (err) {
      setError(err.message);
    } finally {
      setLoading(false);
    }
  };

  useEffect(() => {
    fetchPosts();
  }, [delayMs]);

  // Programmatically reset session sandbox back to clean state
  const handleResetSession = async () => {
    await fetch(`${API_BASE}/session/reset`, { method: 'DELETE', credentials: 'include' });
    fetchPosts();
  };

  return (
    <div style={{ maxWidth: '650px', margin: '40px auto', fontFamily: 'sans-serif' }}>
      <h2>📝 Playground API v2 — Real-Time Test Rig</h2>

      <div style={{ display: 'flex', gap: '10px', marginBottom: '15px' }}>
        <label>
          Simulated Latency:
          <select value={delayMs} onChange={(e) => setDelayMs(Number(e.target.value))}>
            <option value={0}>0 ms (Fast)</option>
            <option value={1000}>1000 ms (Slow 3G)</option>
            <option value={2500}>2500 ms (High Latency)</option>
          </select>
        </label>

        <button onClick={handleResetSession} style={{ background: '#ff4d4f', color: '#fff', border: 'none', padding: '6px 12px', borderRadius: '4px' }}>
          🔄 Reset Session Sandbox
        </button>
      </div>

      {loading && <p>⏳ Loading posts (Simulating latency: {delayMs}ms)...</p>}
      {error && <p style={{ color: 'red' }}>⚠️ Error: {error}</p>}

      {!loading && !error && (
        <ul>
          {posts.map((post) => (
            <li key={post.id}>
              <strong>{post.title}</strong> (User ID: {post.userId})
            </li>
          ))}
        </ul>
      )}
    </div>
  );
}

📊 Summary: v1 vs v2 Comparison

Feature	Playground API v1	🚀 Playground API v2
State Persistence	✅ Per-session Sandbox	✅ Per-session Sandbox
Network Latency Simulation	❌ Instant only	✅ `?_delay=1500` / Header
Error Status Simulation	❌ None	✅ `?_status=500` / Header
Relational Querying	❌ Base routes only	✅ `/users/1/posts`, `/posts?user_id=1`
Search & Sorting	❌ None	✅ `?q=search` & `?_sort=title`
E2E & Incognito Support	⚠️ Cookies only	✅ `X-Playground-Identity` Header
Schema Downloads	❌ None	✅ OpenAPI, Postman, Bruno, Insomnia
Code Generators	⚡ Basic JavaScript	⚡ 9 Languages (Go, Rust, Swift, etc.)

🔗 Try It Out & Support the Project

Playground API is 100% free, zero-config, and requires no registration:

🌐 Live App & Interactive Docs: https://playground-api-xi.vercel.app/

⭐ GitHub Repository: github.com/nileshcodehub/playground_api

If you find Playground API helpful for your projects, demos, or E2E tests, leaving a ⭐ on GitHub would mean the world!

What features would you like to see next? Drop a comment below! 👇

Stop Faking Your Mock APIs: Introducing Playground API 🚀

Nilesh Kumar — Wed, 29 Jul 2026 17:05:18 +0000

If you’ve ever built a frontend prototype, mobile app, or design demo, you’ve likely run into this common headache:

You connect your app to a mock REST API (like standard JSONPlaceholder). You construct a sleek UI form, send a POST request to add a new item, and receive a glowing 201 Created response.

Then you refetch the data... and your new item has completely disappeared. 👻

Because standard mock services don't actually save your mutations, testing realistic user flows like pagination, item updates (PUT/PATCH), or row deletions (DELETE) requires setting up local mock servers like MSW or json-server.

That’s exactly why I built Playground API.

⚡ What is Playground API?

Playground API is a zero-config, ready-to-use mock REST API built for frontend developers, QA engineers, and prototypers.

It comes pre-loaded with realistic global baseline datasets (users, posts, comments, todos), but with one major difference: it actually persists your CRUD state.

When you create, update, or delete a record, subsequent GET requests automatically return your updated state—without requiring account registration, database setups, or API keys.

🆚 Traditional Mocks vs. Local Servers vs. Playground API

Feature	Standard Mock APIs	Local Mock Servers (MSW / JSON-Server)	🚀 Playground API
Real State Persistence	❌ Data vanishes on `GET`	⚠️ Local machine only	✅ Instant Real Persistence
Session Isolation	❌ Shared / None	❌ Local single user	✅ Isolated Developer Sessions
Setup Required	⚡ Zero Setup	🐢 npm install & schema config	⚡ Zero Setup (Plug & Play)
Browser Request Tester	❌ None	❌ Requires Postman	✅ Built-in Interactive Inspector
Authentication / Keys	✅ None	✅ None	✅ Zero Signup Needed

⚛️ How to Use Playground API in a React App

Using Playground API in React is identical to using standard fetch or axios, but with real state persistence across component mounts.

Here is a complete example of a React component performing real Fetch, Create, and Delete actions:

import React, { useState, useEffect } from 'react';

const API_BASE = 'https://playground-api-xi.vercel.app';

export default function PostManager() {
  const [posts, setPosts] = useState([]);
  const [title, setTitle] = useState('');
  const [loading, setLoading] = useState(false);

  // 1. Fetch posts on mount
  const fetchPosts = async () => {
    try {
      const res = await fetch(`${API_BASE}/posts?page=1&limit=5`);
      const data = await res.json();
      setPosts(data);
    } catch (err) {
      console.error('Failed to load posts:', err);
    }
  };

  useEffect(() => {
    fetchPosts();
  }, []);

  // 2. Create a new post (Persists instantly on subsequent GET)
  const handleCreatePost = async (e) => {
    e.preventDefault();
    if (!title.trim()) return;

    setLoading(true);
    try {
      const res = await fetch(`${API_BASE}/posts`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        credentials: 'include', // Ensures identity session persistence
        body: JSON.stringify({
          title,
          body: 'This is a live persisted post created from React!',
          userId: 1,
        }),
      });

      if (res.ok) {
        setTitle('');
        // Refetch: Your newly created item will appear right at the top!
        await fetchPosts();
      }
    } catch (err) {
      console.error('Error creating post:', err);
    } finally {
      setLoading(false);
    }
  };

  // 3. Delete a post (Removes item permanently from your session)
  const handleDelete = async (id) => {
    try {
      const res = await fetch(`${API_BASE}/posts/${id}`, {
        method: 'DELETE',
        credentials: 'include',
      });

      if (res.ok) {
        setPosts((prev) => prev.filter((post) => post.id !== id));
      }
    } catch (err) {
      console.error('Error deleting post:', err);
    }
  };

  return (
    <div style={{ maxWidth: '600px', margin: '40px auto', fontFamily: 'sans-serif' }}>
      <h2>📝 Playground API — React Demo</h2>

      {/* Add Post Form */}
      <form onSubmit={handleCreatePost} style={{ marginBottom: '20px', display: 'flex', gap: '10px' }}>
        <input
          type="text"
          value={title}
          onChange={(e) => setTitle(e.target.value)}
          placeholder="Enter post title..."
          style={{ flex: 1, padding: '8px 12px', border: '1px solid #ccc', borderRadius: '4px' }}
        />
        <button type="submit" disabled={loading} style={{ padding: '8px 16px', cursor: 'pointer' }}>
          {loading ? 'Adding...' : 'Add Post'}
        </button>
      </form>

      {/* Posts List */}
      <ul style={{ listStyle: 'none', padding: 0 }}>
        {posts.map((post) => (
          <li
            key={post.id}
            style={{
              padding: '12px',
              borderBottom: '1px solid #eee',
              display: 'flex',
              justifyContent: 'space-between',
              alignItems: 'center',
            }}
          >
            <span>{post.title}</span>
            <button
              onClick={() => handleDelete(post.id)}
              style={{ background: '#ff4d4f', color: '#fff', border: 'none', padding: '4px 8px', borderRadius: '4px', cursor: 'pointer' }}
            >
              Delete
            </button>
          </li>
        ))}
      </ul>
    </div>
  );
}

🛠️ Key Features at a Glance

Standard REST Endpoints: /users, /posts, /comments, /todos.
Smart Pagination: Paginate easily with ?page=1&limit=10 query parameters.
Built-in Try-It Inspector: Test requests directly in your browser with visual status indicators and response payload inspection.
Zero Config: Just replace your API_BASE URL and start fetching.

🚀 Give It a Try

You can start using Playground API today in your frontend apps or test endpoints right inside your browser:

🔗 Live Website & Docs: https://playground-api-xi.vercel.app/

⭐ GitHub Repository: github.com/nileshcodehub/playground_api

What tools do you currently use for mock APIs? Let me know in the comments below! 👇

The Multiple Browser Tab Token Trap: Synchronizing JWT Refresh Across Browser Tabs

Nilesh Kumar — Sat, 25 Jul 2026 18:21:53 +0000

How multiple open browser tabs can accidentally DDOS your auth server, and how to fix it with the Web Locks API.

Picture this: You’ve just shipped a state-of-the-art Axios response interceptor. You implemented a mutex lock (isRefreshing) and a promise queue (failedQueue) to handle concurrent 401 errors. You tested it within a single tab, and it worked like a charm. You gave yourself a high-five and closed your laptop.

Then, a power user logs in.

Like most humans on the internet, they don't use just one browser tab. They open Tab 1 for User Management, Tab 2 for Analytics, Tab 3 for Settings, and Tab 4 for Support Tickets.

Fifteen minutes pass. Their short-lived JWT access token expires.

The user switches back to Tab 1. In the background, all 4 open tabs wake up, detect the expired token, and fire off four independent POST /auth/refresh-token/ requests at the exact same millisecond.

Tab 1 refreshes the token first, but Tab 2's request arrives a millisecond later, invalidates Tab 1's new token, and Tab 3 nukes the session entirely.

Suddenly, all 4 tabs dump the user back to the login screen.

Welcome to the Cross-Tab Token Trap.

1. The Problem: The Multi-Tab Stampede

In modern single-page applications (SPAs), each browser tab operates in its own isolated JavaScript runtime environment. Memory is not shared.

When an access token expires:

isRefreshing = true in Tab A only stops requests inside Tab A.
Tab B has no idea Tab A is currently refreshing a token.
Tab C lives in complete ignorance of Tabs A and B.

Tab A (Memory Space 1) ---> isRefreshing = true ---> POST /auth/refresh-token/ (Token Set 1)
Tab B (Memory Space 2) ---> isRefreshing = true ---> POST /auth/refresh-token/ (Token Set 2 -> Revokes Set 1!)
Tab C (Memory Space 3) ---> isRefreshing = true ---> POST /auth/refresh-token/ (Token Set 3 -> Revokes Set 2!)

If your backend enforces Single-Use Refresh Token Rotation (where using a refresh token revokes all previous ones), multi-tab usage causes immediate session destruction.

😂 Reality Check:
You spent two days building an in-memory queue for single-tab concurrency, only to realize your users treat browser tabs like browser bookmarks.

2. The Investigation: "Works in My Tab" Syndrome

Here is how the discovery unfolded during QA:

⏱️ Timeline of a Cross-Tab Mystery

02:00 PM — "Token refresh logic is bulletproof! Unit tests pass!"
02:15 PM — QA reports: "I got logged out while using the dashboard."
02:20 PM — Developer response: "Works on my machine!"
02:45 PM — QA reveals: "Oh, I had 5 tabs open at once."
03:00 PM — Developer opens Chrome DevTools across 3 separate windows.
03:05 PM — Discovered that 3 separate POST /auth/refresh-token/ requests were firing simultaneously from 3 different tab IDs!

The realization hit hard: In-memory boolean flags cannot cross tab boundaries.

3. The Root Cause: Memory Isolation

JavaScript variables like let isRefreshing = false live inside a single tab's context. When Tab A sets isRefreshing = true, Tab B’s memory remains untouched.

To fix this, we need Cross-Tab Concurrency Control.

We needed a way for Tab B to say:

"Hey browser, is any other tab currently refreshing our auth token? If so, I’ll wait. And once they finish, I’ll just grab the new token they saved in localStorage instead of calling the server again!"

Enter the Web Locks API (navigator.locks).

4. The Technical Solution: The Web Locks API

The Web Locks API is a native browser feature supported in all modern browsers (Chrome 69+, Firefox 96+, Safari 15.4+, Edge).

It allows web pages running in the same origin to request an exclusive lock across tabs.

How Web Locks Solve Cross-Tab Refresh:

Exclusive Lock Request: When a 401 error occurs, a tab requests an exclusive lock named 'auth_token_refresh_lock'.
Automatic Synchronization: If Tab A gets the lock, Tab B and Tab C are paused by the browser until Tab A releases the lock.
Double-Check Pattern: When Tab B finally gets the lock, it checks a tokenRefreshedAt timestamp in localStorage. If Tab A refreshed the token less than 5 seconds ago, Tab B skips the API call entirely and simply reuses Tab A's new token!

Tab A (401) ----> ACQUIRES LOCK 'auth_token_refresh_lock' ----> Fires POST /auth/refresh-token/ ----> Saves token & timestamp to localStorage ----> RELEASES LOCK
                                                                                                                                                 |
Tab B (401) ----> WAITS FOR LOCK ---------------------------------------------------------------------------------------------------------------+----> ACQUIRES LOCK ----> Checks timestamp ----> Token updated recently! ----> Skips API Call & Retries Request

5. The Implementation: Production-Ready Code

Here is how to update your axiosInstance.js to support cross-tab synchronization.

Step 1: Web Lock Helper Function

First, create a helper function that wraps navigator.locks.request with a fallback for legacy browser support:

// src/httpRequest/axiosInstance.js

// Cross-tab lock wrapper using Web Locks API
const runWithCrossTabLock = async (lockName, callback) => {
  if ("locks" in navigator) {
    // Request exclusive lock across all open browser tabs under the same domain
    return navigator.locks.request(lockName, async () => {
      return await callback();
    });
  } else {
    // Fallback for older browsers lacking Web Locks support
    return await callback();
  }
};

// Helper: Check if another tab refreshed the token within the last 5 seconds
const checkIfTokenRefreshedRecently = () => {
  const lastRefreshedAt = localStorage.getItem("tokenRefreshedAt");
  if (!lastRefreshedAt) return false;

  const timeDifference = Date.now() - parseInt(lastRefreshedAt, 10);
  return timeDifference < 5000; // Returns true if refreshed < 5s ago
};

Step 2: Response Interceptor with Cross-Tab Lock

Now, update your response interceptor to utilize cross-tab synchronization:

axiosInstance.interceptors.response.use(
  (response) => response.data,
  async (error) => {
    const originalRequest = error.config;

    // Process 401 Unauthorized errors
    if (error.response?.status === 401 && originalRequest && !originalRequest._retry) {
      const refreshToken = localStorage.getItem("refreshToken");
      const isRefreshRequest = originalRequest.url?.includes(apiRoutes.refreshToken);

      // If no refresh token exists or if the refresh endpoint itself failed, logout
      if (!refreshToken || isRefreshRequest) {
        handleLogout().catch(console.error);
        return Promise.reject(error);
      }

      originalRequest._retry = true;

      // 🔒 CROSS-TAB MUTEX LOCK:
      // Only ONE tab across the entire browser can execute this block at a time.
      return runWithCrossTabLock("auth_token_refresh_lock", async () => {
        const currentAccessToken = localStorage.getItem("accessToken");

        // 1. DOUBLE-CHECK PATTERN:
        // Did another tab refresh the token while we were waiting for the lock?
        if (checkIfTokenRefreshedRecently() && currentAccessToken) {
          // YES! Skip network request, update header, and retry
          originalRequest.headers.Authorization = `Bearer ${currentAccessToken}`;
          return axiosInstance(originalRequest);
        }

        // 2. WE ARE THE FIRST TAB TO GET THE LOCK:
        // Perform the actual network refresh call
        try {
          const route = `${BASE_URL}${apiRoutes.refreshToken}`;
          const response = await axios.post(route, { refresh: refreshToken });
          const { access, refresh } = response.data;

          // Save new tokens and record timestamp for other tabs
          if (access) {
            localStorage.setItem("accessToken", access);
            localStorage.setItem("tokenRefreshedAt", Date.now().toString());
          }
          if (refresh) {
            localStorage.setItem("refreshToken", refresh);
          }

          // Retry original request with new token
          originalRequest.headers.Authorization = `Bearer ${access}`;
          return axiosInstance(originalRequest);
        } catch (refreshError) {
          handleLogout().catch(console.error);
          return Promise.reject(refreshError);
        }
      });
    }

    return Promise.reject(error);
  }
);

6. Before vs. After

Scenario	In-Memory Interceptor (Before)	Web Locks Interceptor (After)
5 Tabs Open simultaneously	5 parallel `POST /auth/refresh-token/` network requests	1 single `POST /auth/refresh-token/` network request
Token Rotation Behavior	Revokes tokens across tabs, forcing full logout	Tab 1 refreshes token; Tabs 2–5 reuse the new token seamlessly
Network Overhead	High API redundancy on multi-tab power users	Zero redundant network calls across tabs
Tab Crash Safety	N/A	If Tab 1 closes mid-refresh, browser automatically unlocks Tab 2

7. Things I Learned

💡 Lesson #1: Web Locks are Tab-Crash Safe
Unlike custom localStorage mutex flags (which stay stuck if a tab closes mid-execution), navigator.locks automatically releases the lock if a tab closes or crashes unexpectedly.

⚠️ Gotcha #2: Always Double-Check After Acquiring a Lock
Acquiring a lock is only half the battle. You MUST inspect shared state (localStorage timestamp) immediately after acquiring the lock to see if the work was already completed by a previous lock holder!

🚀 Improvement #3: Combine with BroadcastChannel for Instantly Synced Logouts
Use new BroadcastChannel('auth_channel') to post a message when a user explicitly logs out in Tab A, so Tab B instantly redirects without waiting for a 401 error!

8. Conclusion

Handling authentication in single-page applications is rarely just about single HTTP calls. Once users open multiple tabs, your frontend becomes a distributed system running on the user's machine.

By combining Axios Interceptors with the Web Locks API, we eliminated cross-tab token refresh race conditions completely—without adding external libraries or complex backend hacks.

Now, your users can open 50 tabs at once, and your application will handle token updates silently like a charm! 🚀

The Hidden Part of Refresh Token Implementation that every developers should know

Nilesh Kumar — Fri, 24 Jul 2026 06:33:06 +0000

What happens when 5 parallel API calls hit for an expired JWT at the exact same millisecond.

Imagine this: You’ve built a sleek, high-performance React dashboard. The UI is sharp, dark mode is gleaming, components are modularized, and React Query is executing parallel data fetches like a grand symphony.

You brew a cup of coffee, open the app after lunch, hit refresh, and… BAM!

You are immediately booted back to the Login screen. No warnings, no friendly error toasts—just a cold, ruthless redirect.

You check your JWT expiration timer. The access token died 5 seconds ago, but your refresh token is valid for another 14 days. So why on earth did your app decide to kick you out like an uninvited party crasher?

Welcome to the chaotic nightmare of Token Refresh Race Conditions in Axios Interceptors.

In this article, we’ll walk through how parallel React queries can accidentally DDOS your own backend, why standard interceptor tutorials fail in production, how we built a promise-queue lock mechanism to solve it, and the subtle "gotcha" lurking in simple error detail checks that almost broke everything anyway.

1. The Problem: The Dashboard Stampede

When a user logs into our app and opens the main dashboard, React Query triggers a stampede of concurrent API requests:

GET /api/teams/users/ (Fetch team members)
GET /api/teams/addresses/ (Fetch locations)
GET /api/auth/profile/ (Fetch user profile)
GET /api/auth/activity/recent/ (Fetch activity log)
GET /api/notifications/ (Fetch unread alerts)

Under normal circumstances, all five requests ride happily on the same valid Bearer <access_token> HTTP header.

React App ---------------------------------------------> Django Backend
          GET /users/        [Bearer valid]  ---> 200 OK
          GET /locations/    [Bearer valid]  ---> 200 OK
          GET /profile/      [Bearer valid]  ---> 200 OK

The Ticking Time Bomb

Fast forward 15 minutes. The short-lived access token expires.

The user clicks on the "Analytics" tab. All 5 queries trigger at the exact same millisecond (T = 0ms).

Instead of sending one token refresh request, updating the token, and retrying the remaining four... all 5 requests fail with 401 Unauthorized simultaneously.

React App ---------------------------------------------> Django Backend
  (T=0ms) GET /users/        [Bearer EXPIRED] ---> 401 Unauthorized
  (T=0ms) GET /locations/    [Bearer EXPIRED] ---> 401 Unauthorized
  (T=0ms) GET /profile/      [Bearer EXPIRED] ---> 401 Unauthorized
  (T=0ms) GET /activity/     [Bearer EXPIRED] ---> 401 Unauthorized
  (T=0ms) GET /notifications/ [Bearer EXPIRED] ---> 401 Unauthorized

Without synchronization, every single failed request wakes up its own Axios error interceptor and independently calls POST /api/auth/refresh-token/.

  (T=5ms) POST /auth/refresh-token/ (Request #1) ---> Generates Token Set A
  (T=6ms) POST /auth/refresh-token/ (Request #2) ---> Invalidates Token Set A!
  (T=7ms) POST /auth/refresh-token/ (Request #3) ---> Invalidates Token Set B!

😂 Reality Check:
Sending 5 concurrent token refresh calls to a server utilizing single-use refresh token rotation is the frontend equivalent of pulling out 5 credit cards at a vending machine, swiping them all in a fraction of a second, and wondering why the bank locked your account for suspicious activity.

Because modern security backends (like Django REST Framework with SimpleJWT or OAuth2 rotation) invalidate the previous refresh token the instant a new one is issued, Request #2 invalidates the token generated by Request #1.

By the time Request #1 tries to retry its original call with Token Set A, the server responds with: "Token revoked!"

The frontend panics, assumes the user’s session is hijacked, clears localStorage, and nukes the user back to /login.

2. The Investigation: Down the DevTools Rabbit Hole

Here is how the debugging session went down:

⏱️ Timeline of a Frontend Meltdown

11:00 AM — "Everything works fine in local dev!" (Famous last words. Token lifetime was set to 24 hours in local .env).
11:30 AM — Lowered ACCESS_TOKEN_LIFETIME to 1 minute to test session persistence.
11:31 AM — Refreshed the page. Got thrown to /login.
11:35 AM — Thinking: "Ah, React Query must be invalidating state too quickly. I'll blame React Query." (React Query was innocent).
11:45 AM — Opened Chrome DevTools Network Tab. Filtered by /refresh-token/.
11:46 AM — SAW FIVE IDENTICAL POST /api/auth/refresh-token/ REQUESTS FIRING IN PARALLEL AT 11:45:02.104ms.
12:00 PM — Realized we lacked an interceptor lock mechanism.
12:30 PM — Added a basic isRefreshing boolean flag.
01:15 PM — App still logged out users randomly.
02:00 PM — Questioned career choices and analyzed the raw JSON response payload from Django REST Framework.

{
  "detail": "Given token not valid for any token type",
  "code": "token_not_valid",
  "messages": [
    {
      "token_class": "AccessToken",
      "token_type": "access",
      "message": "Token is invalid or expired"
    }
  ]
}

That’s when the lightbulb turned on.

3. The Root Cause: Why Naive Interceptors Fail

Most tutorials on YouTube and Medium give you a response interceptor pattern that looks roughly like this:

// ❌ NAIVE INTERCEPTOR PATTERN (DO NOT USE IN PRODUCTION)
let isRefreshing = false;

axiosInstance.interceptors.response.use(
  (response) => response.data,
  async (error) => {
    if (error.response?.status === 401) {
      if (!isRefreshing) {
        isRefreshing = true;
        const newToken = await refreshToken();
        isRefreshing = false;
        return axiosInstance(error.config);
      }
    }
    return Promise.reject(error);
  }
);

Why this naive solution breaks:

It ignores concurrent requests: If Request #1 sets isRefreshing = true and starts fetching a token, Request #2 through #5 hit if (!isRefreshing) which evaluates to false. They immediately fall through to return Promise.reject(error)! Your UI components receive raw 401 errors and crash.
No Request Queue: Requests #2 through #5 need a way to pause execution until Request #1 finishes refreshing, and then retry with Request #1’s newly minted access token.
The SimpleJWT Error Trapping Bug: In DRF / SimpleJWT, an expired access token returns "Given token not valid for any token type". Many frontend codebases check if error.response?.data?.detail contains "token_not_valid" and immediately call logout(), assuming the session is dead!

⚠️ Gotcha:
If your interceptor checks isTokenExpired by matching string error messages returned from access token failures, it will execute handleLogout() before even attempting to refresh! You literally built a feature that logs users out the exact microsecond their token expires.

4. The Technical Solution: Building a Subscriber Queue Lock

To solve token refresh race conditions elegantly, we need three core primitives in our HTTP client:

A Lock Flag (isRefreshing): A mutex boolean preventing multiple refresh network calls.
A Pending Promise Queue (failedQueue): An array holding the resolve and reject handles of all requests that failed while a refresh was in progress.
A Queue Flusher (processQueue): A helper function that executes all pending promises in order once the new access token arrives.

The Architectural Flow

                      +-----------------------------+
                      | Incoming 401 Unauthorized   |
                      +--------------+--------------+
                                     |
                           Is isRefreshing TRUE?
                                 /       \
                               YES        NO
                              /            \
    +----------------------------+      +-------------------------------+
    | Create new pending Promise |      | Set isRefreshing = TRUE       |
    | Push {resolve,reject} to   |      | Call POST /auth/refresh-token |
    | failedQueue array          |      +---------------+---------------+
    +----------------------------+                      |
                                            Did refresh succeed?
                                                  /      \
                                                YES       NO
                                               /           \
                 +-------------------------------+       +----------------------------+
                 | Save access & refresh tokens  |       | Call processQueue(error)  |
                 | Call processQueue(null, token)|       | Reject all queued promises |
                 | Retry original request        |       | Clear localStorage & Logout|
                 +-------------------------------+       +----------------------------+

5. The Code: Implementation Breakdown

Here is our production-ready implementation inside axiosInstance.js.

Step 1: Initialize the Lock & Queue

// src/httpRequest/axiosInstance.js
import axios from "axios";
import apiRoutes from "./apiRoutes";
import { BASE_URL } from "@/utils/constants";

const axiosInstance = axios.create({
  baseURL: BASE_URL,
  headers: { "Content-Type": "application/json" },
});

// Mutex lock flag and promise queue
let isRefreshing = false;
let failedQueue = [];

// Helper to flush the queue when refresh completes or fails
const processQueue = (error, token = null) => {
  failedQueue.forEach((prom) => {
    if (error) {
      prom.reject(error);
    } else {
      prom.resolve(token);
    }
  });

  failedQueue = [];
};

Step 2: Request Interceptor (Attaching the Token)

axiosInstance.interceptors.request.use(
  (config) => {
    const accessToken = localStorage.getItem("accessToken");
    if (accessToken) {
      config.headers.Authorization = `Bearer ${accessToken}`;
    }
    return config;
  },
  (error) => Promise.reject(error)
);

Step 3: Response Interceptor (The Magic Queue Engine)

axiosInstance.interceptors.response.use(
  (response) => response.data,
  async (error) => {
    const originalRequest = error.config;

    // Only process 401 errors that haven't already been retried
    if (error.response?.status === 401 && originalRequest && !originalRequest._retry) {
      const refreshToken = localStorage.getItem("refreshToken");
      const isRefreshRequest = originalRequest.url?.includes(apiRoutes.refreshToken);

      // 🛑 CRITICAL CHECK:
      // If no refresh token exists, OR if the request that failed with 401 WAS the refresh call itself,
      // then the user's session is genuinely dead. Logout immediately.
      if (!refreshToken || isRefreshRequest) {
        if (!window.isLoggingOut) {
          sessionStorage.setItem(
            "logoutMessage",
            JSON.stringify({
              title: "Session Expired",
              message: "Your session has expired. Please login again.",
            })
          );
        }
        handleLogout().catch(console.error);
        return Promise.reject(error);
      }

      // 🔒 QUEUE LOGIC:
      // If a token refresh is already underway, DO NOT fire another API call.
      // Return a pending promise and store its controls in failedQueue.
      if (isRefreshing) {
        return new Promise((resolve, reject) => {
          failedQueue.push({ resolve, reject });
        })
          .then((newToken) => {
            // Update original request authorization header with the new token
            if (newToken) {
              originalRequest.headers.Authorization = `Bearer ${newToken}`;
            }
            return axiosInstance(originalRequest);
          })
          .catch((err) => Promise.reject(err));
      }

      // Mark request as retried and lock the refresh process
      originalRequest._retry = true;
      isRefreshing = true;

      try {
        // Perform a SINGLE token refresh request
        const route = `${BASE_URL}${apiRoutes.refreshToken}`;
        const response = await axios.post(route, { refresh: refreshToken });
        const { access, refresh } = response.data;

        // Persist new tokens
        if (access) localStorage.setItem("accessToken", access);
        if (refresh) localStorage.setItem("refreshToken", refresh);

        // 🔓 UNLOCK QUEUE: Resolve all waiting requests with the new token
        processQueue(null, access);

        // Retry the original request that triggered the 401
        originalRequest.headers.Authorization = `Bearer ${access}`;
        return axiosInstance(originalRequest);
      } catch (refreshError) {
        // If refresh failed, reject all queued promises and wipe session
        processQueue(refreshError, null);

        if (!window.isLoggingOut) {
          sessionStorage.setItem(
            "logoutMessage",
            JSON.stringify({
              title: "Session Expired",
              message: "Your session has expired. Please login again.",
            })
          );
        }
        handleLogout().catch(console.error);
        return Promise.reject(refreshError);
      } finally {
        // Always release lock, even if an unexpected exception occurred
        isRefreshing = false;
      }
    }

    return Promise.reject(error);
  }
);

6. Before vs. After: The Proof in the Metrics

Let's compare the behavior of our frontend application before and after implementing the queueing interceptor architecture:

Metric / Behavior	Naive Interceptor (Before)	Queued Mutex Interceptor (After)
Concurrent 401 Requests	Fires $N$ parallel `POST /auth/refresh-token/` calls	Fires 1 single `POST /auth/refresh-token/` call
Token Rotation Behavior	Invalidates tokens mid-flight, causing random logouts	Gracefully passes single new access token to all subscribers
User Experience	Users randomly dumped to `/login` every 15–30 minutes	Imperceptible transition; active UI components auto-retry seamlessly
Backend Load	DB lock contention on token table during tab switches	Minimal, predictable backend auth load
Error Handling Safety	Leaks unhandled promise rejections on parallel queries	Rejects entire queue cleanly if refresh token is revoked

7. Pro-Level Enhancements: What We Can Improve Next

Even with a working promise queue, software architecture is never "finished." Here are 3 high-value improvements to take this interceptor setup to senior-engineer perfection:

🚀 1. Abstracting Storage Away from `localStorage`

Currently, our interceptor directly queries localStorage.getItem("accessToken").

The Problem: localStorage is vulnerable to XSS attacks and synchronous read bottlenecks.
The Upgrade: Move access tokens into memory (React Context / Auth Singleton) and store refresh tokens in HttpOnly, SameSite Cookies. The browser will send the cookie automatically, removing localStorage reads from Javascript entirely.

🚀 2. Adding a Request Timeout Safeguard to the Queue

The Problem: If the network hangs during the token refresh request, isRefreshing stays true, and queued promises in failedQueue hang forever (memory leak).
The Upgrade: Add an AbortController timeout (e.g., 10 seconds) to the refresh request, auto-rejecting failedQueue if the server fails to respond promptly.

// Timeout Guard Example
const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), 10000);

try {
  const response = await axios.post(route, { refresh }, { signal: controller.signal });
  clearTimeout(timeoutId);
  // ...
} catch (err) {
  clearTimeout(timeoutId);
  processQueue(err, null);
}

🚀 3. Deduplicating Concurrent Token Requests Across Browser Tabs

The Problem: If a user opens 4 browser tabs to your app simultaneously, each tab runs its own JS environment and memory space. isRefreshing in Tab A won't stop Tab B from firing a refresh call!
The Upgrade: Use the BroadcastChannel API or Web Locks API (navigator.locks.request) to coordinate token refresh across multiple browser tabs synchronously!

8. Things I Learned (The Hard Way)

💡 Lesson #1: Never Trust Error Message Strings for Control Flow
Backend error strings like "Given token not valid for any token type" change across library updates. Rely on HTTP status codes (e.g., 401) and route endpoints, not substring matches on error.response.data.detail.

⚠️ Gotcha #2: Don't Forget finally { isRefreshing = false; }
If your token refresh call throws an unexpected error (like a network offline drop) and isRefreshing isn't reset in a finally block, your app will lock up permanently until the user manually reloads the browser.

🚀 Improvement #3: Dynamic Header Replacement in Queued Promises
When a queued request resolves via .then((newToken) => ...), make sure you explicitly set originalRequest.headers.Authorization = 'Bearer ' + newToken. Relying on a global interceptor to read stale state might send the old token a second time!

9. Conclusion

Token refresh handling is one of those deceptively simple features. It sounds like a 20-minute job: "Just catch a 401, refresh the token, and try again!"

Three hours and 47 console.log statements later, you discover queue theory, promise resolution closures, and backend DB locks.

By introducing a dedicated Mutex Lock and Subscriber Queue, we turned a chaotic, user-kicking bug into a silent, rock-solid background process.

The feature eventually worked flawlessly. My confidence needed a quick hotfix, but hey—that’s just another Tuesday in frontend engineering.

Got questions about handling auth state in React Query or Axios? Drop a comment below or connect on GitHub!

The Ultimate Guide to Fixing AppImages on Ubuntu 24.04 LTS

Nilesh Kumar — Sat, 02 May 2026 06:33:28 +0000

If you have recently upgraded to Ubuntu 24.04 (Noble Numbat) or 22.04 LTS, you might have noticed a frustrating trend: your favorite AppImages—like Oodles TimeTracker, Discord, or BalenaEtcher—simply refuse to open. You double-click the file, the loading icon spins for a second, and then... nothing.

This isn't a bug in the applications themselves, but rather a result of Ubuntu’s evolving security architecture and library transitions. In this post, we’ll break down exactly why this happens and provide a permanent, secure fix.

Why AppImages "Break" on Modern Ubuntu

There are three primary culprits behind the "silent failure" of AppImages on newer versions of Ubuntu:

The FUSE 2 vs. FUSE 3 Gap: Ubuntu now ships with FUSE 3. Most older AppImages were built using FUSE 2 (libfuse2). Since these versions are not cross-compatible, the AppImage cannot "mount" itself to run.
AppArmor Restrictions (The 24.04 Factor): Ubuntu 24.04 introduced a security hardening measure that restricts "unprivileged user namespaces." Many apps (especially those built on Electron) require these namespaces for sandboxing. If AppArmor doesn't recognize the app, it kills the process immediately.
Missing Execution Permissions: By default, Linux treats downloaded files as non-executable for security.

Phase 1: The Essential Foundation

Before diving into advanced security profiles, let’s handle the basics.

1. Install the Compatibility Library

You need the library that allows FUSE 2 apps to talk to your modern system.

For Ubuntu 24.04 / 24.10:

sudo apt update && sudo apt install libfuse2t64

For Ubuntu 22.04:

sudo apt update && sudo apt install libfuse2

2. Grant Execution Permissions

The system must be told that this file is allowed to run as a program.

Terminal: chmod +x /path/to/your-app.AppImage
GUI: Right-click the file > Properties > Permissions > Check "Allow executing file as program."

Phase 2: The Pro Fix (AppArmor Profiles)

While you could disable Ubuntu’s security globally using sysctl, that’s like removing your front door lock because your key is sticking. The better way is to create a targeted AppArmor profile for your specific app.

Case Study: Oodles TimeTracker

If you are trying to run Oodles TimeTracker located at /home/nileshkumar/Desktop/Software/, follow these steps:

Create the profile file:

sudo nano /etc/apparmor.d/home.nileshkumar.Desktop.Software.Oodles_TimeTracker

Paste the configuration:

abi <abi/4.0>,
include <tunables/global>

"/home/nileshkumar/Desktop/Software/Oodles TimeTracker-3.0.2.AppImage" flags=(unconfined) {
  userns,
  include if exists <local/home.nileshkumar.Desktop.Software.Oodles_TimeTracker>
}

Load the new rule:

sudo apparmor_parser -r /etc/apparmor.d/home.nileshkumar.Desktop.Software.Oodles_TimeTracker

Phase 3: Integration & Shortcuts

Running apps from the terminal is fine for debugging, but you want your app in the Applications Menu.

Create a .desktop Launcher

Create a launcher file:

nano ~/.local/share/applications/oodles-timetracker.desktop

Paste the following (updating the path to your file):

[Desktop Entry]
Name=Oodles TimeTracker
Comment=Time tracking software
Exec="/home/nileshkumar/Desktop/Software/Oodles TimeTracker-3.0.2.AppImage" --no-sandbox
Terminal=false
Type=Application
Categories=Utility;Office;

Update the database:

update-desktop-database ~/.local/share/applications

Now, you can find the app by pressing the Super (Windows) key and typing "Oodles."

Wait, What is FUSE anyway?

You might be wondering why we had to install libfuse. FUSE (Filesystem in Userspace) is the "magic" that makes AppImages work.

Because an AppImage is a compressed disk image, it needs to be "mounted" so the system can read its files. FUSE allows you to mount these images as a regular user without needing root privileges. It creates a virtual bridge that translates the compressed data into files your OS can execute. When you close the app, FUSE unmounts it and leaves your system clean.

Maintenance & Future Updates

Linux moves fast. Here is how to keep your apps running:

Version Updates: If you download a new version (e.g., v3.0.3), you must update the paths in both your AppArmor profile and your .desktop file.
Location Matters: If you move the AppImage to a different folder, the security profile will break. I recommend keeping all AppImages in a dedicated ~/Applications folder to keep paths consistent.

Conclusion

Ubuntu 24.04’s new security measures might seem like a hurdle, but they are designed to keep the Linux ecosystem safer from exploits. By using AppArmor profiles instead of disabling system-wide protections, you get the best of both worlds: your essential tools running perfectly and a hardened, secure workstation.

Found this helpful? Follow for more Linux workflow optimizations and dev-ops deep dives!

🚀 Supercharge Your React Apps with Event Delegation! ✨

Nilesh Kumar — Sat, 31 May 2025 16:43:32 +0000

Description:
Uncover the magic of Event Delegation in React! Learn how this powerful pattern solves common performance and maintenance headaches in large lists, why React uses it by default, and how to effortlessly retrieve data from clicked elements.

Ever found yourself building a magnificent list of items, perhaps a task manager, an e-commerce catalog, or a simple user table, and then hit a snag? You want each row or item to be interactive – maybe clicking a task marks it complete, or clicking a product takes you to its detail page. Your first instinct, and a perfectly valid one, might be to attach an onClick handler to each and every list item.

// The "Intuitive" (but potentially problematic) way
function TaskItem({ task }) {
  const handleClick = () => {
    console.log(`Task "${task.name}" clicked!`);
    // Do something with task.id
  };

  return (
    <li onClick={handleClick}>
      {task.name}
    </li>
  );
}

function TaskList({ tasks }) {
  return (
    <ul>
      {tasks.map(task => (
        <TaskItem key={task.id} task={task} />
      ))}
    </ul>
  );
}

This works, right? Absolutely! For a small list of 5-10 items, you won't notice a thing. But imagine your list explodes to hundreds, or even thousands, of items. Each <li> now comes with its own baggage: a dedicated event listener.

The Hidden Cost of Too Many Listeners

When you attach an individual event listener to every single element, you're essentially incurring several hidden costs:

Memory Hog: Each event listener consumes a small amount of memory. Multiply that by hundreds or thousands, and your application's memory footprint starts to grow.
Performance Drain (Setup): The browser has to work harder to set up and tear down all these individual listeners. If your list is dynamic (items are frequently added or removed), this overhead can become a significant performance bottleneck.
Code Clutter: While React helps abstract some of this, in vanilla JavaScript, managing numerous individual listeners, especially for dynamically added elements, can quickly lead to messy, hard-to-maintain code.

This is where Event Delegation swoops in like a superhero!

What is Event Delegation? The Magic Behind the Scenes

At its core, Event Delegation is a clever technique that leverages the natural event bubbling mechanism of the DOM (Document Object Model).

Think of event bubbling like this: When you click on a specific element (say, a button inside a list item), the event doesn't just happen on that button and stop. It "bubbles up" – meaning the event is first triggered on the target element, then on its immediate parent, then its grandparent, and so on, all the way up to the document and window objects.

Event Delegation works by attaching a single event listener to a common ancestor (parent) element, instead of attaching individual listeners to each child. When an event occurs on one of the children, it bubbles up to the parent. The parent's listener then "catches" the event and figures out which specific child actually triggered it.

Why React Loves Event Delegation (and you should too!)

One of the coolest things about React is that it employs event delegation under the hood as part of its Synthetic Event System. Even if you write onClick on individual JSX elements, React doesn't attach native DOM event listeners to every single one. Instead, it attaches a single, top-level event listener to the root of your React application (usually the document object or the element where your React app is mounted).

When a DOM event fires, React's synthetic event system intercepts it, normalizes it across different browsers, and then dispatches it to the appropriate React components based on its own internal component tree. This default behavior means React apps often enjoy the performance benefits of event delegation without you having to explicitly set it up for every scenario.

The advantages are clear:

Optimized Performance & Memory: Fewer actual DOM listeners means less memory consumption and faster initial rendering.
Handles Dynamic Content Effortlessly: If you add or remove items from your list, the single delegated listener automatically covers them. No need to manually add or remove listeners!
Cleaner, More Maintainable Code: Centralizing event logic makes your components tidier and easier to debug.

event.target vs. event.currentTarget: Know Your Event Properties!

When an event bubbles up to your delegated listener, the event object (e in e.target) gives you two crucial pieces of information:

e.target: This refers to the exact element that originally triggered the event. If you click a <span> inside a <button>, e.target will be the .
e.currentTarget: This refers to the element to which the event listener is actually attached. If you attached the listener to a <ul>, then e.currentTarget will be the <ul>, regardless of which <li> or its child was clicked.

Understanding this distinction is key to successful event delegation.

The Million-Dollar Question: Getting Each Object on Row Click in Event Delegation

So, you've got your list, you're using event delegation (either implicitly with React or explicitly), and now you need to know which specific item from your array was clicked.

This is where custom data-* attributes come in handy!

The Strategy:

Embed an Identifier: When rendering each item in your array, embed a unique identifier (like id or index) into a data-* attribute on the clickable element (e.g., the
or ).
Retrieve in Handler: In your delegated event handler on the parent, use event.target to get the element that was clicked, and then access its dataset property to retrieve your identifier.
Find the Object: Use that identifier to find the corresponding object in your original data array.

Let's look at some examples:

Example 1: Basic List of Products (Using `data-id`)

Imagine you have an array of product objects:

// dummy data
const products = [
  { id: 'p1', name: 'Laptop', price: 1200 },
  { id: 'p2', name: 'Mouse', price: 25 },
  { id: 'p3', name: 'Keyboard', price: 75 },
];

Here's how you'd set up event delegation to get the clicked product:

// how product list work
function ProductList({ products }) {
  const handleProductClick = (event) => {
    // Traverse up from event.target to find the element with data-product-id
    // This is important because the click might be on a child of the <li>
    const listItem = event.target.closest('li[data-product-id]');

    if (listItem) { // Ensure a list item was actually clicked
      const productId = listItem.dataset.productId; // Access data-product-id
      const clickedProduct = products.find(product => product.id === productId);

      if (clickedProduct) {
        console.log("Clicked product:", clickedProduct);
        // Navigate to product detail page, add to cart, etc.
        // Example: navigate(`/products/${clickedProduct.id}`);
      }
    }
  };

  return (
    <ul onClick={handleProductClick} style={{ cursor: 'pointer' }}>
      {products.map(product => (
        <li key={product.id} data-product-id={product.id} style={{ padding: '8px', borderBottom: '1px solid #eee' }}>
          <h3>{product.name}</h3>
          <p>${product.price}</p>
        </li>
      ))}
    </ul>
  );
}

// Usage in App.js
function App() {
  const myProducts = [
    { id: 'p1', name: 'Laptop', price: 1200 },
    { id: 'p2', name: 'Mouse', price: 25 },
    { id: 'p3', name: 'Keyboard', price: 75 },
    { id: 'p4', name: 'Monitor', price: 300 },
    { id: 'p5', name: 'Webcam', price: 50 },
  ];

  return (
    <div>
      <h1>Our Products</h1>
      <ProductList products={myProducts} />
    </div>
  );
}

Explanation:

We put the onClick handler on the <ul> (the parent).
Each <li> gets a data-product-id attribute, holding its unique product.id.
Inside handleProductClick, we use event.target.closest('li[data-product-id]'). This is a super handy method that looks for the closest ancestor (including itself) that matches the CSS selector. This handles cases where the user clicks on the <h3> or <p> inside the <li>, ensuring we always get the <li> element itself.
Once we have the listItem, we can access listItem.dataset.productId to get our identifier.
Finally, products.find() helps us retrieve the full product object from our original products array.

Example 2: Interactive Table (Using `data-index`)

For tables, using the index can also be a viable option, especially if your data isn't guaranteed to have unique IDs, or if the order is particularly important.

function UserTable({ users }) {
  const handleRowClick = (event) => {
    const tableRow = event.target.closest('tr[data-user-index]');

    if (tableRow) {
      // data-index values are strings, so convert to number
      const userIndex = parseInt(tableRow.dataset.userIndex, 10);
      const clickedUser = users[userIndex]; // Direct access by index

      if (clickedUser) {
        console.log("Clicked user:", clickedUser);
        // Example: show user details modal
      }
    }
  };

  return (
    <table onClick={handleRowClick} style={{ width: '100%', borderCollapse: 'collapse', cursor: 'pointer' }}>
      <thead>
        <tr>
          <th>ID</th>
          <th>Name</th>
          <th>Email</th>
        </tr>
      </thead>
      <tbody>
        {users.map((user, index) => (
          <tr key={user.id} data-user-index={index} style={{ borderBottom: '1px solid #eee' }}>
            <td>{user.id}</td>
            <td>{user.name}</td>
            <td>{user.email}</td>
          </tr>
        ))}
      </tbody>
    </table>
  );
}

// Usage in App.js
function App() {
  const myUsers = [
    { id: 201, name: 'Alice Smith', email: 'alice.s@example.com' },
    { id: 202, name: 'Bob Johnson', email: 'bob.j@example.com' },
    { id: 203, name: 'Charlie Brown', email: 'charlie.b@example.com' },
    { id: 204, name: 'Diana Prince', email: 'diana.p@example.com' },
  ];

  return (
    <div>
      <h1>User Directory</h1>
      <UserTable users={myUsers} />
    </div>
  );
}

Key Difference with `data-index`:

Instead of product.id, we use index (the second argument of map).
We use parseInt() because values from dataset are always strings.
We can directly access the object using users[userIndex] since we stored the array index. This is generally faster than find() but less resilient if the array order changes after rendering.

Example 3: Handling Specific Actions within a Row

What if you have multiple clickable elements within a single row (e.g., "Edit" and "Delete" buttons)? You can still use event delegation!

function ActionList({ items }) {
  const handleItemAction = (event) => {
    const actionButton = event.target.closest('button[data-action]');

    if (actionButton) {
      const itemId = actionButton.dataset.itemId; // Get item ID from button
      const actionType = actionButton.dataset.action; // Get action type (e.g., 'edit', 'delete')

      const targetItem = items.find(item => item.id === itemId);

      if (targetItem) {
        console.log(`Action: ${actionType} on item:`, targetItem);
        // Perform specific action based on actionType
        if (actionType === 'edit') {
          alert(`Editing ${targetItem.name}`);
        } else if (actionType === 'delete') {
          const confirmDelete = window.confirm(`Are you sure you want to delete ${targetItem.name}?`);
          if (confirmDelete) {
            alert(`${targetItem.name} deleted! (simulated)`);
          }
        }
      }
    }
  };

  return (
    <ul onClick={handleItemAction} style={{ listStyle: 'none', padding: 0 }}>
      {items.map(item => (
        <li key={item.id} style={{ border: '1px solid #ccc', margin: '10px 0', padding: '10px' }}>
          <span>{item.name} - Status: {item.status}</span>
          <div style={{ float: 'right' }}>
            {/* Attach item ID to buttons */}
            <button data-item-id={item.id} data-action="edit" style={{ marginRight: '5px' }}>Edit</button>
            <button data-item-id={item.id} data-action="delete">Delete</button>
          </div>
        </li>
      ))}
    </ul>
  );
}

// Usage in App.js
function App() {
  const myItems = [
    { id: 'task1', name: 'Create Blog Post', status: 'In Progress' },
    { id: 'task2', name: 'Schedule Meeting', status: 'Pending' },
    { id: 'task3', name: 'Review PR', status: 'Done' },
  ];

  return (
    <div>
      <h1>Task Management</h1>
      <ActionList items={myItems} />
    </div>
  );
}

Key takeaways from this example:

The onClick is still on the parent <ul>.
Now, the data-item-id is on the buttons themselves, ensuring we know which item the action belongs to.
A new data-action attribute tells us what kind of action to perform.
We use event.target.closest('button[data-action]') to make sure we're getting a button that is intended for an action.
The handler then uses both itemId and actionType to perform the correct logic.

Final Thoughts

Event delegation is a fundamental concept in modern web development, and React embraces it beautifully through its synthetic event system. By understanding how events bubble and how to effectively use event.target and data-* attributes, you can write more performant, maintainable, and elegant React applications, especially when dealing with large, dynamic lists.

So go ahead, refactor those lists, and enjoy the benefits of a smoother, more efficient user experience!

Happy coding!

How to Fix “Permission Denied (publickey)” When Using Git with GitHub on Windows

Nilesh Kumar — Fri, 30 May 2025 20:06:02 +0000

Description:

If you're seeing Permission denied (publickey) when trying to push to GitHub using Git and SSH on Windows, you're not alone. This guide covers every possible cause of the error and walks you through step-by-step solutions using PowerShell, including SSH key generation, agent setup, and GitHub configuration.

🐛 Common Errors and What They Mean

Description: These are typical errors developers face when SSH isn't correctly configured with GitHub.

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Or, when testing the SSH connection:

ssh -T git@github.com
git@github.com: Permission denied (publickey).

Or while starting the SSH agent:

Start-Service : Cannot start service ssh-agent on computer '.'
Error: 1058

✅ Step 1: Check if You Already Have an SSH Key

Description: Check if an SSH key already exists in your system.

Run in PowerShell:

dir $env:USERPROFILE\.ssh
// USERPROFILE: C:Users\Username

Look for files named:

id_ed25519
id_ed25519.pub

If they're missing, proceed to Step 2 to generate them.

🔐 Step 2: Generate a New SSH Key

Description: If you don’t have an SSH key, create one using the command below.

ssh-keygen -t ed25519 -C "your_email@example.com"

Press Enter to accept the default file path.
Optionally set a passphrase (or leave it blank for no passphrase).

This generates two files:

Private key: id_ed25519
Public key: id_ed25519.pub

⚙️ Step 3: Enable and Start the SSH Agent (Properly on Windows)

Description: On Windows, the SSH agent must be enabled and started using PowerShell.

Run these in PowerShell as Administrator:

Set-Service -Name ssh-agent -StartupType Manual
Start-Service ssh-agent

Then add your SSH key:

ssh-add $env:USERPROFILE\.ssh\id_ed25519

You should see:
Identity added: C:\Users\YourName\.ssh\id_ed25519

🔗 Step 4: Add Your SSH Key to GitHub

Description: GitHub must have your public key to allow authentication.

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub

Copy the entire output, which looks like:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIK... user@example.com

Then:

Go to GitHub SSH Keys Settings

Click New SSH key

Title: Something like Windows Dev Machine

Key: Paste the entire key

Click Add SSH key

🧪 Step 5: Test Your SSH Connection to GitHub

Description: This verifies whether your SSH setup is correctly linked to GitHub.

ssh -T git@github.com

Expected output:

Hi your-username! You've successfully authenticated...

🚀 Step 6: Push Your Code

Description: Now that SSH is configured, retry your Git command.

git push -u origin main

If everything is set up correctly, your code should push without issues.

🧾 Summary of All Possible Errors and Fixes

❌ Error	💡 Cause	🛠️ Solution
`Permission denied (publickey)`	GitHub doesn't recognize your SSH key	Add your public key to GitHub
`Could not read from remote repository`	Auth failed or repo not found	Check SSH key, repo URL, and existence
`ssh-agent cannot be started (error 1058)`	Agent service is disabled	Run `Set-Service` and `Start-Service` as Admin
`eval not recognized`	Unix command used in PowerShell	Use PowerShell-native commands instead
`No such file or directory` on `ssh-add`	SSH key doesn’t exist	Generate a new key using `ssh-keygen`

🙋 Troubleshooting Tips

Make sure you're using SSH URLs, not HTTPS.

SSH: git@github.com:username/repo.git ✅
HTTPS: https://github.com/username/repo.git ❌

To see which key is being used, run:

ssh -vT git@github.com

Ensure you’re using the correct GitHub account if you have multiple.

📌 Final Thoughts

SSH configuration on Windows can be tricky, especially if you're used to Unix-based systems. But with the right steps — generating keys, configuring the agent, and adding keys to GitHub — you can be up and running securely in minutes.

Happy coding! 🚀

How to Create Custom Aliases in Vite for Cleaner Imports

Nilesh Kumar — Sun, 16 Feb 2025 03:34:22 +0000

Tired of messy import paths in your React project? Learn how to simplify your code with custom aliases using Vite! ✨

Check out our step-by-step guide to make your imports cleaner and your development faster.

Description

Learn how to set up and optimize Vite for your React projects! This guide covers everything from integrating React with SWC for faster builds to configuring custom aliases. Follow along with practical examples to supercharge your development workflow.

A Step-by-Step Guide

Vite has quickly become a favourite among developers for building fast and efficient React applications. In this guide, we’ll explore how to set up a powerful Vite configuration tailored for React projects. We’ll cover everything from integrating React with SWC for faster builds, defining custom aliases, and optimizing the development experience. Let's dive in!

Why Use Vite with React?

Vite is a next-generation frontend build tool that is extremely fast and efficient. When combined with React and SWC (a super-fast JavaScript/TypeScript compiler), it significantly speeds up development and build times. Here’s why you should consider using Vite with React:

Lightning-fast HMR (Hot Module Replacement): Instant updates without reloading the whole page.
Faster Builds: Thanks to its modern architecture and SWC integration.
Enhanced Developer Experience: With easy configuration and plugin support.

Before

// src/components/Message.jsx
// src/assets/logo.png
import React from 'react';
import Logo from './../assets/logo.png';
import Message from './../components/Message';

const HelloWorld = () => {
  return (
    <div>
      <img src={Logo} alt="Logo" />
      <h1><Message /></h1>
    </div>
  );
};

export default HelloWorld;

After

// src/components/Message.jsx
// src/assets/logo.png
import React from 'react';
import Logo from 'src/assets/logo.png';
import Message from 'src/components/Message';

const HelloWorld = () => {
  return (
    <div>
      <img src={Logo} alt="Logo" />
      <h1><Message /></h1>
    </div>
  );
};

export default HelloWorld;

Getting Started

Before we begin, ensure you have Node.js and npm installed on your system. If not, download them from nodejs.org.

Step 1: Initialize a Vite Project

To get started with Vite and React, run the following command:

npm create vite@latest my-react-app --template react
cd my-react-app
npm install

This sets up a React project using Vite. Now, let’s configure it to make development faster and easier.

Configuring Vite for React

Below is a complete vite.config.js configuration tailored for React projects:

import path from "path";
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react-swc";

export default defineConfig({
  base: "/",
  plugins: [react()],
  resolve: {
    alias: [
      {
        find: /^~(.+)/,
        replacement: path.resolve(process.cwd(), "node_modules/$1"),
      },
      {
        find: /^src(.+)/,
        replacement: path.resolve(process.cwd(), "src/$1"),
      },
    ],
  },
  server: {
    port: 3031,
  },
  preview: {
    port: 3031,
  },
  build: {
    sourcemap: true,
  },
});

Breaking Down the Configuration

1. React with SWC

import react from "@vitejs/plugin-react-swc";

We are using @vitejs/plugin-react-swc to compile React faster using SWC. It’s a great alternative to Babel because of its blazing-fast speed.

2. Custom Aliases

To make imports cleaner and avoid lengthy relative paths, we define custom aliases:

resolve: {
  alias: [
    {
      find: /^~(.+)/,
      replacement: path.resolve(process.cwd(), "node_modules/$1"),
    },
    {
      find: /^src(.+)/,
      replacement: path.resolve(process.cwd(), "src/$1"),
    },
  ],
},

~ is used to access modules from node_modules.
src is used to access files from the src directory.

Example Usage:

import MyComponent from 'src/components/MyComponent';

3. Custom Server Port

server: {
  port: 3031,
},
preview: {
  port: 3031,
},

We’ve set the development and preview servers to use port 3031. Feel free to change it to any port you prefer.

4. Source Maps for Easier Debugging

build: {
  sourcemap: true,
},

Enabling source maps helps in debugging by allowing you to see the original source code in the browser’s developer tools.

Installing Dependencies

To use this configuration, install the necessary packages:

npm install @vitejs/plugin-react-swc vite-plugin-checker

Running the Project

After setting up the configuration, you can run the development server with:Running the Project

npm run dev

Open your browser and navigate to http://localhost:3031.

Conclusion

Congratulations! You’ve now mastered configuring Vite for React with:

React and SWC for faster builds.
ESLint integration for consistent code quality.
Custom aliases for cleaner imports.
A custom server port and source maps for better debugging.

This configuration makes development faster, cleaner, and more enjoyable. Experiment with additional plugins and settings to tailor it further to your needs!

Final Thoughts

Vite is revolutionizing frontend development with its speed and simplicity. By combining it with React and SWC, you get the best of both worlds. Use this guide to set up your projects and boost your productivity.

Happy Coding! 🚀

Without JWT Library Decode and Verify a JWT Token in JavaScript

Nilesh Kumar — Fri, 07 Feb 2025 17:36:57 +0000

Description

JSON Web Tokens (JWT) are widely used for authentication, but just decoding them is not enough—you need to verify their signature too. In this blog, we’ll break down how to decode a JWT and verify its signature using JavaScript, all in simple terms.

🔍 What is a JWT?

A JWT (JSON Web Token) is a compact, URL-safe token used for securely transmitting information. It has three parts:

HEADER.PAYLOAD.SIGNATURE

Example JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiIxMjM0NSIsIm5hbWUiOiJKb2huIERvZSIsImV4cCI6MTcxNjAwMDAwMH0.ZXhhbXBsZXNpZ25hdHVyZQ

Header → Metadata about the token (e.g., algorithm used: HS256)
Payload → Data like user ID, roles, and expiration time (exp)
Signature → A secret-key-based hash to verify authenticity

Without verifying the signature, anyone can modify a JWT, which is a security risk! 😱

📌 Step 1: Decode the JWT in JavaScript

Before verifying a JWT, let's first decode it to extract the payload (the actual data inside the token).

🚀 JavaScript Code to Decode JWT

function jwtDecode(token) {
  try {
    const base64Url = token.split(".")[1];
    const base64 = base64Url.replace(/-/g, "+").replace(/_/g, "/");
    const jsonPayload = decodeURIComponent(
      window
        .atob(base64)
        .split("")
        .map((c) => `%${`00${c.charCodeAt(0).toString(16)}`.slice(-2)}`)
        .join("")
    );

    const decoded = JSON.parse(jsonPayload);

    // Check if token has expired
    if (decoded.exp) {
      const currentTime = Math.floor(Date.now() / 1000);
      if (decoded.exp < currentTime) {
        console.warn("Token has expired!");
        return null;
      }
    }

    return decoded;
  } catch (error) {
    console.error("Invalid JWT token", error);
    return null;
  }
}

🔹 How It Works?

Splits the token into three parts and extracts the payload (middle part).
Converts Base64 URL-safe encoding into a normal Base64 string.
Decodes it into a readable JSON object.
Checks if the token has expired using the exp field.

🔴 Problem: This does not verify the signature, so anyone could tamper with the payload! 🚨

📌 Step 2: Verify the JWT Signature

To ensure the token is authentic and not modified, we need to verify its signature using a secret key (e.g., "test").

✅ JavaScript Code to Verify JWT Signature

async function jwtVerify(token, secret = "test") {
  try {
    const parts = token.split(".");
    if (parts.length !== 3) throw new Error("Invalid JWT format");

    const [headerB64, payloadB64, signatureB64] = parts;
    const header = JSON.parse(atob(headerB64));
    const payload = JSON.parse(atob(payloadB64));

    const currentTime = Math.floor(Date.now() / 1000);
    if (payload.exp && payload.exp < currentTime) {
      console.warn("Token has expired!");
      return null;
    }

    const encoder = new TextEncoder();
    const keyData = encoder.encode(secret);
    const cryptoKey = await crypto.subtle.importKey("raw", keyData, { name: "HMAC", hash: "SHA-256" }, false, ["sign"]);

    const data = encoder.encode(`${headerB64}.${payloadB64}`);
    const newSignature = await crypto.subtle.sign("HMAC", cryptoKey, data);
    const newSignatureB64 = btoa(String.fromCharCode(...new Uint8Array(newSignature)))
      .replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/, "");

    if (newSignatureB64 !== signatureB64) {
      throw new Error("Invalid signature! JWT is not authentic.");
    }

    return payload;
  } catch (error) {
    console.error("JWT Verification Failed:", error.message);
    return null;
  }
}

🔹 How It Works?

Splits the JWT into three parts: Header, Payload, Signature.
Decodes Header & Payload to JSON format.
Checks expiration time (exp field).
Recreates the signature using HMAC-SHA256 and compares it with the original signature.
✅ If valid, returns decoded payload. Otherwise, it rejects the token.

🔬 Example Usage

const token = "YOUR_JWT_HERE"; // Replace with an actual JWT
jwtVerify(token).then((decoded) => {
  if (decoded) {
    console.log("✅ Valid Token:", decoded);
  } else {
    console.log("❌ Invalid or Expired Token.");
  }
});

🎯 Summary

Step	Action	Code
1️⃣	Decode JWT	Extracts and reads payload (unsafe on its own)
2️⃣	Verify Signature	Ensures token authenticity using a secret key (HMAC-SHA256)
3️⃣	Check Expiration	Rejects expired tokens (via `exp` field)

🔹 Always verify the signature before trusting a JWT!

💡 Final Thoughts

✅ JWTs are great for authentication, but decoding alone is not safe. Always verify the signature before accepting a token!

🔒 Want even better security? Use jsonwebtoken in Node.js:

const jwt = require("jsonwebtoken");
jwt.verify(token, "test");

Learning Node.js with Express.js: A Day-by-Day Guide

Nilesh Kumar — Sun, 26 Jan 2025 06:49:22 +0000

Learning Node.js with Express.js: A Day-by-Day Guide

This document outlines a detailed day-by-day learning path to understand and practice Node.js with Express.js. By the end of the guide, you'll have created a project with login and signup functionality, including password hashing and token management.

Day 1: Introduction to Node.js

Topics:

What is Node.js and why use it?
Installing Node.js and npm
Understanding the Node.js runtime
Exploring Node.js modules and npm packages

Exercises:

Install Node.js and verify the installation with node -v and npm -v.
Create a "Hello World" application using Node.js.

Code:

// hello.js
console.log('Hello, World!');

// Run using: node hello.js

Explore the fs and path modules with small examples.

Code:

const fs = require('fs');
const path = require('path');

// Create a file
fs.writeFileSync('example.txt', 'This is an example');

// Read the file
const data = fs.readFileSync('example.txt', 'utf-8');
console.log(data);

// Get file path info
console.log(path.basename('example.txt'));

Day 2: Setting Up Express.js

Topics:

Introduction to Express.js
Setting up a basic Express application
Understanding middleware and routes

Exercises:

Install Express.js using npm.

Command:

npm install express

Create a basic Express.js server with a "Hello World" route.

Code:

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello World!');
});

const PORT = 3000;
app.listen(PORT, () => {
  console.log(`Server running on http://localhost:${PORT}`);
});

Explore middleware by adding custom logging and error-handling middleware.

Code:

// Custom logging middleware
app.use((req, res, next) => {
  console.log(`${req.method} ${req.url}`);
  next();
});

// Error-handling middleware
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).send('Something broke!');
});

Day 3: Routing and API Basics

Topics:

Understanding routes in Express.js
HTTP methods: GET, POST, PUT, DELETE
Using query parameters and route parameters

Exercises:

Create routes for basic CRUD operations.

Code:

app.get('/items', (req, res) => res.json({ message: 'Get all items' }));
app.post('/items', (req, res) => res.json({ message: 'Create an item' }));
app.put('/items/:id', (req, res) => res.json({ message: `Update item ${req.params.id}` }));
app.delete('/items/:id', (req, res) => res.json({ message: `Delete item ${req.params.id}` }));

Build an API endpoint to return JSON data.

Code:

app.get('/api/data', (req, res) => {
  res.json({ id: 1, name: 'Example Item' });
});

Use Postman or a similar tool to test your routes.

Day 4: Working with Middleware

Topics:

Built-in middleware in Express.js
Third-party middleware (e.g., body-parser, cors)
Writing custom middleware

Exercises:

Use body-parser to parse incoming request bodies.

Code:

const bodyParser = require('body-parser');
app.use(bodyParser.json());

Add cors to your application for handling cross-origin requests.

Code:

const cors = require('cors');
app.use(cors());

Write a custom middleware function for logging request details.

Code:

app.use((req, res, next) => {
  console.log(`[${new Date().toISOString()}] ${req.method} ${req.url}`);
  next();
});

Day 5: Connecting to a Database (MongoDB)

Topics:

Introduction to MongoDB and Mongoose
Connecting your Node.js application to MongoDB
Defining and using schemas and models

Exercises:

Set up a local MongoDB instance or use MongoDB Atlas.
Install Mongoose and connect it to your MongoDB database.

Code:

const mongoose = require('mongoose');

mongoose.connect('mongodb://localhost:27017/mydatabase', {
  useNewUrlParser: true,
  useUnifiedTopology: true,
});

mongoose.connection.once('open', () => {
  console.log('Connected to MongoDB');
});

Create a schema and model for user data.

Code:

const userSchema = new mongoose.Schema({
  email: String,
  password: String,
});

const User = mongoose.model('User', userSchema);
module.exports = User;

Day 6: Password Hashing with bcrypt

Topics:

Why hash passwords?
Using the bcrypt library to hash and compare passwords

Exercises:

Install the bcrypt library.

Command:

npm install bcrypt

Create a function to hash a password before saving it to the database.

Code:

const bcrypt = require('bcrypt');

const hashPassword = async (password) => {
  const salt = await bcrypt.genSalt(10);
  return await bcrypt.hash(password, salt);
};

// Usage
const hashedPassword = await hashPassword('mypassword');

Write a function to compare hashed passwords during login.

Code:

const isMatch = await bcrypt.compare('mypassword', hashedPassword);
console.log(isMatch); // true or false

Day 7: Token Management with JWT

Topics:

Introduction to JSON Web Tokens (JWT)
Creating and verifying JWTs
Storing and using tokens for authentication

Exercises:

Install the jsonwebtoken library.

Command:

npm install jsonwebtoken

Create a function to generate a token after a successful login.

Code:

const jwt = require('jsonwebtoken');

const generateToken = (userId) => {
  return jwt.sign({ id: userId }, process.env.JWT_SECRET, { expiresIn: '1h' });
};

const token = generateToken('12345');
console.log(token);

Add middleware to verify tokens for protected routes.

Code:

app.use((req, res, next) => {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ message: 'Unauthorized' });

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    req.user = decoded;
    next();
  } catch (err) {
    res.status(401).json({ message: 'Invalid token' });
  }
});

Day 8: Creating the Login and Signup Features

Topics:

Building the signup route
Building the login route
Validating user input

Exercises:

Create a /signup route to register users and save hashed passwords.

Code:

app.post('/signup', async (req, res) => {
  const { email, password } = req.body;
  const hashedPassword = await hashPassword(password);

  const user = new User({ email, password: hashedPassword });
  await user.save();
  res.status(201).json({ message: 'User registered successfully' });
});

Create a /login route to authenticate users and return a token.

Code:

app.post('/login', async (req, res) => {
  const { email, password } = req.body;
  const user = await User.findOne({ email });

  if (!user || !(await bcrypt.compare(password, user.password))) {
    return res.status(401).json({ message: 'Invalid credentials' });
  }

  const token = generateToken(user._id);
  res.json({ token });
});

Add input validation using a library like express-validator.

Code:

const { body, validationResult } = require('express-validator');

app.post(
  '/signup',
  [body('email').isEmail(), body('password').isLength({ min: 6 })],
  async (req, res) => {
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
      return res.status(400).json({ errors: errors.array() });
    }

    const { email, password } = req.body;
    const hashedPassword = await hashPassword(password);
    const user = new User({ email, password: hashedPassword });
    await user.save();
    res.status(201).json({ message: 'User registered successfully' });
  }
);

The added code examples provide practical steps for each learning topic, ensuring hands-on practice throughout the journey.

How to Search Amazon Products Using Node.js and Amazon PA-API

Nilesh Kumar — Tue, 17 Dec 2024 18:10:44 +0000

Description

Learn how to set up and use the Amazon Product Advertising API (PA-API) in a Node.js project to search for products, retrieve details like price and reviews, and make your affiliate marketing easier.

Introduction

Amazon's Product Advertising API (PA-API) is a powerful tool that lets developers access product information directly from Amazon's marketplace. In this blog, we’ll walk through a simple Node.js example to search for products on Amazon and retrieve useful details like price, title, images, and customer reviews.

If you’re an Amazon associate or a developer building a product search tool, this tutorial will help you get started with PA-API in no time.

Step-by-Step Guide

1. Prerequisites

Before starting, ensure you have the following:

Node.js installed on your computer.
An active Amazon Associates account with access to the Product Advertising API.
API credentials: Access Key, Secret Key, and Partner Tag.

Where to get the these API credentials
Generate API credentials

You can also test your api credentials online using these list.
List of all Web Services

2. Setting Up Your Node.js Project

Initialize Your Project

Run the following command in your terminal:
```
npm init -y
```
This creates a package.json file to manage project dependencies.
Install the Required Library

Use the amazon-paapi package to interact with the API:
```
npm install amazon-paapi
```
Secure Your API Keys

Instead of hardcoding sensitive data (like API keys) in your code, store them in an .env file using the dotenv package:
```
npm install dotenv
```
Create a Project Structure

Here’s how you can organize your files:

3. Writing the Code

Configure API Parameters

In the config/amazonConfig.js file, define your API keys and search parameters:

require('dotenv').config();  
const commonParameters = {
    AccessKey: process.env.ACCESS_KEY,
    SecretKey: process.env.SECRET_KEY,   
    PartnerTag: process.env.PARTNER_TAG,   
    Marketplace: process.env.MARKETPLACE,   
    PartnerType: 'Associates', 
};  
const requestParameters = {   
    Keywords: 'Harry Potter',   
    SearchIndex: 'Books',   
    ItemCount: 2,   
    Resources: [     
        'Images.Primary.Medium',     
        'ItemInfo.Title',     
        'Offers.Listings.Price',     
        'CustomerReviews.Count',     
        'CustomerReviews.StarRating',   
    ], 
};  
module.exports = { commonParameters, requestParameters };

Call the Amazon API

In the index.js file, make the API call using the amazon-paapi package:

const amazonPaapi = require('amazon-paapi'); 
const { commonParameters, requestParameters } = require('./config/amazonConfig');  
const fetchProduct = async () => {   
    try {     
        const data = await amazonPaapi.SearchItems(commonParameters, requestParameters);     
        console.log(JSON.stringify(data, null, 2));   
    } catch (error) {     
        console.error('Error:', error);   
    } 
};  
fetchProduct();

Store Your Keys in the .env File

Create a .env file in the project root to securely store your API credentials:

ACCESS_KEY=your-access-key-here 
SECRET_KEY=your-secret-key-here 
PARTNER_TAG=your-partner-tag-here 
MARKETPLACE=www.amazon.com

4. Running Your Project

Run the code using the command:
```
node index.js
```
If everything is set up correctly, the API will fetch details for "Harry Potter" books and display them in the console.

What This Code Does

Defines API Credentials

The API keys, marketplace, and associate tag are set up using environment variables for security.
Searches for Products

The SearchItems function fetches product details based on the keyword "Harry Potter."
Retrieves Product Details

Information such as product title, price, images, and reviews is retrieved from Amazon.

Conclusion

Using the Amazon Product Advertising API in Node.js is straightforward when you have the right tools and setup. This example showed how to search for products, fetch specific details, and handle API responses. By using this approach, you can build robust affiliate applications, product comparison tools, or even a custom storefront!

DEV Community: Nilesh Kumar

🚀 Mock APIs Evolved: GraphQL Gateway, Fake JWT Auth, Dynamic Custom Collections & TypeScript SDKs in Playground API v3

🆕 What’s New in Playground API v3.0?

🕸️ 1. GraphQL Sandbox Gateway (/graphql)

GraphQL Query Example:

GraphQL Stateful Mutation Example:

🔑 2. Fake JWT Authentication Simulation (/auth)

📦 3. Dynamic Custom Resource Collections (/custom/:collection)

🖼️ 4. Built-in Dynamic SVG Avatars & Image Placeholders (/public/avatars/:seed)

📘 5. Full TypeScript Definitions & SDK Types (/types/ts)

💾 6. Session Snapshot Export & Import (JSON)

🏗️ 7. Decoupled Architecture (playground_api_fe & playground_api_be)

⚛️ Updated React Example: Combining GraphQL, JWT Auth & Latency Simulation

📊 Complete Feature Matrix: v1 vs v2 vs v3

🔗 Try It Out & Get Involved!

🚀 Mock APIs Just Got an Upgrade: Network Delay Simulation, Error Testing & Postman Exports in Playground API v2

🆕 What’s New in Playground API v2.0?

⏱️ 1. Network Delay Simulation (?_delay & X-Simulate-Delay)

🚨 2. HTTP Error Simulation (?_status & X-Simulate-Status)

🔗 3. Relational Sub-Resources & Nested Filtering

🔍 4. Universal Full-Text Search (?q=) & Dynamic Sorting (?_sort)

🛡️ 5. E2E Test Suite Ready (X-Playground-Identity) & Programmatic Reset

📦 6. Multi-Format Collection & Schema Downloads

💻 7. 9-Language Live Code Generators

⚛️ Updated React Example: Skeleton Loader + Error Handling + Delay Simulation

📊 Summary: v1 vs v2 Comparison

🔗 Try It Out & Support the Project

Stop Faking Your Mock APIs: Introducing Playground API 🚀

⚡ What is Playground API?

🆚 Traditional Mocks vs. Local Servers vs. Playground API

⚛️ How to Use Playground API in a React App

🛠️ Key Features at a Glance

🚀 Give It a Try

The Multiple Browser Tab Token Trap: Synchronizing JWT Refresh Across Browser Tabs

1. The Problem: The Multi-Tab Stampede

2. The Investigation: "Works in My Tab" Syndrome

⏱️ Timeline of a Cross-Tab Mystery

3. The Root Cause: Memory Isolation

4. The Technical Solution: The Web Locks API

How Web Locks Solve Cross-Tab Refresh:

5. The Implementation: Production-Ready Code

Step 1: Web Lock Helper Function

Step 2: Response Interceptor with Cross-Tab Lock

6. Before vs. After

7. Things I Learned

8. Conclusion

The Hidden Part of Refresh Token Implementation that every developers should know

What happens when 5 parallel API calls hit for an expired JWT at the exact same millisecond.

1. The Problem: The Dashboard Stampede

The Ticking Time Bomb

2. The Investigation: Down the DevTools Rabbit Hole

⏱️ Timeline of a Frontend Meltdown

3. The Root Cause: Why Naive Interceptors Fail

Why this naive solution breaks:

4. The Technical Solution: Building a Subscriber Queue Lock

The Architectural Flow

5. The Code: Implementation Breakdown

Step 1: Initialize the Lock & Queue

Step 2: Request Interceptor (Attaching the Token)

Step 3: Response Interceptor (The Magic Queue Engine)

6. Before vs. After: The Proof in the Metrics

7. Pro-Level Enhancements: What We Can Improve Next

🚀 1. Abstracting Storage Away from localStorage

🚀 2. Adding a Request Timeout Safeguard to the Queue

🚀 3. Deduplicating Concurrent Token Requests Across Browser Tabs

8. Things I Learned (The Hard Way)

9. Conclusion

The Ultimate Guide to Fixing AppImages on Ubuntu 24.04 LTS

Why AppImages "Break" on Modern Ubuntu

Phase 1: The Essential Foundation

1. Install the Compatibility Library

2. Grant Execution Permissions

Phase 2: The Pro Fix (AppArmor Profiles)

Case Study: Oodles TimeTracker

Phase 3: Integration & Shortcuts

Create a .desktop Launcher

Wait, What is FUSE anyway?

Maintenance & Future Updates

Conclusion

🚀 Supercharge Your React Apps with Event Delegation! ✨

🕸️ 1. GraphQL Sandbox Gateway (`/graphql`)

🔑 2. Fake JWT Authentication Simulation (`/auth`)

📦 3. Dynamic Custom Resource Collections (`/custom/:collection`)

🖼️ 4. Built-in Dynamic SVG Avatars & Image Placeholders (`/public/avatars/:seed`)

📘 5. Full TypeScript Definitions & SDK Types (`/types/ts`)

🏗️ 7. Decoupled Architecture (`playground_api_fe` & `playground_api_be`)

⏱️ 1. Network Delay Simulation (`?_delay` & `X-Simulate-Delay`)

🚨 2. HTTP Error Simulation (`?_status` & `X-Simulate-Status`)

🔍 4. Universal Full-Text Search (`?q=`) & Dynamic Sorting (`?_sort`)

🛡️ 5. E2E Test Suite Ready (`X-Playground-Identity`) & Programmatic Reset

🚀 1. Abstracting Storage Away from `localStorage`

Example 1: Basic List of Products (Using `data-id`)

Example 2: Interactive Table (Using `data-index`)

Key Difference with `data-index`: