Forem: Bishop Abraham

January 1, 1970 is a very special date in programming. Not because anything groundbreaking happened that day (no revolutionary app launched, no tech billionaire was born), but what really happened is a mind-blowing fact.

Bishop Abraham — Fri, 17 Oct 2025 20:13:55 +0000

Bishop Abraham

Oct 17 '25

Why January 1, 1970 Is the Most Important Date in programming (And You've Probably Never Heard of It)

#programming #computerscience #technology #software

Comments 2

6 min read

Why January 1, 1970 Is the Most Important Date in programming (And You've Probably Never Heard of It)

Bishop Abraham — Fri, 17 Oct 2025 18:51:01 +0000

January 1, 1970 is a very special date in programming. Not because anything groundbreaking happened that day (no revolutionary app launched, no tech billionaire was born), but because it's literally the moment time began for computers.

Every timestamp on your device, from the moment you created that embarrassing selfie to when you last ordered pizza at 2 AM, is secretly just counting seconds from this one specific moment: midnight on January 1, 1970.

Your computer doesn't think it's October 2025. It thinks it's been exactly 1,770,000,000-ish seconds since New Year's Day 1970.

Welcome to Unix Epoch Time, the invisible clock that runs the internet.

What Even Is Unix Time?

Okay, imagine if everyone measured their age not in years, but in seconds since some random Tuesday in 1970. Weird, right? But that's basically what computers do.

Unix time (also called Epoch time or POSIX time) is just a giant counter. At the stroke of midnight on January 1, 1970 (UTC, because even time zones can't agree on anything), the counter started at zero. Every second that passes, the number goes up by one. Right now, as you're reading this, the Unix timestamp is somewhere around 1,770,000,000. That's 1.77 billion seconds of existence.

When you check the "last modified" date on a file, your computer isn't storing "October 10, 2025, 3:42 PM." That would be messy. Different languages write dates differently (is it 10/10/2025 or 10.10.2025?), and don't even get me started on time zones. Instead, it stores something like 1728574920 and then translates it back into a human-readable date when you need to see it.

Why 1970? Why Not, Like, Year Zero?

Great question. The answer is both practical and deeply nerdy.

Unix (the operating system that basically runs everything) was developed at Bell Labs in 1969. The developers needed a reference point for their timekeeping system, and they wanted something recent enough to be relevant but round enough to be simple. They picked January 1, 1970 because:

It was close to when they were building the system
It was the start of a new decade (humans love round numbers)
It made the math easier since they could use 32-bit integers

Nobody thought we'd still be using this system 50+ years later. They just needed something that worked. And honestly? It worked so well that we're stuck with it forever now.

How This Actually Shows Up in Your Code

If you've ever written JavaScript, you've met Unix time whether you knew it or not:

Date.now()
// Returns something like: 1728574920000

That number? Milliseconds since January 1, 1970. JavaScript uses milliseconds instead of seconds (because JavaScript likes to be extra), so you get an even bigger number.

Want to see what time it was exactly 1 billion seconds after the Unix Epoch?

new Date(1000000000 * 1000)
// Sun Sep 09 2001 01:46:40 GMT

Yep, the billionth second happened in 2001. There were parties. Nerds are fun like that.

Python does it too:

import time
time.time()
# Returns something like: 1728574920.547

This is super useful for things like:

Sorting events chronologically (bigger number = happened later)
Calculating time differences (just subtract two numbers)
Storing timestamps in databases (one integer instead of a messy date string)
Making sure your API calls don't arrive from the "future" due to clock drift

When Unix Time Gets Weird

Here's where things get fun. Or terrifying, depending on how you feel about bugs.

The December 31, 1969 Mystery

Ever seen a file or app that claims something happened on December 31, 1969? That's Unix time having an existential crisis.

When a timestamp is 0 (or negative, or undefined), and your computer tries to display it in a time zone that's behind UTC, it rolls back to December 31, 1969. It's like the computer is saying, "I have no idea when this happened, so here's the day before time began."

The Year 2038 Problem (Coming Soon to a Server Near You)

Remember how I said Unix time uses 32-bit integers? Well, those can only count so high: 2,147,483,647 to be exact.

That number will be reached at exactly 03:14:07 UTC on January 19, 2038.

And then? The counter overflows and wraps back around to... December 13, 1901.

This is called the Year 2038 problem, and it's basically Y2K's cooler, scarier younger sibling. Old systems still running on 32-bit integers will absolutely lose their minds. Banking software, embedded systems, legacy servers, anything that hasn't been updated to use 64-bit integers could suddenly think it's the early 1900s.

The good news? Most modern systems have already switched to 64-bit timestamps, which won't run out until the year 292,277,026,596. So unless you're planning to still be debugging code in 292 billion years, you're probably fine.

Leap Seconds: Unix Time's Awkward Cousin

Here's something that'll blow your mind: Unix time completely ignores leap seconds.

Earth's rotation isn't perfectly consistent, so occasionally scientists add a "leap second" to keep our clocks in sync with the planet's actual rotation. But Unix time? It just pretends leap seconds don't exist. It assumes every day has exactly 86,400 seconds, no exceptions.

This means Unix time is technically lying to you by about 27 seconds right now. But it's a useful lie because dealing with random extra seconds would make timestamps way more complicated.

Why This Matters to You (Yes, Even You)

You might be thinking, "Cool story, but I don't write low-level system code. Why should I care?"

Because Unix time is everywhere, and understanding it helps you avoid really annoying bugs:

Time zone disasters: Ever had a user report that your app shows the wrong date? Probably because you forgot to account for time zones when converting Unix timestamps. Always store times in UTC (Unix time already is), then convert to local time only when displaying to users.

Date comparison fails: If you're comparing dates by converting them to strings like "2025-10-10", you're doing it wrong. Convert to Unix timestamps and compare the numbers. Way more reliable.

API authentication: Many APIs use timestamps in their authentication signatures to prevent replay attacks. If your system clock is off by even a few seconds, your requests might get rejected for being "from the future" or "too old."

Cache invalidation: When you're caching data with expiration times, you're almost certainly using Unix timestamps under the hood. Understanding how they work helps you debug when cached data sticks around too long (or expires too soon).

The Beautiful Simplicity of It All

At the end of the day, Unix time is just really good design. It's simple, universal, and mostly foolproof.

Instead of dealing with the nightmare of "Is it October 10 or 10 October?" and "Wait, does this month have 30 or 31 days?" and "What even is daylight saving time?", we just count seconds. One number. That's it.

Sure, it has quirks (looking at you, 2038 problem), but it's been working reliably for over 50 years. That's pretty impressive for something that was probably sketched out on a napkin at Bell Labs in 1969.

So next time you see a timestamp in your code or a weird date bug pops up, remember: somewhere deep in your computer's soul, it's just counting seconds from that magical moment at midnight on January 1, 1970.

Time really does fly when you're having fun. Or when you're a Unix timestamp, at least.

Have you ever encountered a weird Unix timestamp bug? Drop your stories in the comments. Bonus points if it involved December 31, 1969.

Originally published on My Blog

Most of the time, your IP address just quietly does its job. But in the wrong hands? Things get interesting. And by interesting, I mean potentially bad.

Bishop Abraham — Thu, 16 Oct 2025 08:21:57 +0000

Bishop Abraham

Oct 16 '25

How Hackers Use Your IP Address (And Why You Should Actually Care)

#cybersecurity #internet #networking #software

Comments 1

3 min read

How Hackers Use Your IP Address (And Why You Should Actually Care)

Bishop Abraham — Thu, 16 Oct 2025 08:20:50 +0000

Let's talk about something we all have but don't really think about: our IP address.

It's basically your internet phone number. Every device connected to the internet gets one. Your laptop, phone, smart TV, and yes, even that smart fridge nobody asked for but somehow exists.

Most of the time, your IP address just quietly does its job. But in the wrong hands? Things get interesting. And by interesting, I mean potentially bad.

What Hackers Can Actually Do With Your IP

1. Track Your General Location

No, they can't see your exact address (this isn't a spy movie). But they CAN see your city and internet provider.

Which means that phishing email saying "We noticed suspicious activity on your account from [your actual city]" just got way more convincing, didn't it?

It's like someone saying "I know where you live" but they only know your neighborhood. Still creepy enough to make you nervous.

2. Knock on Your Digital Doors

Hackers scan your IP looking for open ports. Running a home server? Remote desktop enabled? Old device you forgot about?

They'll find it. And if you left it unlocked, congrats, they're in.

It's the digital equivalent of someone walking down your street jiggling every door handle to see who forgot to lock up.

3. Flood You Offline (DDoS)

Ever seen a streamer suddenly go offline mid-game? Or a website just... die?

That's a DDoS attack. Someone floods your IP with so much fake traffic that your connection gives up and collapses.

It's like a thousand people calling your phone simultaneously. Eventually, nobody's getting through. Including you.

4. Hijack Your Router or Smart Devices

Here's the fun part: tons of routers still use "admin/admin" or "password" as the default login.

If yours does and it's exposed to the internet, congratulations! Your router just became part of someone's botnet army. Your Ring doorbell is now helping attack a Minecraft server halfway across the world.

5. Brute Force Your Login Pages

Got a login portal on your network? Maybe a home NAS or remote desktop?

Hackers will throw every leaked password from every data breach at it until something clicks. And trust me, they've got a LOT of leaked passwords.

What Your IP WON'T Reveal

Let's kill some myths real quick.

Your IP address alone won't show:

Your name
Your exact street address
Your bank details
Your browser history
What you ordered on Amazon last night

It's not magic. It's just a number.

But combine it with leaked info, some social media stalking, and a convincing phone call? Now you're in trouble.

How to Not Be an Easy Target

You don't need to be a cybersecurity expert. Just do these:

Use a VPN on public Wi-Fi. Coffee shop internet is basically an open buffet for hackers. A VPN hides your real IP and locks down your traffic.

Update your router. Yes, it's boring. Yes, that firmware update might actually save you from getting hacked. Do it anyway.

Change. Default. Passwords. If your router login is still "admin/password," stop reading and go change it right now. Seriously.

Turn off remote features you don't use. Don't know what UPnP or remote admin does? You probably don't need it facing the internet.

Lock down what you expose. Home server? Cool. Leaving it wide open with no firewall? Not cool.

The Real Talk

Your IP isn't dangerous by itself. It's just information.

But hand that information to someone who knows what they're doing and has bad intentions? It becomes a weapon. A starting point. The crack in your armor.

You wouldn't leave your front door wide open with a neon sign saying "FREE STUFF INSIDE." Don't do the internet equivalent.

A few simple steps make you way harder to mess with. And in cybersecurity, not being the easiest target is literally 80% of the game.

The hackers will just move on to the next person who's still using "password123."

Don't be that person.

Be honest: have you changed your router password since you got it? Or are you still rocking the defaults? Drop a comment, no judgment... okay, maybe a little judgment.

Originally published on My Blog

After deploying your react app on Vercel, you're sitting there like "It literally worked two seconds ago. I didn't change anything. What is happening?" Let me explain what's going on, and more importantly, how to fix it without losing your mind.

Bishop Abraham — Mon, 13 Oct 2025 23:42:06 +0000

Bishop Abraham

Oct 13 '25

Why Your React App Breaks When You Refresh on Vercel (And the 2-Minute Fix)

#react #vercel #deployment #webdev

Comments 2

3 min read

Why Your React App Breaks When You Refresh on Vercel (And the 2-Minute Fix)

Bishop Abraham — Mon, 13 Oct 2025 23:37:55 +0000

So you finally deploy your React app to Vercel. It works. You click around, everything's smooth. Then you navigate to another page, hit refresh and…

Boom. 404 Page Not Found.

You're sitting there like "It literally worked two seconds ago. I didn't change anything. What is happening?"

Let me explain what's going on, and more importantly, how to fix it without losing your mind.

What's Actually Happening Here

Your React app uses React Router to handle navigation. When you click a link to /about or /profile, React quietly swaps the content on your screen without actually loading a new page from the server. It's smooth, it's fast, it's great.

But here's the problem.

When you hit refresh on /about, your browser asks Vercel's server: "Hey, give me the /about page."

And Vercel's like: "About? I don't have a file or folder called 'about.' Here's a 404 instead."

See, Vercel is looking for actual files and folders. But /about doesn't exist as a file. It only exists in your React Router configuration, which lives in JavaScript that hasn't run yet because... well, you got a 404 before React could even load.

Classic catch-22.

The Fix (Seriously, Takes 2 Minutes)

You need to tell Vercel: "Listen, no matter what URL someone visits, just serve them the main React app. Let React figure out the routing."

Here's how:

Step 1: In your project folder (where package.json lives), create a file called vercel.json

Step 2: Paste this in:

{
  "rewrites": [
    { "source": "/(.*)", "destination": "/" }
  ]
}

Step 3: Save it. Push to GitHub (or wherever your code lives).

Step 4: Redeploy on Vercel.

That's it. Go test it. Navigate to any page, hit refresh. It works now.

What this config does is tell Vercel "For every route someone tries to access, serve them the main index.html file." Then React Router takes over and shows the right page.

The Quick-and-Dirty Alternative

If you're in a rush and don't want to mess with config files, there's another option.

Change this in your code:

import { BrowserRouter } from "react-router-dom";

To this:

import { HashRouter } from "react-router-dom";

This makes your URLs look like /#/about instead of /about. The refresh issue goes away, but your URLs are uglier and search engines don't love them.

It's like fixing a broken chair by just sitting on the floor. Technically works, but not ideal.

Use this only if you're desperate or don't have access to deploy config files.

Why This Happens to Everyone

You didn't mess up. This trips up tons of developers, even experienced ones.

It's just one of those things where your local development environment and production hosting don't work the same way. On your local machine with npm start, the dev server handles this automatically. But when you deploy? Different story.

Now you know. And next time someone in your Discord or Slack freaks out about this exact issue, you can swoop in with the answer and look like a genius.

The Takeaway

Single Page Apps (SPAs) like React are amazing, but they need a little help when it comes to server-side routing. One tiny config file fixes it permanently.

Bookmark this post. You'll probably need it again, or someone you know will.

Got other React deployment headaches? Drop them in the comments. I've probably run into them too, and misery loves company.

Now go refresh that page with confidence.

Originally published on My Blog

And after four years of building projects, I've figured out which tools actually matter. Not the trendy ones. The ones that save my sanity when production is on fire.

Bishop Abraham — Mon, 13 Oct 2025 00:42:03 +0000

Bishop Abraham

Oct 13 '25

🛠 The MERN Stack Tools I Actually Use (Not Just the Ones That Look Good on Twitter)

#productivity #devtools #devtips #programming

Comments 2

5 min read

🛠 The MERN Stack Tools I Actually Use (Not Just the Ones That Look Good on Twitter)

Bishop Abraham — Mon, 13 Oct 2025 00:40:33 +0000

Let me be honest: my development setup is not aesthetic.

I don't have a standing desk with three curved monitors and a mechanical keyboard that sounds like rainfall. My workspace is a laptop, and approximately 47 browser tabs I keep telling myself I'll close "later."

But you know what? My toolkit works. And after three years of building MERN stack projects, I've figured out which tools actually matter.

Not the trendy ones. The ones that save my sanity when production is on fire.

VS Code: The Editor That Doesn't Fight Me

VS Code is my home base. Not because it's perfect (it's definitely crashed during important demos), but because I've finally got it set up exactly how I need it.

Prettier - Because arguing about semicolons is a waste of everyone's time. Hit save, everything formats. Done.

ESLint - My personal code critic that catches stupid mistakes before they become production problems.

GitLens - Answers the eternal question: "Who wrote this code and what were they thinking?" (Plot twist: it's usually me from three months ago.)

Thunder Client - For when I need to test an API endpoint but don't want to leave VS Code.

Tailwind CSS IntelliSense - Because remembering whether it's justify-center or center-justify shouldn't require a Google search every single time.

React code snippets - Type rafce, get a functional component. It's the small things that add up.

Import Cost - Shows you when you're about to import a 2MB library for one function. Eye-opening.

Chrome DevTools: Where Bugs Go to Get Caught

Chrome DevTools + React Developer Tools are basically my second home.

I live in the Network tab when APIs are being weird. The React component tree is a lifesaver when props aren't flowing right. And the Console? That's where I have philosophical conversations with console.log() about why my variable is undefined.

Real talk: if you're not comfortable with DevTools, you're making life harder. I've watched developers waste hours on bugs that would've taken 5 minutes to spot with the Network tab open.

HTTPie: API Testing Without the Drama

HTTPie is my ride-or-die for API testing.

Yeah, Postman is popular and powerful. But HTTPie just... works. And it doesn't try to make me sign up for a team workspace when I'm just trying to test a login endpoint at midnight.

The environment switching between staging and production? Chef's kiss. No more "oops, I just deleted production data because I forgot to switch environments."

MongoDB Compass: When You Just Need to SEE the Data

Sure, typing mongo shell commands makes you feel like a hacker in a movie. But when you need to actually understand your data structure, or figure out why your query returns 0 results when it should return 50, Compass saves the day.

Visual representation beats staring at JSON in the terminal while your brain tries to parse nested objects.

Git + GitHub: Version Control for Adults

Controversial take: I love Git.

My workflow is boring and that's exactly why it works:

Feature branches for everything
Commit often with messages that future me will understand
Pull requests even on solo projects (yes, really)

GitHub Issues and Projects keep me organized, which is critical because my brain tries to convince me to start three new features while debugging one thing.

The real secret? Good commit messages. "Fixed stuff" doesn't help anyone. "Fixed user authentication redirect loop when session expires" helps a LOT three weeks later.

Node + Nodemon + Concurrently: The Holy Trinity

Nodemon means I don't have to manually restart my server every time I change one line of code. Which sounds small until you realize you make changes approximately 500 times per hour.

Concurrently lets me run frontend and backend servers with one command. One terminal, two servers, zero hassle.

Type npm run dev, everything starts, you get on with your life. Beautiful.

Jest + Supertest: Testing (Yes, Really)

Look, testing isn't fun. Nobody dreams of writing test cases.

But you know what's REALLY not fun? Deploying on Friday afternoon and having everything break because you changed one function and didn't realize it affected seven other things.

Jest and Supertest make testing as painless as possible. Write tests for your API endpoints, run them before you push, sleep better at night.

Notion: The Second Brain

This is where I keep everything I'll definitely forget.

Code snippets that solve specific problems. Weird bugs and how I fixed them. Architecture decisions and why I made them.

It's my external hard drive for developer knowledge. Because there's no way I'm remembering the exact CORS configuration that finally worked.

I can't count how many times I've thought "I've solved this before" and found the answer in my Notion database in 30 seconds. Plus, the fact that I can access it from anywhere (phone, tablet, borrowed laptop when mine dies) has saved me more times than I'd like to admit.

Spotify: The Secret Weapon

This isn't about being cool or having the perfect coding playlist. It's about focus.

Deep focus playlists for complex backend logic. Lo-fi for debugging when my brain hurts. The right audio environment is the difference between flow state and constantly checking Twitter.

What Actually Matters

After years of trying different setups, here's what I've learned:

The best tool is the one you'll actually use. That fancy new framework doesn't matter if you spend more time configuring it than building.

Simple beats complicated. If your setup requires 45 minutes to explain, it's too complex.

Your setup will evolve. What works now might not work in a year. That's fine.

The MERN stack comes with complexity. These tools don't eliminate it, but they make it manageable. They help me ship features instead of fighting with my environment.

And honestly? That's all I need.

What tools are essential in YOUR stack? Let's talk in the comments.

Now if you'll excuse me, I have 47 Chrome tabs to close.

Originally published on My Blog

After months of small annoyances and way too much curiosity, I finally made the switch to Linux. Here's what actually happened (spoiler: I'm not going back).

Bishop Abraham — Sun, 12 Oct 2025 00:15:28 +0000

Why I Finally Ditched Windows for Linux (And Actually Liked It) - DEV Community

Discover why I switched from Windows to Linux and how it's improved my development workflow, offering control and customization

dev.to

Why I Finally Ditched Windows for Linux (And Actually Liked It)

Bishop Abraham — Sun, 12 Oct 2025 00:14:39 +0000

I've shipped projects on Windows for years. It was familiar, easy, and honestly... it worked.

Until one day I caught myself rebooting my laptop for the third time that week because Windows Update decided 2 PM on a Tuesday was the perfect time for a forced restart.

That was my breaking point. After months of small annoyances and way too much curiosity, I finally made the switch to Linux.

Here's what actually happened (spoiler: I'm not going back).

