DEV Community: Sushant Rahate

What Did Earth Look Like When You Were Born? I Built It to Find Out

Sushant Rahate — Sun, 19 Apr 2026 18:52:20 +0000

🌍 I Built a Climate Time Machine That Makes CO₂ Data Feel Personal

This is a submission for Weekend Challenge: Earth Day Edition

The problem with climate data is that it's abstract. "+1.25°C" doesn't land. "427 ppm CO₂" doesn't hurt. Numbers don't move people — stories do.

So I asked a different question: what if you could see exactly what the planet looked like the year you were born?

That's Earth Time Machine. Enter your birth year. Feel what changed.

What I Built

Earth Time Machine is an interactive climate data experience that makes global warming feel personally relevant by anchoring every metric to your birth year.

The core idea

Instead of showing abstract global averages, it asks: what was CO₂ when you were born? How much Arctic ice existed? How many more people share this planet now? Every number becomes a story about your lifetime.

Features

🌐 Animated 3D globe in the hero — hand-coded in Canvas 2D, no WebGL library. The globe visibly browns and cracks based on the CO₂ rise since your birth year. Born in 1960? Healthy green oceans. 2008? Noticeably warmer.
💨 CO₂ breathing animation — the number counts up from zero to your lifetime rise, then locks and pulses gently like Earth exhaling. No looping. It arrives and stays.
📊 6 planetary vital sign cards — CO₂, temperature, Arctic sea ice, forest cover, population, sea level. Each has a sparkline, animated thermometers, comparison bars, and a "sting" — a one-line gut-punch fact that reveals after you've absorbed the numbers.
🌍 20-country local data — select your country and see local warming vs world average, per-capita CO₂ then vs now, and your country's climate risk tier. India's local warming hits differently than Canada's.
🔮 4 IPCC scenario projections to 2100 — actual path, Paris 1.5°C, moderate action, worst case. Canvas-drawn chart showing where each path leads. Interactive tabs with verdicts.
🌿 Paris Path toggle — overlays what values should be if the Paris Agreement was met. The gap is sobering.
🎮 Generational compare mode — enter two birth years, see the CO₂ absorbed between them, the temperature difference, the ice lost. Perfect for showing a parent vs child what Earth each of them inherited.
🎯 Climate knowledge quiz — 4 randomised questions from a pool of 8. Immediate feedback, score bar, explanations. Keeps people engaged after the data shock.
🔊 Ambient sound — two sine-wave oscillators through the Web Audio API. As you drag the year scrubber, the pitch shifts — deeper in early decades, eerier as CO₂ rises. Subtle but effective.
📥 Download your Earth Identity Card as PNG via html2canvas. Share your personal climate report on social media.
🌐 Live CO₂ clock in the sticky toolbar — ticks upward in real time at the actual rate (2.4 ppm/year). Watch it move.

Demo

🔗 https://earth-time-machine.vercel.app/

Try entering:

1960 — see a relatively healthy planet, then watch how much changed
1990 — the year of the Earth Summit, Rio. CO₂ was already rising fast
2005 — the year Arctic ice hit a then-record low

Drag the year scrubber slowly from 1950 to 2026. Watch the CO₂ pill change. Listen to the drone shift. Find 2007 — the year the Arctic shattered its record.

Code

sushantrahate / earth-time-machine

🌍 Earth Time Machine

What did Earth look like when you were born?

Enter your birth year and see exactly how the planet changed in your lifetime — CO₂ levels, temperature rise, Arctic ice loss, forest cover, sea level rise, and more. Every number anchored to your life, not abstract history.

Live: https://earth-time-machine.vercel.app/

Article: https://dev.to/sushantrahate/what-did-earth-look-like-when-you-were-born-i-built-it-to-find-out-3i8i

Built With

React 19 + Vite 6
Tailwind CSS v4
Canvas 2D API (globe + charts)
Web Audio API (ambient sound)

Run Locally

git clone https://github.com/sushantrahate/earth-time-machine.git
cd earth-time-machine
npm install
npm run dev