The Stuff That Pushed Me Over the Edge

Look, Windows works. But it started feeling like I was working around my OS instead of with it.

Resource usage was getting ridiculous. My laptop has decent specs, but Windows acted like it was running on a potato. Background processes everywhere, random CPU spikes, startup times that made me question my life choices.

WSL felt like a band-aid solution. Sure, it gave me a Linux terminal... sort of. But it always felt hacky. Like I was trying to fit a square peg into a round hole while Windows watched and judged.

I had zero control. Want to disable something? Too bad, it's back after the next update.

I wasn't chasing the shiny new thing. I just wanted an OS that got out of my way and let me code.

Making the Jump

I went with Pop!_OS for my first distro. Why? Because I'm not a masochist, and Pop!_OS is basically "Linux for people who want to actually get work done."

Clean interface, stable, great community, and (this is key) it didn't make me feel like I needed a PhD to install my graphics drivers.

What changed immediately:

Real terminal power. No more WSL weirdness. Just a proper Unix environment that does what I tell it to do. Bash scripts actually work. SSH is native. Life is good.

My laptop stopped pretending to be a jet engine. Everything feels lighter and faster. I can run multiple Docker containers, dev servers, and VS Code without my fans screaming for mercy.

Package management that makes sense. Need a tool? sudo apt install whatever. Done. No hunting for .exe files, no sketchy download sites, no installer wizards that try to bundle McAfee.