Submission

Built for the DEV Weekend Challenge: Earth Day Edition 2026.

View on GitHub

Built with:

React 19 + Vite 6
Tailwind CSS v4 (single @import "tailwindcss" — no config file)
Canvas 2D for the globe and all charts (no chart library)
Web Audio API for ambient sound
html2canvas for PNG card export

Zero external data dependencies. All climate datasets (CO₂, TEMP, ICE, POP, FOREST, SEA) are bundled from NOAA, NASA GISTEMP, NSIDC, FAO, and UN World Population Prospects.

How I Built It

The globe

The hardest part was making the hero globe look like Earth — not a red blob, not random ellipses.

The breakthrough was switching from position: absolute painted ellipses to actual spherical projection math. Each continent is defined as a series of [lat, lon] pairs. A project(lat, lon, t) function maps them onto the 2D canvas using:

function project(lat, lon, t) {
  const phi    = (lat * Math.PI) / 180;
  const lam    = (lon * Math.PI) / 180 + t * 0.35; // t = spin time
  const cosLat = Math.cos(phi);
  const x3d    = cosLat * Math.sin(lam);
  const y3d    = Math.sin(phi);
  const z3d    = cosLat * Math.cos(lam);
  if (z3d < -0.05) return null; // back-face cull
  return [cx + x3d * r, cy - y3d * r];
}

Back-face culling (z3d < -0.05) means continents on the far side of the globe simply don't draw. The spin is smooth because t increments 0.008 per frame via requestAnimationFrame.

The heat factor maps CO₂ rise since your birth year onto a 0 → 0.58 value that shifts:

Ocean colour (vivid blue → murky)
Land colour (forest green → reddish-brown)
Ice cap size (large → tiny)
Atmosphere halo (blue-cyan → dimmer)

let heat = 0;
if (birthYear > 0) {
  const rise = interp(CO2, 2026) - interp(CO2, birthYear);
  heat = Math.min(rise / 90, 0.58);
}

The CO₂ number

The original version looped through seasonal offsets forever, making the number tick up and down endlessly. That felt anxious and wrong.

The fix: count up once with a cubic ease-out, then lock the value and add a pure CSS pulse — no more JS interval touching the text:

const tick = (now) => {
  const p    = Math.min((now - start) / 1800, 1);
  const ease = 1 - Math.pow(1 - p, 3);
  el.textContent = `+${(target * ease).toFixed(1)}`;
  if (p < 1) requestAnimationFrame(tick);
  else {
    el.textContent = `+${target.toFixed(1)}`; // locked
    el.classList.add('breathing');             // CSS pulse only
  }
};

@keyframes co2Breathe {
  0%, 100% { transform: scale(1);      filter: drop-shadow(0 0 0px rgba(192,64,48,0)); }
  50%       { transform: scale(1.028); filter: drop-shadow(0 0 18px rgba(192,64,48,.45)); }
}

Gentle, readable, and the number never changes again.

Sound design

Web Audio API is blocked until a user gesture (browser policy). The fix is audioCtx.resume() which returns a Promise — you must wait for it:

const toggle = () => {
  ctx.resume().then(() => {
    gain.gain.cancelScheduledValues(ctx.currentTime);
    gain.gain.setTargetAtTime(0.6, ctx.currentTime, 0.4);
    updatePitch(CO2[2026]);
  });
};

Two oscillators detuned by 2.5Hz create a warm beating effect. As the year scrubber moves, setTargetAtTime glides the frequency smoothly rather than jumping:

function updatePitch(co2) {
  const t    = Math.max(0, Math.min((co2 - 310) / 120, 1));
  const freq = 45 + t * 30; // 45Hz clean → 75Hz tense
  osc1.frequency.setTargetAtTime(freq, ctx.currentTime, 1.5);
  osc2.frequency.setTargetAtTime(freq * 1.045, ctx.currentTime, 1.5);
}

Architecture

The whole app is structured around a single truth: birthYear. Everything derives from it.

App.jsx
├── birthYear (state) ─────────────────────────────┐
├── Hero           → onReveal(year) sets birthYear  │
├── ShockSection   ← birthYear                      │
├── Toolbar        ← country, toggles               │
├── CountryPanel   ← birthYear + country            │
├── Scrubber       ← birthYear + sliderYear         │
├── ScenarioChart  ← birthYear + scenario           │
├── MetricCards    ← birthYear + country + modes    │
├── CompareSection ← birthYear                      │
├── Quiz           ← birthYear (resets questions)   │
├── Timeline       ← birthYear (filters events)     │
└── ShareCard      ← birthYear + country            │
                   ────────────────────────────────┘

No Redux, no Zustand. Just useState in App.jsx with props passed down. The data layer is pure JS objects — no API calls, no loading states, instant renders.

The data

All datasets are annual means from primary sources, hand-curated and interpolated:

// Linear interpolation across sparse data
export function interp(data, year) {
  if (data[year] !== undefined) return data[year];
  const keys = Object.keys(data).map(Number).sort((a, b) => a - b);
  // find surrounding years and lerp
  const t = (year - lo) / (hi - lo);
  return data[lo] + t * (data[hi] - data[lo]);
}

This means every year from 1950–2026 returns an accurate value even if we only store data every 5 years.

What I'd do with more time

SVG world map with country-level temperature choropleth
Real Keeling Curve seasonal animation (actual monthly NOAA data)
Share to Twitter/X with OpenGraph preview card
Offline PWA support — the whole app works without internet anyway

Design Philosophy

The biggest design decision wasn't technical — it was emotional.

Climate data is usually presented as a problem to solve. Numbers, charts, policy. It lands as guilt or numbness.

Earth Time Machine tries a different frame: this happened in your lifetime. You were there. The CO₂ that rose, rose while you were alive. The ice that melted, melted while you watched.

That's not guilt — it's stakes. And stakes make people want to act.

The dark brown/forest green colour palette is intentional. Earth tones. Soil. The feeling of something organic under stress, not cold data on white.

The CO₂ number that arrives and pulses — not loops — is intentional. It's not a process. It's a fact. It stays.

Prize Categories

Not submitting to sponsored prize categories — this project uses no third-party AI APIs, authentication services, or blockchain infrastructure. Just the web platform, open climate data, and a weekend.

Data sources: NOAA Mauna Loa (CO₂), NASA GISTEMP v4 (temperature), NSIDC Sea Ice Index (Arctic ice), FAO FRA 2025 (forest), UN World Population Prospects (population), CSIRO/Church & White 2011 (sea level). All datasets are annual means verified against primary sources.

Built over one weekend for Earth Day 2026. The planet deserved better tooling.

I Built a Daily JavaScript Quote Bot with GitHub Actions (No Server Required)

Sushant Rahate — Sun, 01 Mar 2026 19:54:16 +0000

This is a submission for the DEV Weekend Challenge: Community

👉 Check it out in action: https://t.me/jsdailybyte

The Community

JS Daily Byte was built for a Telegram Channel of developers who want to stay sharp on JavaScript fundamentals.

We didn’t need another course.
We didn’t need long threads.

We just needed one clear JavaScript concept, delivered daily.

Simple. Focused. Practical.

What I Built

JS Daily Byte is a fully automated Telegram bot powered by GitHub Actions.

Every day at 13:00 UTC, it:

Reads a quotes.json file
Picks a deterministic quote based on the current date
Formats it safely for Telegram
Sends it to the JS Daily Byte channel

No servers.
No hosting.
No cron jobs on a VPS.
No backend deployment.

Just GitHub + Telegram API.

Example message:

🟡 JS Daily Byte

“Every JavaScript program runs inside an execution context with two 
phases: memory creation and code execution.”

Demo

🔗 Telegram Channel:
https://t.me/jsdailybyte

(Every day a new JavaScript concept drops automatically.)

Code

The entire project is open on GitHub:

👉 https://github.com/sushantrahate/js-daily-byte

Key files:

quotes.json - Stores all JavaScript concepts in a simple array format.
.github/workflows/js-daily-byte.yml - GitHub Action that runs daily and handles the entire automation flow.

How I Built It

The stack is intentionally minimal:

GitHub Actions → daily scheduler (cron at 13:00 UTC)
Node.js (inline script) → reads JSON + generates deterministic index
Telegram Bot API → sends formatted message
Secrets → bot token + chat ID stored securely

Why GitHub Actions?

Because:

It’s free
It’s reliable
It removes infrastructure complexity

The workflow:

Loads the quotes array from quotes.json
Generates a deterministic index using the current UTC date
Selects the corresponding quote
Escapes HTML to ensure Telegram-safe formatting
Sends the formatted message to the Telegram channel via the Bot API using curl.

No database.
No server.
No maintenance.

The entire setup takes under 30 minutes.
Perfect for a small but meaningful weekend hack. 😉

Build Your Own in 5 Steps

Create a Telegram bot (via @ BotFather)
- Open Telegram and search @ BotFather
- Run /newbot
- Set a name (example: JS Byte Bot) and a username ending with bot
- Copy the API token BotFather gives you (this becomes TG_BOT_TOKEN)
Create a Telegram channel and add the bot
- Create a channel (example: JS Daily Byte)
- Add your bot to the channel
- Make the bot an admin so it can post messages
Get your Telegram chat_id
- Send a message in the channel (or mention the bot like @ YourBot hi)
- Open this URL in a browser: https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates
- Copy the chat.id value (usually starts with -100...) This becomes TG_CHAT_ID
Add your quotes
- Create quotes.json in the repo root
- Store quotes as a simple array of strings, like: ["quote 1", "quote 2", "quote 3"]
Add the GitHub Actions workflow
- Create .github/workflows/js-daily-byte.yml
- Add a scheduled cron job (example: 0 13 * * * for 13:00 UTC)
- Workflow will:
  - read quotes.json
  - pick the quote for the day
  - send it using Telegram Bot API via curl
Add GitHub Secrets (required)
- Repo → Settings → Secrets and variables → Actions → New repository secret
- Add:
  - TG_BOT_TOKEN = your BotFather token
  - TG_CHAT_ID = your channel chat id

After that, the bot runs daily automatically. You can also trigger it anytime from the Actions tab using workflow_dispatch.

That’s it.

Final Thoughts

JavaScript fundamentals aren’t difficult because they’re complex.
They’re difficult because we forget them.

JS Daily Byte keeps these concepts fresh - one small reminder at a time.

You can find more of my work at: https://sushantrahate.com/

Happy coding! 😄

I Built a 100/100 Google Lighthouse Portfolio website - By Keeping It Boring

Sushant Rahate — Sun, 28 Dec 2025 16:11:40 +0000

Like most developers, I once believed a portfolio had to be flashy.
More animations • More motion • More “wow”
And somehow… a Lighthouse score of 62 😅

So this time, I did the opposite.

👉 Portfolio: https://sushantrahate.com

(Open it alongside this post if you want context.)

PageSpeed Insights: https://pagespeed.web.dev/analysis/https-sushantrahate-com/vkyra56xl5?form_factor=desktop

The Real Goal

I didn’t want my portfolio to entertain people.

I wanted it to respect their time.

It should load in milliseconds
And the moment it appears, the viewer should feel: “Okay. I know who this person is.”

The first screen is the first impression.
If that moment is unclear, everything after it is noise.

So the first screen explains - without asking you to scroll:

who I am
what I do
what I’m building

No telling. Only proof.

“Talk is cheap. Show me the code.” - Linus Torvalds

My Constraints (Intentionally Self-Imposed)

Before writing a single line of code, I set strict rules:

⚡ 100% Google Lighthouse performance
🧠 Only essential information
🚫 No heavy frameworks
🚫 No animations to wait for
🚫 No component libraries
🚫 No guessing
🚫 No effort required from the viewer
✅ Fast even on slow networks