Blessed silence. No "suggested apps." No random popups about Edge. Just my desktop and my work.

What Actually Got Better

Docker stopped being a drama queen. Containers run natively and fast. No more Docker Desktop eating half my RAM for breakfast.

Git just works. No weird line ending issues. No path problems. No "Git Bash" as a separate thing. It's all just... there.

SSH and networking tools are built-in. As someone who enjoys ethical hacking and networking as a hobby, having proper networking tools native to my OS is chef's kiss.

I can customize EVERYTHING. Window manager? Changed it. Terminal theme? Exactly how I want it. Keyboard shortcuts? All mine. My dev environment actually feels like MY dev environment.

The Parts That Weren't Great

Real talk: it wasn't all smooth sailing.

The learning curve is real. If you're used to clicking through everything, get ready to Google stuff. A lot. I spent my first week constantly asking "how do I..." for things that were two clicks on Windows.

Some apps just don't exist on Linux. Adobe Creative Suite? Nope. Some proprietary dev tools? Sometimes yes, sometimes "here's a workaround." I've found good alternatives for most things, and Wine/VMs handle the rest.

Hardware can be weird. My Bluetooth mouse had a moment. My Wi-Fi drivers needed a chat. Nothing dealbreaking, but expect to do some troubleshooting early on.

But honestly? Every OS has quirks. At least with Linux, when something breaks, I can actually fix it instead of waiting for Microsoft to maybe address it in six months.

Why I'm Staying

Linux isn't perfect. No OS is.

But it fits how I work. It's flexible, powerful, and treats me like an adult who knows what they want to do with their own computer.

Windows felt like renting. Linux feels like owning.

If you're a dev who's tired of fighting their OS, curious about having more control, or just want to see what the hype is about, give Linux a shot. Grab Pop!_OS or Linux Mint, throw it on a USB drive, try it out for a weekend.

Worst case? You learn something new and go back to Windows.

Best case? You realize your computer can actually be a tool that works FOR you.

I'm still learning, still tweaking, still Googling random terminal commands. And honestly? That's part of the fun.

Thinking about making the switch? Got questions? Already on Linux and want to tell me I picked the wrong distro? Let's talk in the comments.

Originally published on My Blog

After building several projects and breaking authentication in creative ways, I finally figured out a setup that actually works and doesn't make me want to throw my laptop out the window.

Bishop Abraham — Sat, 11 Oct 2025 02:59:25 +0000

How I Handle JWT Authentication in Express.js (Without the Headaches) - DEV Community

A simple, human explanation of JWT authentication with Node.js, Express, and MongoDB, without losing your mind.

dev.to

How I Handle JWT Authentication in Express.js (Without the Headaches)

Bishop Abraham — Sat, 11 Oct 2025 02:56:40 +0000