The Layout: Compact by Design

Once I knew what to show, I focused on how.
I chose a bento grid layout - compact, high-signal information density.

People don’t read websites line by line.
They scan, usually in a Z-pattern:
top-left → top-right
then diagonally down
then left → right again

So I placed sections deliberately to match that flow.

1. Starting With the Human

The page begins with who I am.

I mention JavaScript, not a long list of frameworks (tools change, fundamentals don’t)
I mention backend and security (that’s how I think when building systems)
I end with a small personal line - husband, dad to remind there’s a human behind the code

No fluff. Just context.

2. What I’m Actually Building

At the top, I show what I care about right now:

MatriProfile - my live SaaS

👉 https://matriprofile.com

A modern, multilingual, privacy-first marriage biodata generator -
built end-to-end by me.

Shipping a real product teaches more than any tutorial or side project ever will:
product thinking, user behavior, trade-offs, and long-term maintenance.

3. Proof Over Promises

I first heard this line in The Social Network, and it stuck:

“Talk is cheap. Show me the code.”
Instead of listing skills, I show repositories.

One of them:
👉 https://github.com/sushantrahate/express-typescript-prisma-postgresql
⭐ It has 27 GitHub stars - but more importantly, it has intent.

It’s a production-ready backend starter focused on:

clean architecture
TypeScript discipline
real-world backend patterns

4. Writing for Clarity

I also link to articles I’ve written.
Because writing exposes understanding.
If I can explain authentication, access control, or backend trade-offs in simple words,
it means I’ve wrestled with those concepts long enough to earn clarity.

Finally, social links sit at the bottom.

The Tech Stack

HTML
Tailwind CSS
Vanilla JavaScript

JavaScript is loaded with defer, so it never blocks rendering.

<script src="./script.js" defer></script>

Fetching GitHub stars is handled carefully:

The API call runs only after the page has fully loaded
First paint stays untouched

Closing Thought

A portfolio doesn’t need to explain everything.
It just needs to make the right impression - fast
and give the viewer clear paths to go deeper if they want to.

Mine isn’t a big portfolio.
It’s simple, clean, and intentional.

And sometimes, boring is exactly what works.

GitHub URL: https://github.com/sushantrahate/portfolio

I hope this guide helps you. Happy coding! 😄
I’d love to connect - whether for work, collaboration, or just to talk systems.

Node.js Authentication: Best Practices and Key Strategies

Sushant Rahate — Mon, 11 Nov 2024 08:41:06 +0000

This article showcases secure login strategies for Node.js, implementing multiple security techniques to safeguard user credentials, sessions, and account access.

Key Security Features

1. Password Hashing with Salt

Passwords are hashed using a strong hashing algorithm (e.g., bcrypt) along with a random salt for each password. This ensures that even if the hashed password is compromised, it cannot easily be reversed into the original password.

Why its important:

Prevents plain-text password storage.
Salting makes it difficult for attackers to use precomputed hash tables (rainbow tables) to guess passwords.

Implementation:

import bcrypt from 'bcrypt';

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

// Create and save the user in the database
const newUser = new User({ username, password: hashPassword });
await newUser.save();

// Login API
const { username, password } = req.body;

const user = users.find((u) => u.username === username);
if (!user) return res.status(400).send('User not found');

const isPasswordValid = await bcrypt.compare(password, user.password);
if (!isPasswordValid) return res.status(400).send('Incorrect password');

2. Token-Based Authentication

JWT (JSON Web Token) is used for token-based authentication, allowing stateless authentication between the client and server. Users receive a JWT upon login, which is then sent with every subsequent request in the Authorization header.

Why its important:

Stateless: No need for session storage on the server.
Secure token can carry claims (user ID, roles) without exposing sensitive information.

Implementation:

import jwt from 'jsonwebtoken';

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

3. Refresh Tokens

A refresh token is used to obtain new access tokens without requiring the user to log in again. This ensures a smooth experience for users without compromising security.

Here Is Repo for JWT Authentication With Refresh Token as HTTP-only Cookie

Why its important:

Minimizes exposure by using short-lived access tokens.
Refresh tokens are stored more securely (e.g., in a database or HTTP-only cookie).

Implementation:

const generateRefreshToken = (userId: string) => {
  return jwt.sign({ userId }, process.env.REFRESH_SECRET, { expiresIn: '7d' });
};

4. HTTP-Only Cookies

Store sensitive tokens such as refresh tokens in HTTP-only cookies. This prevents JavaScript from accessing the tokens, protecting them from XSS (Cross-Site Scripting) attacks.

Why its important:

Shields tokens from being stolen by malicious scripts.
Reduces the risk of token exposure through client-side code.

Implementation:

res.cookie('refreshToken', refreshToken, {
  httpOnly: true,
  secure: process.env.NODE_ENV === 'production',
  sameSite: 'strict',
});

5. JWT Blacklisting

JWT tokens do not have built-in revocation. To invalidate tokens (e.g., on logout), JWT blacklisting is used. A database or Redis is used to store invalidated tokens until they expire.

Why its important:

Prevents previously issued tokens from being used after logout or account compromise.

Implementation:

const blacklistToken = async (token: string) => {
  await redisClient.set(token, 'blacklisted', 'EX', tokenExpirationTime);
};

6. Single Session at a Time

Ensure that only one session is active for a user at any given time. When a new session is created, invalidate previous tokens or sessions.

Why its important:

Prevents concurrent logins from multiple devices or locations, enhancing account security.

Implementation:

// Schema for User table:
sessionId: { type: String, unique: true }

//login API
const newSessionId = generateAccessToken(user);
user.sessionId = newSessionId;
await user.save();

// Auth API
const decodedToken: any = jwt.verify(token, process.env.ACCESS_TOKEN_SECRET!); // Replace with your JWT secret key
const sessionIdFromToken = decodedToken.sessionId;

if (user.sessionId !== sessionIdFromToken) {
      return res.status(403).json({ message: 'Session invalidated. You are logged in elsewhere.' });
    }

7. Ideal Time Session Expiration

Sessions expire after a period of inactivity. Implement a session expiration timer to automatically log out users who are inactive for a predefined time.

Why its important:

Reduces the risk of an unauthorized person accessing the session if the user forgets to log out.

Implementation:

const sessionExpirationTime = 15 * 60 * 1000; // 15 minutes
const IDLE_TIMEOUT = 15 * 60 * 1000;

// User Schema
lastActivity: { type: Date, default: Date.now }, // Track last activity timestamp

// in auth middleware
const now = new Date();
const idleTime = now - new Date(user.lastActivity);

if (idleTime > IDLE_TIMEOUT) {
  // Token is still valid, but session is idle for too long
  return res.status(401).json({ message: 'Session expired due to inactivity' });
}

// Else Update last activity timestamp if within idle timeout
user.lastActivity = now;
await user.save();

8. Account Lockout Mechanism

Prevent brute force attacks by locking out accounts after several failed login attempts. Implement time-based lockout, where accounts are temporarily locked after repeated failures.

Why its important:

Mitigates brute force attacks by limiting login attempts.

Implementation:

// Schema
failedLoginAttempts: { type: Number, default: 0 },
lockoutUntil: { type: Date, default: null }, // Track lockout time

const MAX_ATTEMPTS = 3;
const LOCK_TIME = 15 * 60 \_ 1000; // 15 minutes
// Example for MongoDB with Mongoose
const handleFailedLogin = async (email: string) => {
  const user = await User.findOne({ email });
  if (!user) return false;

  if (user.lockoutUntil && user.lockoutUntil > new Date()) {
    return true; // Account is still locked
  }

  user.failedLoginAttempts += 1;

  if (user.failedLoginAttempts >= MAX_ATTEMPTS) {
    user.lockoutUntil = new Date(Date.now() + LOCK_TIME); // Lock for 30 mins
  }

  await user.save();
  return user.lockoutUntil && user.lockoutUntil > new Date(); // Return if account is locked
};