Authentication used to stress me out.

Not because it's conceptually hard, but because every tutorial I found either oversimplified it to the point of being useless, or made it so complicated I needed a PhD to understand what was happening.

After building several projects and breaking authentication in creative ways, I finally figured out a setup that actually works and doesn't make me want to throw my laptop out the window.

Here's how I do it, explained like I'm talking to a friend over coffee, not writing a textbook.

What We're Working With

Node.js & Express - The backend
MongoDB & Mongoose - Where user data lives
bcryptjs - Makes passwords unreadable (important!)
jsonwebtoken - Creates those tokens everyone talks about
cookie-parser - Handles cookies properly
dotenv - Keeps secrets actually secret

Nothing fancy. Nothing you can't install in 30 seconds.

Step 1: Letting People Sign Up

When someone registers, we need to save their info. But we can't just store their password as-is. That's like leaving your house key under the doormat with a sign that says "KEY HERE."

const bcrypt = require('bcryptjs');
const User = require('../models/User');

app.post('/api/register', async (req, res) => {
  const { username, email, password } = req.body;

  // Turn the password into scrambled nonsense
  const hashedPassword = await bcrypt.hash(password, 10);

  const user = new User({ username, email, password: hashedPassword });

  try {
    await user.save();
    res.status(201).json({ message: 'User created successfully' });
  } catch (err) {
    res.status(400).json({ error: 'User already exists or invalid input' });
  }
});