// Reset login attempts if the login is successful

9. Secure Password Reset Procedures

Users can reset their passwords through a secure process. Use a time-limited, one-time token (OTP) sent to the user's email for the reset process. Ensure the reset token expires after a short period.

Why its important:

Provides users a secure way to recover accounts without compromising security.

Implementation:

// User Schema
resetPasswordToken: String,
resetPasswordExpires: Date,

/* Use crypto.randomBytes() to generate a secure hex instead of Math.random(), Math.random() hex are easier for attackers to guess or brute force. */
const generateResetToken = () => {
  return crypto.randomBytes(20).toString('hex');
};

const token = generateResetToken();
user.resetPasswordExpires = Date.now() + 3600000; // 1 hour from now

10. Password Expiration and Restricting Past 3 Passwords

Here's how this works:

Password History:

The system stores the last three hashed passwords in a user's password history.
When a user attempts to set a new password, the system compares the new password against these previous passwords to prevent reuse.

Password Expiration:
- The system tracks how long a user has been using their current password.
- After a set period (e.g., 1 month), the system sends a notification prompting the user to change their password.
- If the password is not updated within a given grace period, access may be restricted until a new password is set.

// Schema
passwordHistory: [{ type: String }], // Array to store past 3 password hashes
passwordUpdatedAt: { type: Date, default: Date.now }, // When the password was last updated

// You can Check Expiration on Login or have a corn job to find and notify users via email.

11 . Implementing Strong Password Policies

Strong password policies help prevent unauthorized access and minimize the risk of brute-force attacks, dictionary attacks, and credential stuffing.

Implementation:

import validator from 'validator';

const password = 'User@1234';
if (
  !validator.isStrongPassword(password, {
    minLength: 8,
    minLowercase: 1,
    minUppercase: 1,
    minNumbers: 1,
    minSymbols: 1,
  })
) {
  throw new Error('Password does not meet complexity requirements.');
}

12. User-Specific Token Revocation

User-specific token revocation is the process of invalidating a single user’s tokens without affecting others.

It’s useful in cases like:

Suspicious activity detected on an account
A user requests token revocation for security
The account is disabled or suspended
A token is stolen or leaked

How it Works:

Token Structure:

Tokens (e.g., JWTs) contain user data and a tokenVersion. The tokenVersion is stored in the database to track the validity of tokens for each user.

Token Verification:

When a request is made, the server decodes the token and compares the tokenVersion in the token with the version stored in the database. If they match, the token is valid; if not, the token is invalidated.

Token Revocation:

To revoke all tokens for a user, simply increment the tokenVersion in the database. All tokens with the previous version are automatically invalidated.

Implementation:

// Schema: token_version INT DEFAULT 1

// JWT Creation
const createToken = (user) => {
  const payload = { userId: user.id, tokenVersion: user.tokenVersion };
  return jwt.sign(payload, SECRET_KEY, { expiresIn: '1h' });
};

// Token Validation
if (user.tokenVersion !== decoded.tokenVersion) {
  throw new Error('Invalid token: version mismatch');
}

// To revoke, increment tokenVersion
user.tokenVersion++;

13. Cross-Origin Resource Sharing (CORS) Configuration

Configure CORS to restrict which origins are allowed to access the API. Only trusted domains should be allowed to send requests to your server.

Why its important:

Prevents unauthorized sites from making requests to your server.
Protects against CSRF (Cross-Site Request Forgery) attacks.

Implementation:

import cors from 'cors';

app.use(
  cors({
    origin: 'https://your-frontend-domain.com',
    credentials: true,
  })
);

Also read Role-Based Access Control with Feature-Centric Approach

Check out my GitHub profile: https://github.com/sushantrahate

I hope this guide helps you. Happy coding! 😄

Role-Based Access Control (RBAC) with Feature-Centric Approach

Sushant Rahate — Sat, 09 Nov 2024 19:01:50 +0000