What's happening: We take their password and scramble it (that's the hashing part). Even if someone breaks into your database, they just see gibberish instead of actual passwords.

The hacker after breaking into your database:

Step 2: Logging In and Getting Tokens

This is where it gets interesting. When someone logs in, we give them TWO tokens:

Access token - Short-lived (15 minutes). Like a temporary pass to get into places.
Refresh token - Lasts longer (5 days). Used to get new access tokens without logging in again.

Why two? Security. If someone steals your access token, it expires quickly. The refresh token stays safe in a cookie.

const jwt = require('jsonwebtoken');

const generateAccessToken = (payload) => {
    return jwt.sign(payload, process.env.JWT_SECRET, {expiresIn: '15m'})
}

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

  // Find the user
  const user = await User.findOne({ email });
  if (!user) return res.status(401).json({ error: 'Invalid credentials' });

  // Check if password matches
  const isMatch = await bcrypt.compare(password, user.password);
  if (!isMatch) return res.status(401).json({ error: 'Invalid credentials' });

  // Package up user info
  const payload = {
    id: user._id,
    username: user.username,
    email: user.email
  }

  // Create both tokens
  const refreshToken = jwt.sign(
    payload,
    process.env.JWT_REFRESH_SECRET,
    { expiresIn: '5d' }
  );

  const accessToken = generateAccessToken(payload);

  // Send refresh token as a secure cookie
  res.cookie("refreshToken", refreshToken, {
    secure: true,
    httpOnly: true,
    maxAge: 1000 * 60 * 60 * 24 * 7 // 7 days
  })

  res.status(200).json({ accessToken });
});