In this article, we’ll explore how to set up a Role-Based Access Control (RBAC) system where features are a central part. We'll go through defining modules, associating features, assigning roles with specific features, and finally assigning roles to users. This example uses JSON data to keep things simple and adaptable, allowing for scalable access control without requiring any changes for new roles on the frontend

Live Demo

1. Define Modules and Features

Modules group similar features together. Each module can contain multiple features representing actions that users can perform.

JSON Structure for Modules and Features:

{
  "modules": [
    {
      "id": 1,
      "name": "Users",
      "features": [
        "view-users",
        "edit-users"
      ]
    },
    {
      "id": 2,
      "name": "Reports",
      "features": [
        "view-reports",
        "edit-reports"
      ]
    }
  ]
}

Modules: Represents a specific area of the application, like "Users" or "Reports."
Features: Actions within each module, such as view-users and edit-users for the Users module.

2. Create Roles and Assign Features

Next, create roles that define sets of features. Each role will have a list of permissions that grant access to specific features within the modules.

JSON Structure for Roles and Permissions:

{
  "roles": [
    {
      "id": 1,
      "name": "Admin",
      "permissions": [
        "view-users",
        "edit-users",
        "view-reports",
        "edit-reports"
      ]
    },
    {
      "id": 2,
      "name": "Viewer",
      "permissions": [
        "view-users",
        "view-reports"
      ]
    }
  ]
}

Roles: Represent groups with specific access rights, like "Admin" and "Viewer."
Permissions: Specify which features each role has access to, allowing for flexible permission settings.

By defining roles, you can manage access control efficiently without modifying each user's permissions.

3. Assign Roles to Users

After creating roles, assign them to users. Each user will inherit the permissions granted by their role.

JSON Structure for Users and Role Assignments:

{
  "users": [
    {
      "id": 1,
      "name": "Sushant",
      "roleId": 1
    },
    {
      "id": 2,
      "name": "Raghav",
      "roleId": 2
    }
  ]
}

Users: Represent individuals who will access the application.
RoleId: Links each user to a specific role, determining their feature access.

With this structure, you can easily update roles to grant or restrict access for multiple users simultaneously.

4. Setting Up Access Control Logic in the Frontend

On the frontend, access to each feature is checked based on the user's role. Here’s how to securely handle user access based on their assigned role.

Fetch Role Permissions: When a user logs in, retrieve their role's permissions from the backend.
Store Permissions Locally: For session-based access control, store permissions in a secure format (such as JWT or session storage).
Conditional Rendering: For each section or feature, check if the user has permission to view or edit it.

Example Access Check in JavaScript:

const userPermissions = ["view-users", "edit-users"]; // Loaded from backend based on role

if (userPermissions.includes("view-users")) {
  // Render the user view section
}

if (userPermissions.includes("edit-users")) {
  // Render the user edit section
}

Using a role-based check in the frontend ensures that users only see features they’re permitted to access.

Backend Validation

While this example focuses on the frontend, validating user roles and permissions should also happen on the backend. Backend validation should re-check feature access on every request, helping to prevent any unauthorized data or feature access

Pros and Cons

Pros

Fine-Grained Access Control: This approach allows you to control user access on a feature-by-feature basis, which is more flexible than traditional role-based access control.
Scalability: New features and modules can easily be added to the system, and roles can be adjusted without significant backend changes.
Improved Security: By combining frontend validation and strict backend checks, this system helps prevent unauthorized access to restricted features.

Cons

Complexity: Feature-based access control can become complex, especially as the number of modules, features, and roles increases. Proper planning and documentation are essential to prevent it from becoming difficult to manage.

Conclusion

Role-Based Access Control (RBAC) with a feature-centric approach offers a scalable and efficient way to manage user permissions. By defining modules and features, setting up roles, and assigning or updating features to roles, you can easily create and manage custom roles without requiring any new changes in the frontend.

Check out my GitHub profile: https://github.com/sushantrahate

I hope this guide helps you. Happy coding! 😄