What's happening: We check if the user exists, verify their password, then create two tokens. The refresh token goes in a special cookie that JavaScript can't touch (that's the httpOnly part). The access token goes in the response.

Step 3: Getting a New Access Token

After 15 minutes, your access token expires. Instead of making users log in again, we use the refresh token to get a new one.

First, set up cookie parsing in your main file:

const cookieParser = require("cookie-parser");
app.use(cookieParser());

Then create the refresh endpoint:

app.post('/token/refresh', (req, res) => {
  // Get the refresh token from the cookie
  const refreshToken = req.cookies.refreshToken;
  if (!refreshToken) return res.status(401).json({ error: 'No token' });

  // Verify it's legit
  const verifiedToken = jwt.verify(refreshToken, process.env.JWT_REFRESH_SECRET);
  if (!verifiedToken) return res.status(403).json({ error: 'Invalid token' });

  // Create a new access token
  const {id, username, email} = verifiedToken;
  const accessToken = generateAccessToken({id, username, email});

  res.status(200).json({ accessToken });
});

What's happening: We grab the refresh token from the cookie, check if it's valid, and if it is, we create a fresh access token. Simple.

Step 4: Protecting Routes

Now we need to make sure only logged-in users can access certain routes. That's what middleware is for.

const authMiddleware = (req, res, next) => {
  const authHeader = req.headers.authorization;
  if (!authHeader) return res.status(401).json({ error: 'No token provided' });

  // Token comes as "Bearer actualtoken", so we split it
  const token = authHeader.split(' ')[1];

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    req.user = decoded; // Now we know who's making the request
    next();
  } catch (err) {
    res.status(403).json({ error: 'Invalid or expired token' });
  }
};

// Use it on any route you want to protect
app.get('/api/profile', authMiddleware, async (req, res) => {
  const user = await User.findById(req.user.id).select('-password');
  res.json(user);
});

What's happening: The middleware checks if there's a valid token. If yes, attach the user info to the request and move on. If no, reject them. Think of it as a bouncer checking IDs.

Why This Setup Works

It's stateless. No need to store sessions on the server. Everything lives in the tokens.

It scales. Works whether you have 10 users or 10,000.

It's secure enough. Passwords are hashed, tokens expire, and the refresh token is protected.

It's not overwhelming. You can understand what each piece does without a computer science degree.

What I'd Add Next

Right now, this handles basic authentication. But for bigger projects, you might want:

Role-based access - Admins can do more than regular users
Token blacklisting - Invalidate tokens when users log out
Rate limiting - Stop people from spamming your login endpoint

But for most projects? This setup is solid.

The Real Talk

Authentication doesn't have to be scary or complicated. Yes, there are edge cases. Yes, there are more secure ways to do things. But this approach has worked for my projects, and it's simple enough that I can set it up in an hour without pulling my hair out.

If you're just starting with backend auth or you've been putting it off because it seems overwhelming, start here. Get it working, understand what each part does, then optimize later.

Perfect is the enemy of shipped.

Got questions? Different approach? Let me know in the comments. Always happy to learn better ways to do this.

Originally published on My Blog