Forem: Nikita Dmitriev

🧰 How Compilers actually work?

Nikita Dmitriev — Sat, 14 Mar 2026 10:01:03 +0000

This overview explains the C++ compilation process using the GCC compiler and x86-64 architecture. GCC acts as an orchestrator, managing specialized tools for each stage of the pipeline:

1. Lexical Analysis

The compiler (cc1plus) reads the source code and breaks it into tokens. This step removes irrelevant elements like whitespace and comments, detects basic lexical errors, and prepares the code for further analysis

2. Syntax Analysis

The compiler (cc1plus) checks whether the tokens follow the grammar rules of the programming language and builds an Abstract Syntax Tree (AST). The AST represents the logical structure of the program

3. Compilation

The compiler translates the AST into assembly code specific to the target CPU architecture (x86-64). At this stage, the code is still human-readable instructions

4. Assembly

The GNU assembler (as) converts the assembly code into binary machine code, producing an object file (.o or .obj)

5. Linking

Since programs often consist of multiple files and external libraries, the GNU linker (ld) combines all generated object files and required libraries into a single executable file

Program Execution

When the program is run, the operating system loads the executable file into memory and initializes a process. The CPU then begins executing the machine instructions contained in the binary

💡 The transition from source code to machine instructions can be implemented in various ways and is limited only by human imagination. The stages described here correspond to the standard model used by most compilers

🌐 Never buy a .online domain

Nikita Dmitriev — Thu, 26 Feb 2026 02:13:25 +0000

A developer got a free .online domain on Namecheap for a simple web app. The site was super simple: just a few screenshots and a link to the App Store

Everything was fine until, a few weeks later, traffic hit zero. Instead of his site, he saw the dreaded "This site is unsafe" red screen. Google had blacklisted the domain, even though there was absolutely nothing wrong with the content

The worst part wasn't the ban itself — it was the recovery process. Google asked for DNS verification to prove ownership, but Radix (the domain registry) had put the domain on "serverHold", meaning it wouldn't resolve at all. He couldn't prove he owned the site because the registry wouldn't let the site exist. It's a loop

In the end, it took a stroke of luck. After posting the story on Hacker News, the post got enough attention that an "unknown Google hero" manually cleared the blacklist. Only after the flag was removed did the registry finally release the domain and let the site back online

The Lesson

Stick to .com domains
Always set up Google Search Console from the start so you have a way to talk to Google if things go wrong
Use uptime monitoring so you don't find out about a ban too late

It's Time to Learn about Google TPUs in 2026

Nikita Dmitriev — Mon, 12 Jan 2026 22:08:54 +0000

Gemini, Veo, and Nano Banana are impressive, but they are just software. Let's talk about the hardware that makes them possible

Prerequisites

A computer only needs two things to function:

Processor (The Brain)
RAM (The Workbench)

When you open your cool AI IDE:

The app data moves from the SSD to RAM
You do something
The Processor fetches instructions from RAM
It executes them and writes the result back to RAM
The Video Card (GPU) reads from RAM to show it on your screen

A computer can work without a GPU (using a terminal), but it cannot work without a CPU & RAM

PU

Processing Unit — an electronic circuit that manipulates data based on instructions. Physically, it is billions of transistors organized into logical gates (AND, OR, NOT)

Key Components:
– ALU (Arithmetic Logic Unit): The calculator. It does the math (addition, multiplication)
– Control Unit: The traffic cop. It tells data where to go
– Registers/Cache: Ultra-fast internal memory (small, usually 10–200 MB) to keep data close to the ALU

The Three Types

CPU (Central Processing Unit) — The Generalist

– Architecture: Few cores, but very complex and smart
– Role: Serial processing. Great for logic, operating systems, and sequential tasks
– Motto: "I can do anything, but one thing at a time"

GPU (Graphics Processing Unit) — The Parallelist

– Architecture: Thousands of small, simple cores
– Role: Parallel processing. Designed for graphics and simple math tasks performed on massive datasets simultaneously
– Motto: "I can't run an OS, but I can solve 10,000 easy math problems at once"

ASIC (Application-Specific Integrated Circuit) — The Specialist

– Definition: A chip designed for exactly one task. It cannot run Windows or render a video game. It is "hardwired" logic
– Role: Maximum efficiency for a specific algorithm
– Motto: "I do one thing, but I do it faster and cheaper than anyone else"

History

In 2013, Jeff Dean and Jonathan Ross at Google recognized that CPUs and GPUs were structurally inefficient for the coming AI scale. A single metric made the problem clear: three minutes of daily Android Voice Search per user would force Google to double its data center capacity

While GPUs were faster than CPUs, they were still general-purpose devices carrying architectural baggage that made them energy-inefficient for AI

So, they decided to build their own custom silicon (ASIC). 15 months later, the TPU (Tensor Processing Unit) was born

TPU vs GPU

The main bottleneck in AI computing is Memory Access. Moving data is expensive and slow

The Classical Approach (GPU/CPU):

Read Number A from memory into Register
Read Number B from memory into Register
ALU. Multiply A × B
Write result back to memory

The chip spends more time moving data than doing math

The TPU Approach (Systolic Array):

Data loads from memory once
It "flows" into the first row of ALUs
The ALU performs the math and passes the result directly to its neighbor in the next cycle instead of writing intermediate results back to memory
Data moves in a rhythmic wave (like a heart systole) through the entire array

Extremely high throughput for matrix multiplication (the core of AI) with drastically lower power consumption

Impact

If you want to build an AI startup today, you usually pay NVIDIA. You can buy their chips or rent them from almost any provider

Google's model is cloud-based. You can't buy a TPU to put in your server. Instead, Google keeps them in their own data centers and rents access exclusively through this. This allows Google to control the entire stack and they don't have to pay the "NVIDIA Tax"

– In 2024, Apple released a technical paper revealing that "Apple Intelligence" was trained on TPUs, bypassing NVIDIA entirely
– Top AI models like Claude (Anthropic), Midjourney, and Character.ai rely heavily on Google because they offer better performance-per-dollar for massive Transformer models

Future

Google's success with Gemini, Nano Banana, and Veo speaks for itself. The industry has realized that general-purpose hardware is not sustainable for AGI scale, so now everyone is trying to copy Google's homework:

– Microsoft is building Maia
– Amazon is building Trainium
– Meta is building MTIA

However, it's important to understand that the TPU ecosystem does not guarantee a Google monopoly or the downfall of NVIDIA:

– Google is a competitor. For many tech giants, using Google Cloud means helping a rival perfect their own AI models
– NVIDIA is universal and too deeply entrenched in the industry infrastructure to be replaced easily

Apple

I wrote the previous part of the article right after the release of Gemini 3. Now Apple has partnered with Google for its AI, which confirms my arguments. Apple realized they could not close this gap in time, so they are letting Google handle AI operations while they focus on selling hardware

Many say this is a defeat for Apple. But I would say this is a win-win situation. Apple integrates the current best AI into its devices, and Google generates revenue. The deal is valued at $1 billion, suggesting it may be a temporary solution or a bridge while Apple continues training its own models. Notably, Apple has not ended its partnership with OpenAI, but you never know...

watch the stock

The Complete Guide to HTTP Cookies: What Every Web Developer Must Know

Nikita Dmitriev — Wed, 06 Aug 2025 04:27:37 +0000

Introduction
The Cookie Origin Story: Why Do We Even Need Them?
Anatomy of a Cookie: More Than Just a Name and Value
- The HttpOnly Guard: "No JavaScript Allowed!"
- The Secure Guard: "HTTPS Only, Please!"
- Understanding CSRF Attacks
- The SameSite Guard: Elegant Solution
The Browser's Cookie Jar: Understanding the Filtering Pipeline
Best Practices and Recommendations

Introduction

You're building your first authentication system. You've got your login form working, your server validates credentials perfectly, but somehow users keep getting logged out randomly. Or worse, their authentication works on some pages but mysteriously fails on others. Sound familiar?

Welcome to the wonderful, weird, and occasionally infuriating world of HTTP cookies. They're deceptively simple on the surface - just key-value pairs, right? but beneath that simplicity lies a sophisticated security system that trips up even experienced developers.

Today, we're going to demystify cookies completely. Not just the "what," but more importantly, the "why" behind every single behavior. By the end of this article, you'll understand cookies so deeply that authentication bugs will practically debug themselves.

The Cookie Origin Story: Why Do We Even Need Them?

Here's a mind-bending fact: HTTP is stateless. Every single request your browser makes is like meeting someone for the first time. The server has absolutely no memory of who you are or what you did five seconds ago.

Imagine if every time you clicked a link on Amazon, you had to log in again. Click "Add to Cart"? Login. View your cart? Login. Check out? You get the idea. This would be the reality without cookies.

Cookies were invented in 1994 by Lou Montulli at Netscape (yes, that Netscape) to solve this exact problem. He needed a way for servers to recognize returning visitors without maintaining massive server-side session tables for every user on the internet. The solution? Let the client (browser) hold onto a small piece of identifying data and send it back with every request.

Let me show you this dance between browser and server:

Anatomy of a Cookie: More Than Just a Name and Value

When you first learn about cookies, you might think they're just simple key-value pairs, like username=alice. But that's like saying a car is just wheels and an engine. The magic and the complexity comes from all the additional attributes that control exactly when, where, and how that cookie gets sent.

Let's dissect a real cookie and understand what each part does:

Set-Cookie: sessionId=abc123; Domain=.example.com; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=86400

Think of these attributes as security guards with very specific instructions about when to let the cookie through. Each guard has a different job, and they all work together to prevent your authentication tokens from ending up in the wrong hands.

The HttpOnly Guard: "No JavaScript Allowed!"

The HttpOnly attribute is like putting your cookie in a locked safe that only the browser itself can open. When this flag is set, JavaScript code cannot access the cookie through document.cookie.

Why does this matter? Imagine an attacker manages to inject some malicious JavaScript into your site through an XSS vulnerability. Without HttpOnly, they could simply run document.cookie and steal all your users' session tokens. With HttpOnly, that attack vector is completely blocked.

// Without HttpOnly
document.cookie = "regularCookie=stolen";
console.log(document.cookie); // "regularCookie=stolen"

// With HttpOnly
// Server sets: Set-Cookie: authToken=secret; HttpOnly
console.log(document.cookie); // authToken is invisible!
// But the browser still sends it with HTTP requests

The tradeoff: You can't read or manipulate these cookies in your client-side code. This is usually fine for authentication tokens, but it means you need a different approach for things like theme preferences that your JavaScript needs to read.

The Secure Guard: "HTTPS Only, Please!"

The Secure flag is straightforward but critical. It tells the browser to only send this cookie over encrypted HTTPS connections. Without it, your cookie could be intercepted by anyone on the same coffee shop WiFi as your user.

Here's the interesting part: browsers make an exception for localhost during development. This is why your auth cookies work locally even without HTTPS. But the moment you deploy to production without HTTPS, those Secure cookies simply won't be sent.

// In production
// User visits: http://example.com (not HTTPS!)
// Cookie with Secure flag: NOT SENT ❌
// Cookie without Secure flag: SENT ✅ (but vulnerable!)

// On localhost (special exception)
// User visits: http://localhost:3000
// Cookie with Secure flag: SENT ✅ (browser makes exception)

Understanding CSRF Attacks

Cross-Site Request Forgery (CSRF) represents one of the most elegant and dangerous web vulnerabilities. To truly understand how the SameSite cookie attribute protects us, we need to first understand the attack it's defending against and why it was such a significant problem for web security.

The Anatomy of a CSRF Attack

The fundamental issue that makes CSRF possible is actually a feature, not a bug. Browsers automatically include cookies with every request to a domain, regardless of where that request originates. This automatic cookie inclusion is what makes seamless authentication possible across multiple pages of a website. However, this same convenience becomes a massive vulnerability when exploited by attackers.

Think about how authentication typically works on the web. When you log into a website, the server sets a session cookie in your browser. From that point forward, every request you make to that domain automatically includes that cookie, proving you're authenticated. The server doesn't need to ask who you are with each click because your browser helpfully attaches your identity to every request. This system works beautifully until someone figures out how to make your browser send requests you didn't intend to make.

Let me walk you through exactly how a CSRF attack unfolds. Consider Sarah, who's logged into her bank at bank.com with a valid session cookie. While still logged in, she visits another website that appears innocent but contains malicious code. This is where the attack begins.

The truly insidious part of this attack is that everything appears legitimate from the bank's perspective. The request arrives with a valid session cookie, so the bank processes it. Sarah's browser did exactly what it was designed to do, which is include the relevant cookies with the request to bank.com. The attack exploits the very feature that makes the web convenient to use.

Here's what the attacker's malicious page might look like. Notice how simple it is to execute this attack:

<!-- evil-cats.com/cute-cats.html -->
<!DOCTYPE html>
<html>
<head>
    <title>Adorable Cats!</title>
</head>
<body>
    <h1>Look at these cute cats!</h1>
    <img src="cat.jpg" alt="Cute cat">

    <!-- The evil part - completely invisible to Sarah -->
    <form id="evil-form" action="https://bank.com/transfer" method="POST" style="display: none;">
        <input type="hidden" name="recipient" value="attacker-account">
        <input type="hidden" name="amount" value="1000">
        <input type="hidden" name="currency" value="USD">
    </form>

    <script>
        // Submit the form automatically when the page loads
        // Sarah won't even see it happen
        window.onload = function() {
            document.getElementById('evil-form').submit();
        };
    </script>
</body>
</html>

When Sarah visits this page, her browser faithfully sends her bank.com authentication cookie along with the forged transfer request. The bank cannot distinguish between this request and a legitimate one Sarah might make herself. After all, it has her valid session cookie attached to it.

The attack doesn't even need to use a form. It could be as simple as an image tag:

<!-- This also triggers a CSRF attack, though only for GET requests -->
<img src="https://bank.com/transfer?recipient=attacker&amount=1000" 
     style="display: none;">

When the browser tries to load this "image," it sends a GET request to the bank with all of Sarah's cookies attached. If the bank incorrectly accepts GET requests for state-changing operations (a violation of REST principles, but surprisingly common), the attack succeeds.

Why Traditional Defenses Weren't Enough

Before SameSite cookies existed, developers had to implement complex workarounds to prevent CSRF attacks. The most common defense was the CSRF token pattern, and understanding why we needed it helps appreciate the elegance of the SameSite solution.

The CSRF token approach works by including a random, unguessable token with every state-changing request. The server generates this token, ties it to the user's session, and expects it back with form submissions. Since the attacker's site can't read the token (thanks to the Same-Origin Policy), they can't include it in their forged request.

Here's how CSRF tokens work in practice:

// Server-side: Generate and validate CSRF tokens
class CSRFProtection {
    generateToken(sessionId) {
        // Create a random token tied to this session
        const token = crypto.randomBytes(32).toString('hex');

        // Store it server-side, associated with the session
        sessionStorage[sessionId] = {
            csrfToken: token,
            createdAt: Date.now()
        };

        return token;
    }

    validateRequest(request) {
        const sessionId = request.cookies.session;
        const providedToken = request.body.csrfToken || 
                             request.headers['x-csrf-token'];

        // Check if the provided token matches the stored one
        const storedData = sessionStorage[sessionId];

        if (!storedData || !providedToken) {
            throw new Error('CSRF token missing');
        }

        if (storedData.csrfToken !== providedToken) {
            throw new Error('CSRF token mismatch - possible attack!');
        }

        // Token is valid, request is legitimate
        return true;
    }
}

// Client-side: Include CSRF token with requests
async function makeSecureRequest(url, data) {
    // First, get the CSRF token from a meta tag or API endpoint
    const token = document.querySelector('meta[name="csrf-token"]').content;

    const response = await fetch(url, {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'X-CSRF-Token': token  // Include token in header
        },
        credentials: 'include',  // Include cookies
        body: JSON.stringify({
            ...data,
            csrfToken: token  // Or include in body
        })
    });

    return response;
}

This approach works, but it's cumbersome. Every form needs a hidden input with the token. Every AJAX request needs to include it. Developers need to remember to validate it on every endpoint. It's a lot of moving parts, and if you forget even once, you've created a vulnerability.

The real problem with CSRF tokens is that they're fighting the symptom, not the cause. The root issue is that browsers automatically send cookies with cross-site requests. What if we could just tell the browser not to do that?

The SameSite Guard: Elegant Solution

The SameSite cookie attribute is brilliantly simple in concept. It tells the browser when it's allowed to send a cookie with cross-site requests. Instead of complex token systems, we just configure our cookies to not be sent when the request originates from another site. Let me break down exactly how each SameSite value behaves and when you'd use each one.

SameSite=Strict: The Maximum Security Setting

When you set SameSite=Strict, you're telling the browser to only send this cookie when the request originates from the same site that set it. This completely prevents CSRF attacks because the malicious site literally cannot cause the browser to send your cookie.

But here's where it gets interesting and potentially problematic. "Strict" means STRICT. The browser makes no exceptions, even for seemingly innocent scenarios. Watch what happens in different situations:

The strict behavior creates a frustrating user experience in common scenarios. Imagine you send your users an email with a link to their dashboard. When they click that link, they'll appear logged out, even though they have a valid session cookie, because the navigation originated from their email client, not from your site. They'll have to log in again, and then they'll suddenly be logged in everywhere else on your site. This confusion is why Strict mode, despite being the most secure, isn't always the best choice.

SameSite=Lax

SameSite=Lax represents the sweet spot for most applications, which is why it became the default behavior in modern browsers. It provides strong CSRF protection while maintaining a reasonable user experience. The key innovation of Lax mode is that it distinguishes between different types of cross-site requests.

The Lax mode follows what I call the "Safe Methods for Top-Level Navigation" rule. It allows cookies to be sent with cross-site requests, but only when two specific conditions are met. First, the request must be a top-level navigation, meaning the URL in the browser's address bar changes. Second, it must use a safe HTTP method, specifically GET or HEAD, which by REST conventions shouldn't change server state.

Understanding the Two-Minute Window Exception

There's a fascinating implementation detail in how browsers handle SameSite=Lax that many developers don't know about. For the first two minutes after a cookie is set, some browsers temporarily relax the Lax restrictions for top-level POST navigations. This isn't a bug; it's a deliberate compatibility measure to handle a specific scenario that would otherwise break many payment flows and OAuth redirects.

Consider what happens during a typical payment flow. Your user clicks "Pay Now" on your site, which performs a POST request to the payment processor. The payment processor then needs to POST back to your site with the payment result. Without the two-minute window, your Lax cookies wouldn't be sent with that returning POST request, potentially breaking the user's session right when they're completing their purchase.

// The Two-Minute Window in action
const cookieSetTime = new Date('2024-01-15T10:00:00');
const requestTime = new Date('2024-01-15T10:01:30'); // 90 seconds later

// During the two-minute window after cookie creation:
function isWithinTwoMinuteWindow(setTime, requestTime) {
    const timeDiff = requestTime - setTime;
    const twoMinutes = 2 * 60 * 1000; // in milliseconds
    return timeDiff <= twoMinutes;
}

// Example: OAuth redirect flow
// Step 1: Your site sets a Lax cookie
res.cookie('auth_session', token, { sameSite: 'lax' });

// Step 2: User redirected to OAuth provider
// Step 3: OAuth provider POSTs back to your callback URL
// If this happens within 2 minutes: Cookie IS sent (window exception)
// If this happens after 2 minutes: Cookie NOT sent (standard Lax behavior)

// This is why some OAuth flows mysteriously fail if the user 
// takes too long to authorize on the external site!

SameSite=None: When You Actually Need Cross-Site Cookies

Sometimes you genuinely need cookies to work across different sites. Maybe you're building a widget that other sites embed, or you're implementing single sign-on across multiple domains, or you're dealing with payment processing that involves redirects to third-party services. For these cases, you need SameSite=None, but it comes with important requirements and security implications.

First and foremost, SameSite=None only works with the Secure flag. The browser will actually reject cookies that specify SameSite=None without Secure. This requirement exists because if you're intentionally allowing cross-site requests, you absolutely must encrypt them to prevent interception.

// SameSite=None requirements and use cases

// ❌ This will be rejected by the browser
res.cookie('widget_session', token, {
    sameSite: 'none'  // Missing Secure flag!
    // Browser will ignore this cookie entirely
});

// ✅ Correct way to set SameSite=None
res.cookie('widget_session', token, {
    sameSite: 'none',
    secure: true,  // Required!
    httpOnly: true
});

// Common legitimate use cases for SameSite=None:

// 1. Embedded widgets (like chat widgets, analytics, comments)
// Your widget on customer sites needs to authenticate
if (isEmbeddedWidget) {
    res.cookie('widget_auth', token, {
        sameSite: 'none',  // Allows cross-site embed
        secure: true,
        domain: '.widget-provider.com'
    });
}

// 2. Single Sign-On across different domains
// SSO provider needs to work across company1.com, company2.net, etc.
if (isSSOProvider) {
    res.cookie('sso_session', ssoToken, {
        sameSite: 'none',  // Works across all partner sites
        secure: true,
        httpOnly: true
    });
}

// 3. Payment processor callbacks
// Payment gateway needs to POST back with authentication
if (isPaymentCallback) {
    res.cookie('payment_session', sessionId, {
        sameSite: 'none',  // Allows POST from payment processor
        secure: true,
        maxAge: 3600000  // Short-lived for security
    });
}

Using SameSite=None essentially brings you back to the pre-SameSite world where CSRF attacks are possible again. This means you need to implement additional CSRF protections like tokens or origin checking when using None. Think of it as consciously opting out of the browser's automatic CSRF protection because your use case requires it.

The "Same Site" vs "Same Origin" Confusion

One of the most confusing aspects of SameSite cookies is understanding what "same site" actually means, especially since web developers are already familiar with the "same origin" concept. These are different things, and the distinction is crucial for understanding when your cookies will or won't be sent.

The Same Origin Policy is strict and looks at the protocol, domain, and port. If any of these differ, it's a different origin. The Same Site concept is more relaxed and only looks at the registrable domain, which is essentially the domain you could purchase from a registrar.

Let me illustrate this critical distinction with concrete examples:

// Understanding Same Site vs Same Origin

// Same Origin comparison (strict)
function isSameOrigin(url1, url2) {
    const u1 = new URL(url1);
    const u2 = new URL(url2);

    return u1.protocol === u2.protocol &&  // https === https
           u1.hostname === u2.hostname &&  // exact match
           u1.port === u2.port;            // same port
}

// Same Site comparison (relaxed)
function isSameSite(url1, url2) {
    // Extract the "registrable domain" (eTLD+1)
    // This is the domain you can actually register
    const getSite = (url) => {
        const u = new URL(url);
        // Simplified - real implementation uses Public Suffix List
        const parts = u.hostname.split('.');
        if (parts.length >= 2) {
            return parts.slice(-2).join('.');  // last two parts
        }
        return u.hostname;
    };

    return getSite(url1) === getSite(url2);
}

// Let's test with real examples:

// Different ORIGINS, but SAME SITE
isSameOrigin('https://app.example.com', 'https://api.example.com');  // false
isSameSite('https://app.example.com', 'https://api.example.com');    // true!

// This is why SameSite=Strict cookies still work across subdomains
// But if you're making fetch() requests between subdomains,
// you still need CORS headers because of Same Origin Policy

// Different protocols: Different ORIGIN, SAME SITE
isSameOrigin('https://example.com', 'http://example.com');  // false
isSameSite('https://example.com', 'http://example.com');    // true

// Different ports: Different ORIGIN, SAME SITE  
isSameOrigin('https://example.com:3000', 'https://example.com:4000');  // false
isSameSite('https://example.com:3000', 'https://example.com:4000');    // true

// Completely different domains: Different everything
isSameOrigin('https://example.com', 'https://google.com');  // false
isSameSite('https://example.com', 'https://google.com');    // false

This distinction explains why you might encounter situations where your cookies are sent (because it's the same site) but your JavaScript fetch() calls fail with CORS errors (because it's a different origin). The browser applies different security policies for different aspects of web security.

The Browser's Cookie Jar: Understanding the Filtering Pipeline

To truly understand how SameSite and other cookie defenses work, we need to understand the sophisticated system that browsers use to manage cookies. The browser maintains what we call a "cookie jar" - essentially a database indexed by domain, path, and name. Think of it as a sophisticated filtering system that runs every single time you make an HTTP request. The browser needs to decide which cookies from potentially hundreds stored locally should be sent with each specific request.

This isn't just a simple lookup table. Every time your browser makes a request—whether it's loading an image, submitting a form, or making a fetch call-it runs through an elaborate filtering pipeline to determine exactly which cookies should be included. Understanding this pipeline is crucial because it explains why your authentication might work in some scenarios but mysteriously fail in others.

Let's visualize what's actually stored in the cookie jar to understand what the browser is working with:

right click on this image and "open image in a new tab"

This filtering happens automatically and invisibly every single time your browser makes a request. Understanding this process is crucial because when your authentication fails, it's often because one of these filters rejected your auth cookie. The most common culprits in modern web apps are the SameSite restrictions (especially for single-page applications making cross-origin API calls) and Secure flag issues during local development.

What makes this system particularly interesting is that it's completely transparent to both users and most developers. You never see the rejected cookies or get explicit error messages about why a cookie wasn't sent. The browser simply excludes cookies that fail any check, and your request proceeds without them. This is why debugging cookie issues can feel like fighting ghosts - you're battling against invisible security rules that the browser never explicitly tells you about.

This sophisticated filtering system is also why Server-Side Rendering (SSR) and Server Components can be tricky with authentication. When your server makes a request to another service, it bypasses this entire browser-based security system. The server needs to manually forward the appropriate cookies, essentially recreating the authorization context that the browser would have automatically handled. Without understanding this filtering pipeline, it's easy to accidentally create security vulnerabilities or authentication failures in your SSR implementations.

Best Practices and Recommendations

After working with SameSite cookies across numerous production applications, I've developed a set of best practices that will save you hours of debugging frustration.

For authentication cookies, start with SameSite=Lax as your default. It provides excellent CSRF protection while maintaining good user experience. Only use Strict if you have specific security requirements and can accept the UX tradeoffs. Reserve None for cases where cross-site access is absolutely necessary, and always implement additional CSRF protection when using it.

Consider using different cookies for different purposes. Your main authentication cookie can be Lax for the best balance, while you might have a separate Strict cookie for highly sensitive operations like payment processing or account changes. This gives you granular control over security boundaries.

// Recommended cookie strategy for modern applications

class CookieStrategy {
    // Main authentication cookie - balanced security and UX
    setAuthCookie(res, token) {
        res.cookie('auth', token, {
            httpOnly: true,
            secure: true,
            sameSite: 'lax',  // Good default
            maxAge: 7 * 24 * 60 * 60 * 1000,  // 1 week
            path: '/'
        });
    }

    // High-security operations cookie - maximum protection
    setSecureActionCookie(res, token) {
        res.cookie('secure_action', token, {
            httpOnly: true,
            secure: true,
            sameSite: 'strict',  // Maximum security
            maxAge: 15 * 60 * 1000,  // 15 minutes only
            path: '/account'  // Restricted path
        });
    }

    // Cross-domain SSO cookie - needed for integrations
    setSSOCookie(res, token) {
        res.cookie('sso', token, {
            httpOnly: true,
            secure: true,
            sameSite: 'none',  // Required for cross-site
            maxAge: 60 * 60 * 1000,  // 1 hour
            domain: '.sso-provider.com'
        });

        // Additional CSRF protection since we're using None
        res.cookie('csrf', generateCSRFToken(), {
            secure: true,
            sameSite: 'strict',  // CSRF token can be strict!
            maxAge: 60 * 60 * 1000
        });
    }

    // Remember me cookie - long-lived but limited scope
    setRememberMeCookie(res, token) {
        res.cookie('remember', token, {
            httpOnly: true,
            secure: true,
            sameSite: 'lax',
            maxAge: 30 * 24 * 60 * 60 * 1000,  // 30 days
            path: '/auth'  // Only for auth endpoints
        });
    }
}

Always test your cookie behavior across different browsers and scenarios. Set up automated tests that verify cookies work correctly for common user journeys like clicking email links, OAuth flows, and payment processing. Don't assume that because it works in Chrome, it will work the same way in Safari or Firefox.

Remember that SameSite is just one layer of defense. Continue to follow other security best practices like using HTTPS everywhere, implementing proper CORS headers, validating origins for sensitive operations, and keeping your authentication tokens short-lived with refresh token rotation.

Detailed Explanation of Hashing

Nikita Dmitriev — Fri, 01 Aug 2025 21:10:45 +0000

The Library Card Revelation
What is Hashing?
The Four Fundamental Properties
Building Your First Hash Function
Real-World Hashing: Where the Magic Happens
The Collision: When Different Inputs Produce Same Hash Outputs
A Brief History
Modern Applications: Hashing Everywhere

The Library Card Revelation

Picture this: You walk into a massive library containing millions of books. You need to find "The Great Gatsby" by F. Scott Fitzgerald. Without any organization system, you'd have to check every single book until you found it - potentially examining millions of volumes! But instead, you walk to a simple card catalog, look up "Fitzgerald," and instantly get the exact shelf location: 813.52 FIT.

This everyday library experience reveals the core magic of hashing - one of computer science's most elegant and powerful concepts. Just as the library transforms "F. Scott Fitzgerald" into "813.52 FIT" for instant book location, hashing transforms any piece of data into a compact, fixed-size "address" that enables lightning-fast storage and retrieval.

But here's where it gets fascinating: hashing isn't just about finding books. It's the invisible force securing your passwords, powering Bitcoin mining, enabling Google's instant search results, and ensuring the evidence in criminal trials hasn't been tampered with. Let's explore why this mathematical transformation has become one of the most important concepts in our digital world.

What is Hashing?

At its heart, hashing is like creating a digital fingerprint for any piece of information. Just as your fingerprint uniquely identifies you while being much smaller than your entire body, a hash value uniquely identifies data while being much smaller than the original information.

Think of hashing as a special kind of one-way mathematical recipe. You put ingredients (your data) into this recipe (the hash function), and it produces a specific dish (the hash value). The remarkable property? The same ingredients always produce the same dish, but you can't reverse-engineer the ingredients from the final dish.

Here's a simple example using a basic hash function on the word "HELLO":

Input: "HELLO"
Hash Function Process: H(72) + E(69) + L(76) + L(76) + O(79) = 372
Final Hash: 372 % 10 = 2

So "HELLO" gets the hash value 2. Every time we hash "HELLO" with this function, we'll always get 2. But if we know the answer is 2, we can't easily determine the original word was "HELLO."

The Three Essential Components

Every hashing operation consists of three fundamental parts, much like our library example:

The Input represents your original data - whether it's a word like "HELLO," a password like "MySecret123," or an entire file containing thousands of pages. This is the raw information you want to transform into a hash.

The Hash Function acts as the mathematical transformation engine. It's the "recipe" that converts your input into a hash value. Different hash functions use different mathematical approaches, from simple addition to complex cryptographic algorithms like SHA-256.

The Hash Output (or hash value/hash digest) is the fixed-size result produced by the hash function. Regardless of whether your input is a single character or a massive file, the hash output is always the same size for a given hash function - SHA-256 always produces exactly 256 bits (64 hexadecimal characters).

The Four Fundamental Properties

What makes hash functions mathematically fascinating? They possess three crucial properties that define their core nature.

1. Deterministic: Same Input Always Produces Same Hash

A hash function must be completely deterministic - like a mathematical equation that always gives the same result. If you hash "password123" today and get the result "7a58db2e," you must get exactly "7a58db2e" every time you hash "password123" in the future, on any computer, anywhere in the world.

This isn't just convenient - it's mathematically essential. Without determinism, hash functions would be useless for verification, data integrity, or any practical application.

Example:

SHA-256("Hello") = 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969
This result is exactly the same every single time, forever

2. Irreversible: Cannot Retrieve Input from Hash Output

Hash functions are one-way mathematical transformations. Given a hash output, it is computationally impossible to determine what the original input was. This isn't just difficult - it's mathematically designed to be irreversible.

Think of it like this: if you blend a fruit smoothie, you can't "un-blend" it back into separate fruits. Similarly, hash functions "blend" input data in a way that cannot be undone.

Why this matters:

Security: Even if someone steals a database of password hashes, they can't directly recover the original passwords
Privacy: You can prove you know something without revealing what it is
Integrity: You can detect changes without storing the original data

3. Collision Resistance: Mathematically Impossible to Avoid All Collisions

Here's the fascinating mathematical reality: collisions are inevitable. No hash function can avoid them entirely, and this isn't a design flaw - it's a mathematical certainty.

The Pigeonhole Principle proves this: If you have an infinite number of possible inputs (any data of any size) but only a finite number of possible hash outputs (say, 2^256 for SHA-256), then multiple inputs must eventually produce the same hash output.

However, good hash functions make finding collisions practically impossible:

Weak Collision Resistance: Given one input and its hash, it should be computationally infeasible to find a different input that produces the same hash
Strong Collision Resistance: It should be computationally infeasible to find any two different inputs that produce the same hash

Real-world impact: While collisions must exist mathematically, finding them in SHA-256 would require more computational power than exists on Earth.

4. Avalanche Effect

While not one of the core mathematical requirements, the avalanche effect makes hash functions particularly powerful for security applications. A tiny change in input should produce a dramatically different hash output.

Example:

SHA-256("Hello World") = a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e
SHA-256("Hello World!") = 7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069

Adding one exclamation mark completely scrambled the entire hash - this makes tampering detection extremely reliable.

Building Your First Hash Function

Let's create a simple hash function together to understand the underlying mechanics. We'll build something educational rather than cryptographically secure - think of it as learning to ride a bicycle before attempting motorcycle stunts.

The Mid-Square Method

The mid-square method provides an excellent learning example because you can calculate it by hand and observe how it "mixes" the input data:

def mid_square_hash(key, table_size):
    """
    A simple educational hash function using the mid-square method

    Step 1: Square the key
    Step 2: Extract middle digits
    Step 3: Take modulo of table size
    """
    # Convert key to number if it's a string
    if isinstance(key, str):
        # Sum ASCII values of characters
        key = sum(ord(char) for char in key)

    # Step 1: Square the key
    squared = key * key
    print(f"Step 1 - Squared: {key}² = {squared}")

    # Step 2: Extract middle digits
    # Convert to string to manipulate digits
    squared_str = str(squared)
    length = len(squared_str)

    # Take middle 3 digits (or available digits if shorter)
    if length >= 3:
        start = (length - 3) // 2
        middle = squared_str[start:start + 3]
    else:
        middle = squared_str

    middle_value = int(middle)
    print(f"Step 2 - Middle digits: {middle_value}")

    # Step 3: Take modulo of table size
    hash_value = middle_value % table_size
    print(f"Step 3 - Final hash: {middle_value} % {table_size} = {hash_value}")

    return hash_value

# Let's try it with the word "CAT"
result = mid_square_hash("CAT", 100)

Walking through "CAT":

C(67) + A(65) + T(84) = 216
216² = 46,656
Middle digits: 665
665 % 100 = 65

So "CAT" hashes to index 65 in a table of size 100.

Understanding Why This Works

The mid-square method works because squaring amplifies differences between inputs. Two similar numbers like 216 and 217 become 46,656 and 47,089 when squared - much more different than the original values. The middle digits capture this amplified difference while discarding potentially predictable patterns in the first and last digits.

Notice the beautiful transformation: we started with a variable-length input ("CAT") and produced a fixed-size hash output (65). This consistent output size is crucial - whether we hash a single word or an entire novel, our hash function produces the same size result.

Try this yourself: What happens when you hash "DOG" using the same method? Can you predict the result before calculating?

Real-World Hashing: Where the Magic Happens

Now that you understand the mechanics, let's explore how hashing powers the digital world around us.

Password Security: Your Digital Guardian

Every time you log into a website, hashing protects your password through a sophisticated process. Websites don't actually store your password - they store its hash value instead.

Here's how it works with bcrypt, the gold standard for password hashing:

When you create an account:

You enter password: "MySecret123"
bcrypt adds random salt: "MySecret123" + "a8f5f167f44f4964e6c998dee827110c"
bcrypt hashes the result: "$2b$10$3euPcmQFCiblsZeEu5s7p.9OVHgeHWFDk9nhMqZ0m/3pd/lhwZgES"
Only the hash gets stored in the database

When you log in:

You enter password: "MySecret123"
System retrieves stored hash and extracts the salt
System applies same process: hash("MySecret123" + salt)
If the new hash matches the stored hash, access granted

The beautiful security here? Even if hackers steal the database, they only get meaningless hash values. They can't reverse-engineer your actual passwords because of hashing's one-way nature.

Bitcoin Mining: The Computational Race

Bitcoin provides perhaps the most dramatic example of hashing in action. Bitcoin miners are essentially competing in a massive computational race to find specific hash values.

Here's the challenge Bitcoin sets: Find a number (called a nonce) that, when combined with transaction data and hashed with SHA-256, produces a hash value starting with a specific number of zeros.

Example Bitcoin Mining Problem:

Block data: "TransactionData + PreviousBlockHash + 1847563"
SHA-256 hash: 00000000a2c4ff82c4d4c3e2e1b8e8d7f6e5d4c3b2a1908f7e6d5c4b3a29180

The hash starts with eight zeros! Finding such a hash requires trying millions or billions of different nonce values until one produces the required pattern. The current Bitcoin network performs over 150 exahashes per second - that's 150,000,000,000,000,000,000 hash operations every second globally.

Digital Forensics: The Truth Detector

Law enforcement relies on hashing to ensure evidence integrity. When investigators seize a computer, they immediately calculate hash values for all files. These digital fingerprints prove that evidence hasn't been tampered with during analysis.

Example forensic process:

Seize laptop containing potential evidence
Calculate SHA-256 hash: "4d186321c1a7f0f354b297e8914ab240c7e8a4c3a321b2c4d5e6f7a8b9c0d1e2"
Perform analysis on copied data
Recalculate hash after analysis
If hashes match, evidence integrity proven in court

Any modification - even changing a single bit—would produce a completely different hash, immediately revealing tampering.

The Collision: When Different Inputs Produce Same Hash Outputs

Now we encounter one of hashing's most fascinating challenges: hash collisions. A collision occurs when two different inputs produce the same hash output. While this might seem like a flaw, it's actually inevitable and leads to some of the most elegant solutions in computer science.

Why Collisions Are Inevitable

The pigeonhole principle guarantees that collisions must occur. If you have more items than containers, at least one container must hold multiple items. Hash functions map an infinite input space (any possible data) to a finite output space (fixed-size hash values). Therefore, collisions are mathematically inevitable.

Consider a simple example: if our hash function produces values from 0 to 99 (100 possibilities), and we hash 101 different inputs, at least two must produce the same hash output.

The Birthday Paradox in Action

The timing of collisions often surprises people due to the birthday paradox. In a room of just 23 people, there's a 50% chance that two people share the same birthday, despite 365 possible days. Similarly, for a hash function that produces 1,000 different possible outputs, you'll likely encounter your first collision after hashing only about 37 different inputs - much sooner than intuition suggests.

import math

def collision_probability(num_inputs, output_space_size):
    """Calculate probability of at least one collision"""
    # Using birthday paradox formula
    probability = 1.0
    for i in range(num_inputs):
        probability *= (output_space_size - i) / output_space_size
    return 1.0 - probability

# For a hash function with 1000 possible outputs
output_space = 1000
for inputs in [10, 20, 30, 40, 50]:
    prob = collision_probability(inputs, output_space)
    print(f"{inputs} inputs: {prob:.2%} collision probability")

Understanding Hash Collisions

When collisions occur in cryptographic contexts, they represent potential security vulnerabilities. For example, if an attacker can find two different files that produce the same hash output, they might be able to substitute a malicious file for a legitimate one without detection.

However, for most practical purposes, well-designed hash functions make finding collisions computationally infeasible. Modern cryptographic hash functions like SHA-256 are specifically designed so that finding two inputs that produce the same hash output would require astronomical computational resources.

A Brief History

The evolution of hashing reflects humanity's growing need to organize and secure information.

The Foundation Era (1950s-1960s) Hans Peter Luhn at IBM pioneered hashing concepts while developing the KWIC (Key Word in Context) indexing system. His insight that data could be "chopped up" and reorganized for faster access laid the groundwork for modern hash tables.

The Cryptographic Awakening (1990s) Ronald Rivest's MD5 algorithm brought hashing into the security spotlight. Suddenly, hashing wasn't just about data storage - it was about protecting information integrity and authenticity. However, as computing power grew, MD5's vulnerabilities became apparent.

The Security Arms Race (2000s-Present) The development of SHA-1, then SHA-2, then SHA-3 represents an ongoing arms race between cryptographic innovation and attack sophistication. The 2017 SHAttered attack demonstrated practical SHA-1 collisions, forcing widespread migration to stronger algorithms.

Today's landscape includes:

SHA-256: The current security standard
SHA-3: Mathematical diversity insurance
BLAKE3: Performance breakthrough
Argon2: Memory-hard password protection

Modern Applications: Hashing Everywhere

Once you understand hashing, you'll start noticing it everywhere in modern technology.

Database Performance: PostgreSQL uses hash indexes to transform "WHERE user_id = 12345" queries from linear scans through millions of records into instant O(1) lookups.

Load Balancing: Companies like Netflix use consistent hashing to distribute billions of requests across thousands of servers. When you stream a movie, hashing determines which server handles your request.

Content Distribution: Blockchain networks use hashing to create tamper-evident ledgers. Each block contains the hash of the previous block, creating an unbreakable chain of trust.

Data Deduplication: Cloud storage services use hashing to detect duplicate files. If a million users upload the same photo, the service stores it once and uses hash values to reference it.

Explanation of preventDefault(), stopPropogation()

Nikita Dmitriev — Wed, 30 Jul 2025 10:22:46 +0000

The Problem: Events Have a Mind of Their Own
Understanding Event Flow: The Journey of a Click
preventDefault(): Stopping Default Browser Behaviors
stopPropagation(): Controlling Event Flow
Using Both Together: The Power Combo
Visual Comparison: preventDefault vs stopPropagation
Common Pitfalls
Best Practices: When to Use What
The Secret Third Option: stopImmediatePropagation()
Debugging Event Issues
Conclusion

Picture this: You're building a sleek dropdown menu. Everything looks perfect until you click a link inside it, and suddenly the menu closes when it shouldn't. Or worse, clicking a button inside a form accidentally submits the entire form. Sound familiar?

These frustrating scenarios happen when we don't properly control how events flow through our web pages. Today, we're diving deep into two powerful JavaScript methods that give us precise control over event behavior: preventDefault() and stopPropagation().

The Problem: Events Have a Mind of Their Own

Before we jump into solutions, let's understand the chaos we're trying to tame. In the browser's world, events don't just happen in isolation. They travel, they bubble, they trigger default behaviors, and sometimes they cause a cascade of unintended consequences.

Think of events like dropping a stone in a pond. The ripples spread outward, affecting everything in their path. Without proper control, one small click can trigger a chain reaction throughout your entire page.

Understanding Event Flow: The Journey of a Click

To master event control, we first need to understand how events travel through the DOM. This journey happens in three distinct phases:

1. Capturing Phase (Going Down)

Imagine you're in a tall building and someone on the top floor drops a ball. The ball passes by each floor on its way down. Similarly, when you click a button, the event starts at the window and travels down through each parent element until it reaches your button.

2. Target Phase (The Destination)

The ball reaches the ground floor - this is where the event arrives at the element you actually clicked.

3. Bubbling Phase (Coming Back Up)

Now imagine the ball bounces back up, passing each floor again. The event bubbles back up through all the parent elements, all the way back to the window.

// Let's visualize this journey
document.addEventListener('click', function(event) {
    console.log('Capturing: Document level', event.target);
}, true); // true = capturing phase

document.body.addEventListener('click', function(event) {
    console.log('Capturing: Body level', event.target);
}, true);

button.addEventListener('click', function(event) {
    console.log('Target: Button clicked!');
});

document.body.addEventListener('click', function(event) {
    console.log('Bubbling: Body level', event.target);
}); // false or omitted = bubbling phase

document.addEventListener('click', function(event) {
    console.log('Bubbling: Document level', event.target);
});

preventDefault(): Stopping Default Browser Behaviors

Now that we understand event flow, let's tackle our first hero: preventDefault().

What It Does

preventDefault() tells the browser: "Hey, I know you usually do something specific when this happens, but please don't do it this time. I've got it covered."

Common Use Cases

Here are situations where preventDefault() saves the day:

1. Custom Form Handling

const form = document.querySelector('#signup-form');

form.addEventListener('submit', function(event) {
    // Stop the form from submitting the traditional way
    event.preventDefault();

    // Now we can handle it ourselves
    const formData = new FormData(form);

    // Maybe validate the data
    if (!validateEmail(formData.get('email'))) {
        showError('Please enter a valid email');
        return;
    }

    // Send it via AJAX instead
    fetch('/api/signup', {
        method: 'POST',
        body: formData
    });
});

2. Creating Single Page Application Navigation

const navLinks = document.querySelectorAll('nav a');

navLinks.forEach(link => {
    link.addEventListener('click', function(event) {
        // Don't navigate away from the page
        event.preventDefault();

        // Update the page content dynamically instead
        const page = this.getAttribute('href');
        loadPageContent(page);

        // Update the URL without reloading
        history.pushState({}, '', page);
    });
});

3. Custom Drag and Drop

const dropZone = document.querySelector('.drop-zone');

dropZone.addEventListener('dragover', function(event) {
    // Prevent the browser's default "not allowed" cursor
    event.preventDefault();

    // Show our custom visual feedback instead
    this.classList.add('drag-over');
});

dropZone.addEventListener('drop', function(event) {
    // Prevent the browser from navigating to the dropped file
    event.preventDefault();

    // Handle the dropped files ourselves
    const files = event.dataTransfer.files;
    handleFileUpload(files);
});

What preventDefault() Doesn't Do

Here's a crucial point: preventDefault() does NOT stop event propagation. The event still bubbles up through the DOM tree, triggering any other event listeners along the way.

// This link is inside a div with its own click handler
link.addEventListener('click', function(event) {
    event.preventDefault(); // Stops navigation
    console.log('Link clicked');
});

div.addEventListener('click', function(event) {
    // This STILL fires! preventDefault doesn't stop bubbling
    console.log('Div clicked too!');
});

stopPropagation(): Controlling Event Flow

Enter our second hero: stopPropagation(). While preventDefault() deals with browser behaviors, stopPropagation() controls the event's journey through the DOM.

What It Does

stopPropagation() is like putting up a roadblock. It tells the event: "Stop right here. Don't go any further up (or down) the DOM tree."

Common Use Cases

1. Nested Interactive Elements

// Imagine a card that's clickable, but has buttons inside it
const card = document.querySelector('.product-card');
const buyButton = card.querySelector('.buy-button');

card.addEventListener('click', function() {
    // Clicking anywhere on the card shows details
    showProductDetails();
});

buyButton.addEventListener('click', function(event) {
    // Stop the card's click handler from firing
    event.stopPropagation();

    // Only add to cart, don't show details
    addToCart();
});

2. Dropdown Menus That Stay Open

const dropdown = document.querySelector('.dropdown');
const dropdownMenu = dropdown.querySelector('.dropdown-menu');

// Clicking outside closes the dropdown
document.addEventListener('click', function() {
    dropdown.classList.remove('open');
});

// But clicking inside the dropdown shouldn't close it
dropdownMenu.addEventListener('click', function(event) {
    event.stopPropagation();
});

3. Modal Dialogs

const modal = document.querySelector('.modal');
const modalContent = modal.querySelector('.modal-content');

// Clicking the dark overlay closes the modal
modal.addEventListener('click', function() {
    closeModal();
});

// But clicking the modal content itself shouldn't close it
modalContent.addEventListener('click', function(event) {
    event.stopPropagation();
});

The Hidden Danger of stopPropagation()

While stopPropagation() seems like a quick fix, it can create problems. Other parts of your application (or third-party libraries) might be listening for events higher up the DOM tree. By stopping propagation, you might break functionality you didn't even know existed.

// Somewhere in your analytics code
document.addEventListener('click', function(event) {
    // Track all clicks for heatmap data
    analytics.track('click', {
        element: event.target.tagName,
        position: { x: event.clientX, y: event.clientY }
    });
});

// Your dropdown code
dropdownItem.addEventListener('click', function(event) {
    event.stopPropagation(); // Oops! Now analytics won't track this click
    selectItem(this.textContent);
});

Using Both Together: The Power Combo

Sometimes you need both methods to achieve the desired behavior:

// A link inside a clickable card
cardLink.addEventListener('click', function(event) {
    // Don't navigate away
    event.preventDefault();

    // Don't trigger the card's click handler
    event.stopPropagation();

    // Do our custom action
    openInModal(this.href);
});

Better Alternatives: Event Delegation and Conditional Logic

Instead of stopping propagation everywhere, consider these cleaner approaches:

Event Delegation

// Instead of this (with stopPropagation)
menuItems.forEach(item => {
    item.addEventListener('click', function(event) {
        event.stopPropagation();
        handleMenuItemClick(this);
    });
});

// Try this (checking the target)
menu.addEventListener('click', function(event) {
    // Only handle clicks on menu items
    if (event.target.matches('.menu-item')) {
        handleMenuItemClick(event.target);
    }
    // Clicks on other elements naturally do nothing
});

Conditional Logic

// Instead of this
button.addEventListener('click', function(event) {
    event.stopPropagation();
    doSomething();
});

container.addEventListener('click', function(event) {
    doSomethingElse();
});

// Try this
container.addEventListener('click', function(event) {
    if (event.target === button) {
        doSomething();
    } else {
        doSomethingElse();
    }
});

Visual Comparison: preventDefault vs stopPropagation

Common Pitfalls

Pitfall 1: Using preventDefault() on Non-Cancelable Events

// This won't work - scroll events can't be prevented this way
window.addEventListener('scroll', function(event) {
    event.preventDefault(); // Does nothing!
});

// Instead, use CSS or other techniques
body.style.overflow = 'hidden'; // Prevents scrolling

Pitfall 2: Forgetting That Some Events Don't Bubble

// These events don't bubble, so stopPropagation is meaningless
input.addEventListener('focus', function(event) {
    event.stopPropagation(); // Unnecessary - focus doesn't bubble
});

// Use capturing phase if you need to intercept these
parentElement.addEventListener('focus', function(event) {
    console.log('Child element focused:', event.target);
}, true); // true = capturing phase

Pitfall 3: Breaking Third-Party Code

// Your code
clickableElement.addEventListener('click', function(event) {
    event.stopPropagation(); // Seems harmless...
});

// Bootstrap's dropdown closer (simplified)
document.addEventListener('click', function() {
    // This never runs for clicks on your element!
    closeAllDropdowns();
});

Best Practices: When to Use What

Use preventDefault() when:

You want to handle form submissions via JavaScript
You're building a single-page application with custom routing
You need custom drag-and-drop behavior
You want to disable right-click context menus for a specific element
You're implementing custom keyboard shortcuts

Use stopPropagation() when:

You have nested interactive elements (buttons inside clickable cards)
You're building dropdown menus or modals
You need to prevent parent elements from responding to child element events
But always consider if there's a better way first!

Avoid Both When Possible:

Use pointer-events: none in CSS for non-interactive overlays
Use event delegation and check event.target
Design your HTML structure to avoid conflicts
Use the capture phase strategically

The Secret Third Option: stopImmediatePropagation()

There's actually a third method worth knowing:

element.addEventListener('click', function(event) {
    console.log('Handler 1');
    event.stopImmediatePropagation();
});

element.addEventListener('click', function(event) {
    console.log('Handler 2'); // This won't run!
});

// stopImmediatePropagation() stops other handlers on the SAME element
// AND stops propagation to other elements

Debugging Event Issues

When events aren't behaving as expected, use these techniques:

// Trace event flow
function traceEvent(event) {
    console.log({
        phase: event.eventPhase === 1 ? 'capturing' : 
               event.eventPhase === 2 ? 'target' : 'bubbling',
        currentTarget: event.currentTarget,
        target: event.target,
        defaultPrevented: event.defaultPrevented,
        propagationStopped: event.cancelBubble
    });
}

// Add to any event listener
element.addEventListener('click', function(event) {
    traceEvent(event);
    // Your code here
});

Conclusion

Understanding preventDefault() and stopPropagation() transforms you from someone who fights with events to someone who conducts them like an orchestra. These methods are powerful tools, but like any tool, they're best used with precision and purpose.

Fetch Wrapper for Next.js: A Deep Dive into Best Practices

Nikita Dmitriev — Tue, 29 Jul 2025 17:57:26 +0000

Picture this: You're building your dream Next.js application, and you're happily making API calls with the native fetch function. Everything seems great until... your app goes to production. Suddenly, you're drowning in repetitive error handling code, wrestling with authentication tokens scattered across components, and pulling your hair out trying to debug why some requests work on the server but fail on the client.

Sound familiar? You're not alone. While Next.js extends fetch with powerful caching and revalidation features, the core challenge remains: building a robust, production-ready API layer requires much more than raw fetch calls.

Today, we're going to craft a production-ready fetch wrapper that will transform your API layer from a source of headaches into a joy to work with. We'll explore not just how to build it, but why each decision matters and how it fits into Next.js's unique execution model.

The Problem with Raw Fetch (Even in Next.js)

Let's start by looking at what most developers write when they first encounter fetch:

// The naive approach - don't do this in production!
async function getUser(id) {
  const response = await fetch(`/api/users/${id}`);
  const user = await response.json();
  return user;
}

This looks innocent enough, but it's a ticking time bomb. Here's what happens when the API returns a 404:

// This will throw an error when trying to parse JSON from an error response
const user = await getUser('nonexistent-id'); // 💥 Boom!

The fundamental issue is that fetch doesn't automatically handle HTTP error statuses. A 404, 500, or any other error status is considered a "successful" request by fetch—it only rejects on network errors. You still need to manually check response.ok and handle errors appropriately, even in Next.js.

But that's just the beginning. In a real application, you'll also need to handle:

Authentication tokens for protected routes
Consistent error handling across your app
Request/response transformation (like automatic JSON parsing)
Loading states and error boundaries
TypeScript support for type safety
Different behavior for server vs. client contexts in Next.js

Let's build a wrapper that elegantly solves all these problems.

Designing Our Fetch Wrapper Architecture

Before we dive into code, let's think about what our ideal wrapper should provide:

Automatic error handling for HTTP status codes
Built-in JSON parsing with proper error handling
Authentication token management
TypeScript support with proper typing
Next.js context awareness (server vs. client)
Extensible configuration for different environments
Consistent API that feels natural to use

Think of our wrapper as a friendly assistant that handles all the tedious, error-prone tasks while giving you a clean, predictable interface to work with.

Building the Foundation: Core Wrapper Structure

Let's start with the basic structure. We'll create a file called lib/api.ts (following Next.js conventions):

// lib/api.ts
interface ApiConfig {
  baseUrl?: string;
  defaultHeaders?: Record<string, string>;
  timeout?: number;
}

interface ApiResponse<T = any> {
  data: T;
  status: number;
  headers: Headers;
}

class ApiError extends Error {
  constructor(
    message: string,
    public status: number,
    public response?: Response
  ) {
    super(message);
    this.name = 'ApiError';
  }
}

class ApiClient {
  private config: Required<ApiConfig>;

  constructor(config: ApiConfig = {}) {
    this.config = {
      baseUrl: config.baseUrl || '',
      defaultHeaders: {
        'Content-Type': 'application/json',
        ...config.defaultHeaders,
      },
      timeout: config.timeout || 10000,
    };
  }

  private async makeRequest<T>(
    endpoint: string,
    options: RequestInit = {}
  ): Promise<ApiResponse<T>> {
    // We'll implement this next
  }
}

Why a class-based approach? While functional approaches are popular in React, a class gives us several advantages:

State management: We can store configuration and potentially cache data
Method chaining: We can add fluent API methods later
Inheritance: Teams can extend the base class for specific use cases
Encapsulation: Private methods keep the implementation details hidden

The Heart of the Wrapper: Request Logic

Now let's implement the core request logic. This is where the magic happens:

// lib/api.ts (continued)
class ApiClient {
  // ... previous code

  private async makeRequest<T>(
    endpoint: string,
    options: RequestInit = {}
  ): Promise<ApiResponse<T>> {
    const url = this.buildUrl(endpoint);
    const requestOptions = this.buildRequestOptions(options);

    try {
      // Create AbortController for timeout
      const controller = new AbortController();
      const timeoutId = setTimeout(() => controller.abort(), this.config.timeout);

      const response = await fetch(url, {
        ...requestOptions,
        signal: controller.signal,
      });

      clearTimeout(timeoutId);

      // Here's the key: we check the status and throw for errors
      if (!response.ok) {
        throw new ApiError(
          `HTTP ${response.status}: ${response.statusText}`,
          response.status,
          response
        );
      }

      // Parse JSON safely
      const data = await this.parseResponse<T>(response);

      return {
        data,
        status: response.status,
        headers: response.headers,
      };

    } catch (error) {
      if (error.name === 'AbortError') {
        throw new ApiError('Request timeout', 408);
      }
      throw error;
    }
  }

  private buildUrl(endpoint: string): string {
    // Handle both absolute and relative URLs
    if (endpoint.startsWith('http')) {
      return endpoint;
    }
    return `${this.config.baseUrl}${endpoint.startsWith('/') ? endpoint : `/${endpoint}`}`;
  }

  private buildRequestOptions(options: RequestInit): RequestInit {
    return {
      ...options,
      headers: {
        ...this.config.defaultHeaders,
        ...options.headers,
      },
    };
  }

  private async parseResponse<T>(response: Response): Promise<T> {
    const contentType = response.headers.get('content-type');

    if (contentType?.includes('application/json')) {
      try {
        return await response.json();
      } catch (error) {
        throw new ApiError('Invalid JSON response', response.status, response);
      }
    }

    // Handle text responses
    return (await response.text()) as unknown as T;
  }
}

The crucial insight here is that we're transforming fetch's behavior to be more intuitive. By checking response.ok and throwing an error for HTTP errors, we make error handling predictable and consistent throughout our application.

Adding HTTP Method Convenience Methods

Now let's add the methods that developers will actually use:

// lib/api.ts (continued)
class ApiClient {
  // ... previous code

  async get<T>(endpoint: string, options?: RequestInit): Promise<ApiResponse<T>> {
    return this.makeRequest<T>(endpoint, { ...options, method: 'GET' });
  }

  async post<T>(
    endpoint: string, 
    data?: any, 
    options?: RequestInit
  ): Promise<ApiResponse<T>> {
    return this.makeRequest<T>(endpoint, {
      ...options,
      method: 'POST',
      body: data ? JSON.stringify(data) : undefined,
    });
  }

  async put<T>(
    endpoint: string, 
    data?: any, 
    options?: RequestInit
  ): Promise<ApiResponse<T>> {
    return this.makeRequest<T>(endpoint, {
      ...options,
      method: 'PUT',
      body: data ? JSON.stringify(data) : undefined,
    });
  }

  async delete<T>(endpoint: string, options?: RequestInit): Promise<ApiResponse<T>> {
    return this.makeRequest<T>(endpoint, { ...options, method: 'DELETE' });
  }

  async patch<T>(
    endpoint: string, 
    data?: any, 
    options?: RequestInit
  ): Promise<ApiResponse<T>> {
    return this.makeRequest<T>(endpoint, {
      ...options,
      method: 'PATCH',
      body: data ? JSON.stringify(data) : undefined,
    });
  }
}

Notice how we're automatically JSON.stringify-ing the data for POST, PUT, and PATCH requests. This eliminates another common source of bugs—forgetting to stringify your request body.

Authentication: The Token Management Challenge

Authentication is where things get interesting in Next.js. Unlike traditional SPAs, we have to consider both server-side and client-side contexts. Let's add authentication support:

// lib/api.ts (continued)
interface AuthConfig {
  tokenProvider?: () => Promise<string | null> | string | null;
  tokenHeader?: string;
  tokenPrefix?: string;
}

class ApiClient {
  private authConfig: AuthConfig;

  constructor(config: ApiConfig = {}, authConfig: AuthConfig = {}) {
    // ... previous constructor code
    this.authConfig = {
      tokenHeader: 'Authorization',
      tokenPrefix: 'Bearer',
      ...authConfig,
    };
  }

  private async buildRequestOptions(options: RequestInit): Promise<RequestInit> {
    const headers = { ...this.config.defaultHeaders };

    // Add authentication token if available
    if (this.authConfig.tokenProvider) {
      const token = await this.authConfig.tokenProvider();
      if (token) {
        headers[this.authConfig.tokenHeader!] = 
          `${this.authConfig.tokenPrefix} ${token}`;
      }
    }

    return {
      ...options,
      headers: {
        ...headers,
        ...options.headers,
      },
    };
  }

  // Update makeRequest to use async buildRequestOptions
  private async makeRequest<T>(
    endpoint: string,
    options: RequestInit = {}
  ): Promise<ApiResponse<T>> {
    const url = this.buildUrl(endpoint);
    const requestOptions = await this.buildRequestOptions(options);

    // ... rest of the method stays the same
  }
}

The token provider pattern is crucial here. Instead of directly storing tokens, we provide a function that can retrieve them. This allows us to:

Fetch fresh tokens from different sources (localStorage, cookies, memory)
Handle token refresh logic transparently
Work in both server and client contexts with different storage mechanisms

Creating Context-Aware API Instances

Now comes the Next.js-specific magic. We need different configurations for different execution contexts:

// lib/api.ts (continued)

// Client-side token provider (browser only)
const getClientToken = (): string | null => {
  if (typeof window === 'undefined') return null;
  return localStorage.getItem('auth_token');
};

// Server-side token provider (for SSR)
const getServerToken = (): string | null => {
  // In server components, you might get tokens from cookies
  // This is a simplified example - in practice, you'd use Next.js headers()
  return null;
};

// Create different instances for different contexts
export const clientApi = new ApiClient(
  {
    baseUrl: process.env.NEXT_PUBLIC_API_URL || '/api',
  },
  {
    tokenProvider: getClientToken,
  }
);

export const serverApi = new ApiClient(
  {
    baseUrl: process.env.API_URL || process.env.NEXT_PUBLIC_API_URL || 'http://localhost:3000/api',
  },
  {
    tokenProvider: getServerToken,
  }
);

// For convenience, export a context-aware API
export const api = typeof window === 'undefined' ? serverApi : clientApi;

This is a game-changer. By creating context-aware instances, we can use the same API interface everywhere while having different behavior on server vs. client. The server instance might use absolute URLs and server-side authentication, while the client instance uses relative URLs and browser storage.

TypeScript: Making It Type-Safe

Let's add proper TypeScript support to make our wrapper even more robust:

// lib/api.ts - Adding TypeScript interfaces

interface User {
  id: string;
  name: string;
  email: string;
}

interface ApiEndpoints {
  // Define your API shape
  '/users': {
    GET: { data: User[] };
    POST: { body: Omit<User, 'id'>; data: User };
  };
  '/users/:id': {
    GET: { data: User };
    PUT: { body: Partial<User>; data: User };
    DELETE: { data: { success: boolean } };
  };
}

// Type-safe wrapper methods
class TypedApiClient extends ApiClient {
  async getTyped<T extends keyof ApiEndpoints, M extends keyof ApiEndpoints[T]>(
    endpoint: T,
    method: M extends 'GET' ? 'GET' : never
  ): Promise<ApiEndpoints[T][M] extends { data: infer D } ? D : never> {
    const response = await this.get(endpoint as string);
    return response.data;
  }

  // Similar methods for POST, PUT, DELETE...
}

While this adds complexity, it provides incredible developer experience. Your IDE will autocomplete endpoints, catch typos, and ensure you're passing the right payload shapes.

Usage in Next.js Components

Now let's see how our wrapper shines in real Next.js scenarios:

Server Component Usage

// app/users/page.tsx - Server Component
import { serverApi } from '@/lib/api';

interface User {
  id: string;
  name: string;
  email: string;
}

export default async function UsersPage() {
  try {
    const { data: users } = await serverApi.get<User[]>('/users');

    return (
      <div>
        <h1>Users</h1>
        {users.map(user => (
          <div key={user.id}>{user.name}</div>
        ))}
      </div>
    );
  } catch (error) {
    if (error instanceof ApiError) {
      return <div>Error: {error.message}</div>;
    }
    return <div>Something went wrong</div>;
  }
}

Client Component with React Hook

// components/UserProfile.tsx - Client Component
'use client';

import { useState, useEffect } from 'react';
import { clientApi, ApiError } from '@/lib/api';

interface User {
  id: string;
  name: string;
  email: string;
}

interface UserProfileProps {
  userId: string;
}

export function UserProfile({ userId }: UserProfileProps) {
  const [user, setUser] = useState<User | null>(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    async function fetchUser() {
      try {
        setLoading(true);
        const { data } = await clientApi.get<User>(`/users/${userId}`);
        setUser(data);
      } catch (err) {
        if (err instanceof ApiError) {
          setError(err.message);
        } else {
          setError('An unexpected error occurred');
        }
      } finally {
        setLoading(false);
      }
    }

    fetchUser();
  }, [userId]);

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error}</div>;
  if (!user) return <div>User not found</div>;

  return (
    <div>
      <h2>{user.name}</h2>
      <p>{user.email}</p>
    </div>
  );
}

Route Handler Usage

// app/api/users/route.ts - API Route Handler
import { NextRequest } from 'next/server';
import { serverApi } from '@/lib/api';

export async function GET(request: NextRequest) {
  try {
    // Forward request to external API
    const { data } = await serverApi.get('/external-api/users');
    return Response.json(data);
  } catch (error) {
    if (error instanceof ApiError) {
      return Response.json(
        { error: error.message }, 
        { status: error.status }
      );
    }
    return Response.json(
      { error: 'Internal server error' }, 
      { status: 500 }
    );
  }
}

Advanced Features: Caching and Request Deduplication

For production applications, you might want to add caching and request deduplication:

// lib/api.ts - Advanced features
class ApiClient {
  private cache = new Map<string, { data: any; timestamp: number }>();
  private pendingRequests = new Map<string, Promise<any>>();

  async get<T>(
    endpoint: string, 
    options?: RequestInit & { cache?: boolean; cacheTTL?: number }
  ): Promise<ApiResponse<T>> {
    const cacheKey = `GET:${endpoint}`;
    const now = Date.now();

    // Check cache first
    if (options?.cache) {
      const cached = this.cache.get(cacheKey);
      const ttl = options.cacheTTL || 60000; // 1 minute default

      if (cached && (now - cached.timestamp) < ttl) {
        return { data: cached.data, status: 200, headers: new Headers() };
      }
    }

    // Deduplicate concurrent requests
    if (this.pendingRequests.has(cacheKey)) {
      return this.pendingRequests.get(cacheKey)!;
    }

    const requestPromise = this.makeRequest<T>(endpoint, { ...options, method: 'GET' });
    this.pendingRequests.set(cacheKey, requestPromise);

    try {
      const response = await requestPromise;

      // Cache successful responses
      if (options?.cache && response.status === 200) {
        this.cache.set(cacheKey, { data: response.data, timestamp: now });
      }

      return response;
    } finally {
      this.pendingRequests.delete(cacheKey);
    }
  }
}

Error Handling Strategies

One of the biggest advantages of our wrapper is centralized error handling. Here's how to leverage it:

// lib/error-handler.ts
import { ApiError } from './api';

export function handleApiError(error: unknown): string {
  if (error instanceof ApiError) {
    switch (error.status) {
      case 401:
        // Redirect to login or refresh token
        return 'Please log in to continue';
      case 403:
        return 'You don\'t have permission to perform this action';
      case 404:
        return 'The requested resource was not found';
      case 500:
        return 'Server error. Please try again later';
      default:
        return error.message;
    }
  }

  return 'An unexpected error occurred';
}

// Usage in components
import { handleApiError } from '@/lib/error-handler';

try {
  await api.get('/protected-resource');
} catch (error) {
  const errorMessage = handleApiError(error);
  toast.error(errorMessage);
}

File Structure and Organization

Here's how I recommend organizing your API layer:

lib/
├── api/
│   ├── index.ts          # Main API client and exports
│   ├── types.ts          # TypeScript interfaces
│   ├── endpoints.ts      # Endpoint definitions
│   └── error-handler.ts  # Error handling utilities
├── hooks/
│   ├── useApi.ts         # Custom React hooks
│   └── useAuth.ts        # Authentication hooks
└── utils/
    └── api-helpers.ts    # Utility functions

This structure keeps your API layer organized and makes it easy for team members to find what they need.

Best Practices and Common Pitfalls

Do's:

Always handle errors explicitly - don't let them bubble up uncaught
Use TypeScript interfaces for request/response shapes
Create separate instances for different environments or services
Implement proper loading states in your components
Cache responses when appropriate to reduce network requests

Don'ts:

Don't store sensitive tokens in localStorage for production apps (use httpOnly cookies)
Don't ignore HTTP status codes - handle different statuses appropriately
Don't make API calls in render methods - use useEffect or server components
Don't forget about request timeouts - they prevent hanging requests
Don't hardcode URLs - use environment variables

Common Pitfalls:

The "works on my machine" trap: Always test in different Next.js contexts (server, client, API routes)
Token refresh hell: Implement proper token refresh logic before you need it
Error boundary neglect: Wrap your API-consuming components in error boundaries

The Bigger Picture: Why This Matters

Building a robust fetch wrapper isn't just about cleaner code—it's about creating a reliable foundation for your application. When your API layer is solid, you can:

Focus on features instead of debugging network issues
Scale confidently knowing your request handling is consistent
Onboard new developers faster with a clear, documented API interface
Maintain better code quality through centralized error handling and typing

Think of it as investing in your future self. The hour you spend building this wrapper will save you dozens of hours debugging production issues, writing repetitive error handling code, and hunting down network-related bugs.

Conclusion: Your API Layer as a Competitive Advantage

We've journeyed from the humble beginnings of raw fetch calls to a sophisticated, production-ready API client that handles authentication, errors, TypeScript safety, and Next.js's unique execution contexts. But here's the thing—this isn't just about writing better code.

In today's development landscape, the quality of your API layer directly impacts your team's velocity and your application's reliability. A well-crafted fetch wrapper becomes the invisible infrastructure that lets your team move fast and ship confidently.

The patterns we've explored—context awareness, proper error handling, TypeScript integration, and thoughtful architecture—aren't just "nice to have" features. They're the difference between a fragile application that breaks in production and a robust system that handles the real world gracefully.

Symmetric, Asymmetric, Hybrid Encryption Explained Simply. How TLS (HTTPS) Works

Nikita Dmitriev — Sun, 11 May 2025 22:18:16 +0000

1. Introduction
2. Core Encryption Types
- 2.1. Symmetric Encryption
- 2.2. Asymmetric Encryption
3. Hybrid Encryption Scheme
4. TLS / SSL
5. Classification of encryption algorithms
6. Conclusion

1. Introduction

Encryption is the process of converting readable data (plaintext) into an unreadable format (ciphertext) so that only authorized recipients can decipher it

There are two primary types of encryption:

Symmetric: The same key is used for both encryption and decryption
Asymmetric: Two different keys are used—one to encrypt, another to decrypt

Hybrid encryption isn’t a standalone type but rather a data exchange scheme combining both methods

2. Core Encryption Types

2.1. Symmetric Encryption

How Symmetric Encryption Works

The sender and recipient share the same secret key
If a hacker obtains this key, they can decrypt all messages

Simple example: Caesar Cipher

Concept: Each letter in a message is shifted by a fixed number of positions in the alphabet. The key is the shift value

def caesar_encrypt(text, shift):  
    result = ""  
    for char in text:  
        if char.isalpha():  # Check if the character is a letter  
            # Determine offset for uppercase (A-Z) or lowercase (a-z) letters  
            offset = 65 if char.isupper() else 97  
            # Apply Caesar cipher with circular alphabet wrap (%26)  
            result += chr((ord(char) - offset + shift) % 26 + offset)  
        else:  
            result += char  # Non-alphabetic characters remain unchanged  
    return result  

# Example: Shift by 3 positions  
print(caesar_encrypt("Hello, World!", 3))  # Output: "Khoor, Zruog!"

Note: The Caesar cipher is a historical example and is not secure for modern use

Modern algorithms:

These are far more secure than the Caesar cipher but still rely on a single key

2.2. Asymmetric Encryption

How Asymmetric Encryption Works

The recipient generates a key pair:
- Public key: Shared freely
- Private key: Kept secret
The sender encrypts data with the recipient’s public key
Only the recipient’s private key can decrypt it

Example scenario

Bob generates a key pair (public + private)
He distributes his public key (e.g., to Alice)
Alice writes a message, encrypts it with Bob’s public key, and sends it
Only Bob can decrypt it using his private key

How is this possible?

We ourselves encrypt a message with a public key and we ourselves can't decrypt it with the same key - that's right. It's the math that makes this system work.

The keys are generated in a bundle:

Public key - only encrypts

Private key - only decrypts.

Once Alice has encrypted her message, even she can't read it unless she has the private key. To further understand how this works, I recommend studying the RSA encryption algorithm - it's the one that shows how such a process is implemented in practice

Modern algorithms:

Important: Asymmetric algorithms are inconvenient to encrypt large amounts of data because they are slow. Therefore, in practice they are used in combination with symmetric encryption, which is hybrid encryption

3. Hybrid Encryption Scheme

Why use it?

Asymmetric: Secure but slow.
Symmetric: Fast but requires secure key exchange.
Solution: Combine both.

How Hybrid Encryption Works

Symmetric Keys Exchange Scenario

The recipient (Bob) generates a key pair - public and private - using the RSA algorithm
The sender (Alice) generates a symmetric key for encryption (e.g., using the AES algorithm)
Alice encrypts the symmetric key using Bob's public key
The encrypted symmetric key is given to Bob. No one but him can decrypt it without the private key
Bob receives the encrypted key and decrypts it using his private key
Now both Alice and Bob have a common symmetric key known only to them
They can then use this key to encrypt and decrypt messages. Asymmetric encryption is no longer required

Instant Data Exchange Scenario

The recipient (Bob) generates a key pair - public and private - using the RSA algorithm
the sender (Alice) generates a symmetric key for encryption (e.g., using the AES algorithm)
Alice encrypts the symmetric key using Bob's public key
She then encrypts her message using the symmetric key created
Alice sends Bob two items: the encrypted symmetric key and the encrypted message
Bob receives the encrypted key and decrypts it using his private key
After obtaining the symmetric key, Bob decrypts the message. Thus, he simultaneously obtains both the key and the contents of the message. They can then use this key to encrypt and decrypt the messages. Asymmetric encryption is no longer required

4. TLS / SSL

TLS (Transport Layer Security) - A protocol to protect data transmitted over the Internet. SSL (Secure Sockets Layer) is an older version. Before these protocols, the http protocol was used, now it is https, which ensures that your data is encrypted when requests are made to the server

TLS Handshake

A Client (e.g., browser) connects to the server (https://example.com) and requests a secure connection
The Server sends its public key and a SSL certificate signed by a certificate authority
The client verifies the authenticity of the certificate
The client creates a symmetric key, encrypts it with the server's public key, and sends it to the server
The server decrypts the symmetric key with its private key
Now both parties have a common symmetric key, and all further data is encrypted with that key

This is hybrid encryption in action: first asymmetric encryption is used to transmit the symmetric key, and then symmetric encryption is used for speed.

SSL Certificates

Issued by special organizations - Certification Authorities (CAs)
Signed by the CA's digital signature
Contains domain, organization, expiration date and public key

5. Classification of encryption algorithms

By the number of keys:
1. Symmetric - one key is used for encryption and decryption. Examples: AES, 3DES, IDEA.
2. Asymmetric - two keys are used: public and private. Examples: RSA, ECC.
Algorithm structure: 1.
1. Block Ciphers - process data in fixed-size blocks. Examples: AES, DES.
2. Stream Ciphers - encrypt data by bytes or bits. Examples: RC4, ChaCha20.

6. Conclusion

That's it

2-Factor Authentication OTP: TOTP & HOTP Algorithms

Nikita Dmitriev — Tue, 22 Apr 2025 23:05:52 +0000

Table of Contents
Introduction
Under The Hood
TOTP or HOTP
Little Practice

Introduction

First of all, it is important to understand the difference between authorization and authentication

Authentication - who are you? Enter your login and password please
Authorization - what are you allowed to do? Oh, you're admin, so you can view this page but others don't

Globally, authentication types can be categorized into:

What you know - password, PIN
What you have - smartphone, token, smart card
What you are - fingerprint, face, voice (biometrics)
(Sometimes a 4th type is distinguished: “where you are” - geolocation, IP address)

In this article, we’ll dive deep into One-Time Password (OTP) authentication, a method that falls under the "something you have" type.

Let’s start by looking at how OTP works from the user’s perspective - chances are, you’ve already encountered it in practice.

To begin, you download an authenticator app that generates codes locally (without internet) on your device. A common choice is Google Authenticator, though there are many alternatives - you can even build your own. Functionally, they all work the same way.

The authenticator app doesn’t need internet access. It generates one-time passwords for logging into websites and apps. Here’s how the setup process typically works:

When enabling 2FA on a website, it shows you a QR code that contains a secret key.
You scan this QR code with your authenticator app (or enter the secret manually).
After linking, the app displays the service name (which you can customize) and starts generating one-time passcodes.
These codes change:
- Either at regular time intervals (typically every 30 seconds),
- Or immediately after being used.

When you log into the service, it asks you for the current code from your app - this acts as another layer of verification. But how exactly does it all work behind the scenes?

Under The Hood

The service (say, Facebook) generates a secret key. You add this key to your authenticator app, usually by scanning a QR code.

From that point, both the server and the app can independently generate the same one-time passwords using that shared secret.

There are two main types of OTP generation:

HOTP (counter-based): uses a number that increases each time a code is generated.
TOTP (time-based): uses the current time (typically in 30-second intervals) to create a new code.

Today, TOTP is the standard, since it doesn’t require syncing counters - just the secret key and system time. When you enter a code, the service generates its own and compares it. If they match, you’re authenticated.

TOTP or HOTP

Now that we’ve looked at how OTP works, let’s explore the algorithms behind it

HOTP (HMAC-based One-Time Password)

HOTP is an algorithm for generating one-time passwords based on HMAC and counter. It is defined in the official specification RFC 4226 and is the basis for the later TOTP (temporary OTP)

Input data:

Secret key
Counter - 8-byte value incremented at each generation

Example:

SECRET = "JBSWY3DPEE======"
COUNTER = 5

1. Convert counter to bytes:
   COUNTER_BYTES = [00 00 00 00 00 00 00 05]

3. Calculate HMAC-SHA1:
   HMAC_RESULT = HMAC_SHA1(SECRET, COUNTER_BYTES) 
   -> [1a f9 15 68 c8 7c 7a 61 37 99 7f 25 b0 dc 76 b3 c0 80 ee d2]

4. Take the last byte of HMAC:
   LAST_BYTE = 0xD2

5. Calculate offset:
   OFFSET = 0xD2 & 0x0F = 0x03 (3 in decimal)

6. Extract 4 bytes starting with offset (3):
   HMAC_SLICE = [15 68 c8 7c]

7. Convert to 31-bit number:
   BINARY = 0x1568c87c & 0x7FFFFFFFFF = 0x1568C87C (359,186,844 in decimal)

8. Take the last 6 digits:
   TOTP = 186844

Output data (6-digit code):

Code: 186844

TOTP (Time-based One-Time Password)

TOTP is a time-based one-time password generation algorithm that extends HOTP. It uses the current time instead of a counter, which makes it more user-friendly. The TOTP specification is described in RFC 6238.

The main differences from HOTP are:

A timestamp (usually Unix time in seconds) is used instead of a counter
Password changes at a fixed interval (most commonly 30 seconds)
Does not require synchronization of the counter between client and server (synchronized time is sufficient).

Input data

Secret key
Current time in unix format
Time interval in seconds

Example:

SECRET = "JBSWY3DPEE======"
CURRENT_TIME = 1712589000 (UNIX timestamp 2024-04-08 12:10:00 UTC)
TIME_STEP = 30 (seconds)

1. Convert time to a time step
   T = floor(CURRENT_TIME / TIME_STEP)

2. Convert T to an 8-byte array
   T_BYTES = [00 00 00 00 03 68 F3 DC]

3. Compute HMAC-SHA1 with secret and T_BYTES
   HMAC_RESULT = HMAC_SHA1(SECRET, T_BYTES)
   -> [1f 86 98 98 69 0e 02 ca 16 61 85 50 ef 7f 19 da 8e 94 5b 55]

4. Determine offset (last 4 bits of the last byte):
   LAST_BYTE = 0x55
   OFFSET = 0x55 & 0x0F = 0x05 (5 in decimal)

5. Extract the 4 bytes starting at offset
   HMAC_RESULT[5:9] = [0e 02 ca 16]

6. Convert to 31-bit number (ignore high bit)
   0x0e02ca16 & 0x7FFFFFFFFF
   = 00001110 00000010 11001010 00010110 (binary)
   & 01111111 11111111 11111111 11111111 11111111 11111111
   = 00001110 00000010 11001010 00010110
   = 0x0e02ca16 (234,999,318 in decimal)

7. Take the last 6 digits
   TOTP = 999,318 % 1,000,000 = 999318

Output data (6-digit code):

Code: 999318

Little Practice

With a little help from AI I wrote a simple Command-Line Interface (CLI) with adding secret keys and generating OTP. Google Authenticator operates in a similar manner

#!/usr/bin/env node

// Import required modules
const readline = require("readline"); // For reading user input
const { authenticator } = require("otplib"); // For OTP generation

// Object to store secret keys with their labels
const secrets = {};

// Create interface for reading from stdin and writing to stdout
const rl = readline.createInterface({
   input: process.stdin,
   output: process.stdout,
});

// Main menu function that displays options and handles user choice
function menu() {
   console.log("\n=== Authenticator Menu ===");
   console.log("1. Add new secret");
   console.log("2. Show current tokens");
   console.log("3. List saved entries");
   console.log("4. Exit\n");

   // Prompt user for their choice
   rl.question("Choose an option: ", (answer) => {
      switch (answer.trim()) {
         case "1":
            addSecret(); // Add new secret key
            break;
         case "2":
            showTokens(); // Generate and display current OTP tokens
            break;
         case "3":
            listSecrets(); // List all saved secret labels
            break;
         case "4":
            rl.close(); // Exit the program
            break;
         default:
            console.log("Invalid option. Try again.");
            menu(); // Show menu again on invalid input
      }
   });
}

// Function to add a new secret key with a label
function addSecret() {
   rl.question("Enter label (e.g. email/service name): ", (label) => {
      rl.question("Enter secret (base32 format): ", (secret) => {
         // Store the secret with its label
         secrets[label] = secret.trim();
         console.log(`✅ Secret for "${label}" saved.`);
         menu(); // Return to main menu
      });
   });
}

// Function to generate and display current OTP tokens for all stored secrets
function showTokens() {
   console.log("\n--- Current OTP Codes ---");
   // Iterate through all stored secrets and generate tokens
   for (const [label, secret] of Object.entries(secrets)) {
      const token = authenticator.generate(secret);
      console.log(`${label}: ${token}`);
   }
   console.log("--------------------------\n");
   menu(); // Return to main menu
}

// Function to list all stored secret labels
function listSecrets() {
   console.log("\n--- Saved Labels ---");
   // Display all labels with numbering
   Object.keys(secrets).forEach((label, i) => {
      console.log(`${i + 1}. ${label}`);
   });
   console.log("---------------------\n");
   menu(); // Return to main menu
}

// Clear console and display welcome message
console.clear();
console.log("Welcome to CLI Authenticator!");
// Start with the main menu
menu();

You can clone it from GitHub as well - https://github.com/dmitit/authit

Outroduction

This method of authentication is quite simple for both developers and users. However, if an attacker gets your secret key, it will be no problem for him to log into your account. So storing your secret key offline on your devices saves the situation.

I never memorize passwords. I memorize the algorithms that generate them

How 'npm create vue@latest' works

Nikita Dmitriev — Tue, 28 May 2024 15:04:16 +0000

Introduction

I don't think I'm the only interested in the functionality of this command as presented in the Vue quickstart documentation

npm create vue@latest

Once we execute this command, we encounter some 'magic' where we select preferences for our future Vue app. But how exactly does it work?

npm create

This command works very simply. Everyone is used to working with the npm init command, so let's look at these logs

Both of them are the same. npm create just an alias for npm init. Let's just replace create with init and we'll get

@latest is simply a pointer to the latest version of an npm package. You can try it with any package you desire

Since we now know this, we can read the documentation about npm init . Run npm help init in your terminal

As we see here, we can also use npx instead of npm init but with create- prefix:

npm init <package-spec> (same as `npx <package-spec>`)
npm init <@scope> (same as `npx <@scope>/create`)

Let's try npx for our case. And then we see

Let's return to npm init documentation

The npx and npm exec commands are very similar, but there's one difference, which you can read about here. We don't need to understand this to use create-vue

Now I'll call all the known commands and demonstrate that they all produce the same result. When we use npm create vue@latest, it's essentially the same as npm init create-vue@latest - just an alias

Now, I hope you understand the npm create functionality. Then let's get to the next point

bin

Here you can see our test project

Let's install prettier for example

npm i -D prettier

Now if you open the node_modules directory you'll notice a .bin directory and a symbolic link called prettier. What is it for? You can execute your installed executable packages from .bin repository using npm scripts and commands like npx

For example let's run npx prettier . --check

It works!

Let's open node_modules/.bin/prettier and look at the code

But what is a symbolic link exactly? It comes from programming and I often liken symbolic links to basic redirects but with greater stability. However, not every package needs a place in .bin. Packages like nodemon, webpack, gulp, eslint and create-vue are found in .bin because they need to be executed. On the other hand, packages like animate.css, swiper and express operate at the application layer, so you won't find them in .bin after installation. How does npm determine whether a package is executable or not? It's simple: by using the bin property in your package.json to specify the executable path. If your package is executable, you can set it accordingly. Let's take a look at prettier's package.json file

Here you see

"bin": "./bin/prettier.cjs"

Let's follow the path ./bin/prettier.cjs in the prettier package. Do not confuse this path with node_modules/.bin

We've seen this somewhere before, haven't we? Open .bin/prettier in the root of node_modules and you'll see the same code.

Prettier has

"bin": "./bin/prettier.cjs"

So npm creates bin repository and insert a symbolic link there that refers to the Prettier package's file inside bin/prettier.cjs. And now you understand how symbolic links work in practice :)

If you remove the .bin directory from node_modules and try to run npx prettier . It'll throw an error sh: 1: prettier: not found, regardless of whether you have the prettier package installed

create-vue

Let's remove Prettier with npm rm prettier and install npm i -D create-vue now. Inside the .bin directory, we can see the symbolic link for create-vue

Let's move to package.json in node_modules/create-vue

We see create-vue bin key that runs outfile.cjs.

"bin": {
   "create-vue": "outfile.cjs"
},

If we open it, we'll notice the same code as in node_modules/.bin/create-vue (symbolic link)

Does that mean we can simply execute create-vue from the terminal? Exactly. Just like we can execute outfile.cjs. Let's try it

While using npm init or its alias npm create provided with the package, npm executes the binary file (bin) with the name of this package during initialization

Conclusion

I'd like to point out another potential source of confusion. Vue docs provide a link only to the create-vue GitHub repository. However, if you visit that repository, you won't find an outfile.js or any direct similarity with the create-vue package we just explored. This is because GitHub primarily stores open-source code for contribution and development purposes. In contrast, npm stores the actual bundled package code that you install. So, it's important not to confuse the GitHub repository with the package as installed via npm

Now I hope I've helped you, and you can now understand and explore similar packages such as create-react-app or create svelte@latest using this guide

Complete and Quick Guide to Lua 🌑

Nikita Dmitriev — Fri, 05 Apr 2024 14:25:16 +0000

From the author

This article contains only the most basic information about Lua. What prompted me to create it was the lack of such a short guide on this language on the Internet. I only found a shortened version in the documentation, but it also seemed quite large to me. So, if that’s what you’re looking for, let’s start

Introduction

Lua is a powerful, lightweight scripting language that is used in a wide range of applications, from web servers to video games. It is known for its simplicity and flexibility, making it a popular choice for programmers of all skill levels.

The peculiarity of Lua is that while it supports object-oriented programming (OOP) principles, it does not have built-in classes like some other languages. Instead, Lua uses tables to simulate classes. Tables are essentially associative arrays that can contain keys and values, which can be any data type, including functions. Furthermore, arrays in Lua start with an index of 1, not 0 as in many other programming languages.

Variables

In Lua, you can declare a variable using the local keyword, followed by the variable name. If you want the variable to be global, you can omit the local keyword.

local x = 10
y = 20

Data Types

Lua has eight basic types: nil, boolean, number, string, userdata, function, thread, and table.

Operators

Lua supports a variety of operators, including arithmetic, relational, logical, and bitwise operators.

Arithmetic operators include: + (addition), - (subtraction), * (multiplication), / (division), ^ (exponentiation), and % (modulus).

Relational operators include: == (equal to), ~= (not equal to), < (less than), > (greater than), <= (less than or equal to), and >= (greater than or equal to).

Logical operators include: and (logical AND), or (logical OR), and not (logical NOT).

Bitwise operators, available from Lua 5.2 onwards, include: & (AND), | (OR), ~ (XOR), << (left shift), >> (right shift), and ~ (NOT).

It's important to note that Lua uses "short-circuit" evaluation for its logical operators, meaning it will stop evaluating as soon as the outcome is determined.

local a = true
local b = false

if a or b then
  print("At least one of the conditions is true.")
end

In this case, Lua will stop evaluating as soon as it encounters the a variable, because it's true, and that's enough to determine the outcome of the or operation. It won't even check the value of b.

Tables

Tables in Lua are the only data structure, and they can be used to represent arrays, sets, records, graphs, trees, etc.

local numbers = {1, 2, 3}
local titles = {['luna'] = 'devops engineer', ['rudy'] = 'backend developer'}
local wtf = {1, 2, ['pithon'] = 'ml engineer'}

a = {}     -- create a table and store its reference in `a'
k = "x"
a[k] = 10        -- new entry, with key="x" and value=10
a[20] = "great"  -- new entry, with key=20 and value="great"
print(a["x"])    --> 10
k = 20
print(a[k])      --> "great"
a["x"] = a["x"] + 1     -- increments entry "x"
print(a["x"])    --> 11

Control Structures

Lua supports the usual control structures: if statements, while loops, and for loops.

if x > y then
  print("x is greater than y")
else
  print("x is not greater than y")
end

Example of a for loop:

for i = 1, 10 do
  print(i)
end

Iterating Over Tables

Iterating over tables in Lua is achieved through the use of loop constructs. A common method is using the pairs function with a for loop. This function returns a key-value pair for each item in the table, allowing you to access both the index and value in each iteration.

local tbl = {apple = "fruit", carrot = "vegetable", lion = "animal"}

for key, value in pairs(tbl) do
  print(key, value)
end

In this example, the for loop will iterate over each key-value pair in the table. The pairs function is particularly useful when working with tables where the keys are not just numerical values or when the keys are not in sequence.

It's important to note that the pairs function does not guarantee any particular order when iterating over the table.

Another function, ipairs, is used specifically for tables with integer keys that are in sequence. It stops iterating once it encounters a nil value.

Arrays are just a special kind of table, and you can iterate over them using a for loop.

You can get length of an array by # as simple as of a string.

local array = {1, 2, 3, 4, 5}

for i = 1, #array do
  print(array[i])
end

In this example, #array gives the length of the array, and array[i] accesses the i-th element in the array.

There’s no arr[0] in lua. Every array starts with 1 index

Functions

You can declare a function in Lua using the function keyword, followed by the function name and parameters.

function add(x, y)
  return x + y
end

Object-Oriented Programming in Lua

Lua supports object-oriented programming (OOP) principles, but it does not have built-in classes like some other languages. Instead, Lua uses tables to simulate classes. Tables are essentially associative arrays that can contain keys and values, which can be any data type, including functions.

Here is a simple example of how to implement a class in Lua:

Person = {}
Person.__index = Person

function Person.new(name, age)
  local self = setmetatable({}, Person)
  self.name = name
  self.age = age
  return self
end

function Person:greet()
  print("Hello, my name is " .. self.name .. " and I am " .. self.age .. " years old.")
end

-- To create a new instance of the class and call a method:
local john = Person.new("John", 25)
john:greet()

In this example, Person is a table that serves as a class. The __index metamethod is set to the Person table itself, which allows instances of the class to access its methods.

The new function is a constructor that creates a new instance of the Person class. It uses setmetatable to associate the Person methods with the new instance.

The greet function is a method that all Person instances will have access to.

Lua also supports inheritance, which allows one class to inherit the properties and methods of another class. This can be done by setting the __index metamethod of the child class to the parent class. Here is an example:

-- Assuming the Person class has been defined...

Student = setmetatable({}, Person)
Student.__index = Student

function Student.new(name, age, grade)
  local self = Person.new(name, age)  -- Create a Person instance
  setmetatable(self, Student)  -- Change its metatable to Student
  self.grade = grade
  return self
end

function Student:study()
  print(self.name .. " is studying.")
end

-- To create a new instance of the Student class:
local jane = Student.new("Jane", 20, "A")
jane:study()  -- Outputs: "Jane is studying."

In this example, Student is a subclass of Person. The new function in Student calls the new function in Person to create a Person instance, then changes its metatable to Student, effectively turning it into a Student instance.

Threads

In Lua, a thread represents an independent execution line. Lua supports multithreading by using coroutines, which are a generalization of subroutines. Coroutines in Lua are a type of collaborative multitasking where the switch from one task to another is done explicitly by a coroutine. Lua's threads are not operating system threads, but they can be used to simulate multithreading.

Threads are a type of value in Lua and they are manipulated just like any other value. You can create a thread with the coroutine.create() function, which returns a value of type thread. This function takes a single argument: a Lua function that the thread will execute.

co = coroutine.create(function ()
  print("Hello, World!")
end)

coroutine.resume(co)  -- Outputs: "Hello, World!"

In this example, coroutine.create() creates a new coroutine with the specified function and coroutine.resume() starts or continues the execution of a coroutine.

A thread in Lua can be in one of three states: suspended, running, or dead. When you create a thread, it starts in the suspended state. Then, when you call coroutine.resume(), it goes to the running state. If the function finishes its execution or if an error occurs, the thread goes to the dead state. You can check the status of a thread with the coroutine.status() function.

Coroutines provide a lot of flexibility, as they can yield (pause) at any point in their execution and can be resumed later from where they left off. This is done using the coroutine.yield() and coroutine.resume() functions.

Note that coroutines are not a parallelism mechanism. Even though they can be used to simulate concurrency, only one coroutine runs at a time.

Conclusion

This is a very basic introduction to Lua. Lua is a powerful language that has a lot to offer, so don't hesitate to dive deeper and explore what you can do with it!

Guide to ESLint & Prettier with Nuxt 3

Nikita Dmitriev — Mon, 29 Jan 2024 15:51:26 +0000

Introduction

In this article, you will learn:

How to set up a Nuxt project with ESLint and Prettier
How to configure ESLint and Prettier together
How ESLint plugins and configs work
The difference between plugins and extends in ESLint
How Prettier plugins work
Other important details

Prerequisites

You should have basic knowledge of Prettier and ESLint. You'll also need VS Code, but if you don't have that, it's not a problem as long as you really know the basics about your particular IDE.

Environment Preparation

If you're using a separate IDE from VSCode, you can skip this part. ESLint and Prettier follow the same script in every IDE. If you are a VSCode user, let's get started.

First of all install these 2 extensions:

Prettier - Code formatter
ESLint

Now open VSCode settings using CTRL + , hotkey in Windows or using the panel below:

Open settings.json. You can find the button in the top right corner

Then add or change the following parameters:

{
  "prettier.configPath": ".prettierrc",
  "editor.formatOnPaste": false,
  "editor.formatOnType": false,
  "scss.lint.unknownAtRules": "ignore",
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "eslint.format.enable": true,
  "prettier.useEditorConfig": false
}

Useful Note. If you want to see what each of these settings does, then go back to the convenient UI window with settings and enter the keys (from settings.json) into the search one by one, for example:

Project Initialization

Now go to the terminal and select the folder you like to create the project

To initialize the nuxt project you must run the following command:

npx nuxi@latest init my-project

Useful Note. If you want to deploy the nuxt project exactly in the current folder, and not create a new one with the project, then run npx nuxi@latest init ./ (as in my case)

As you can see, the project is deployed directly in the selected folder. As for me, in some cases this is a way more convenient than nuxt creating a new folder for the project

Now let's install the common dependencies:

npm i -D prettier eslint

Useful Note. The -D flag is used to add a package to devDependencies. You can read more here

I think you already know how Prettier and ESLint work without each other, but if not, be sure to check it out before we go any further.

Integrate ESLint module to Nuxt

You can just follow this guide and skip this section, but if you want, let's walk through it together.

In your nuxt application install

npm add -D @nuxtjs/eslint-module

Useful Note. npm add is exactly the same command as npm i, but it just looks nicer from a naming point of view. That is, it’s like an alias

In essence, this action simply adds a plugin to the nuxt application (in addition to ESLint, you can add any other from here). This setting is purely for nuxt so that it knows which modules you are using, so now you need to edit nuxt.config.ts and add just one line to it

modules: ["@nuxtjs/eslint-module"]

Now your nuxt.config.ts should look something like this

// https://nuxt.com/docs/api/configuration/nuxt-config
export default defineNuxtConfig({
  devtools: { enabled: true },
  modules: ["@nuxtjs/eslint-module"],
})

Plugins and configs in ESLint

Remember one thing - plugins do not configure your ESLint in any way. You just sort of add a module to it, but don't connect it. This can be compared to regular projects. For example, you can add a large jquery folder to the project (I hope you haven’t had this experience), and connect only jquery.min.js to the project from the folder. And here the jquery folder is a plugin, and jquery.min.js is a config. That is, when you specify something in plugins in ESLint, you simply load some rules and you need to configure which ones work.

All plugin names begin with eslint-plugin-. Having any plugin installed, for example eslint-plugin-react, you can connect it with removed prefix, like here

plugins: [
  "react", // the same as "eslint-plugin-react"
]

But you can use a longer way:

plugins: [
  "eslint-plugin-react", // the same as "eslint-plugin-react"
]

I also would like to say about plugins starting with @. Let's introduce the child plugins @foo/eslint-plugin and @foo/eslint-plugin-bar. And you can connect these plugins in the following ways:

"plugins": [
      "@foo/eslint-plugin-bar", // the same as "@foo/eslint-plugin-bar"
      "@foo/bar",           // the same as "@foo/eslint-plugin-bar"
      "@foo/eslint-plugin",        // the same as "@foo/eslint-plugin"
      "@foo"        // the same as "@foo/eslint-plugin"
    ]

And here ESLint works quickly, but I wouldn’t say it’s good, because often confusion arises due to such moments. Therefore, carefully study the example above and make sure that everything is clear.

Well, I hope you have mastered the information above and now let's talk about extends. In extends we always specify the configuration of our plugins. You can specify the entire configuration yourself in a separate place and add just this one file to extends. But this practice is very inconvenient and generally makes no sense when there are already ready-made configurations. In general, with plugins you simply load a preset, and with configs you connect the necessary settings for this preset. Configs start with eslint-config- (similar to plugins), but configs can also be inside plugins, and to use them you must set the appropriate plugin: prefix. I understand that it has become more difficult now, so let’s immediately analyze everything we’ve covered using the example of our application.

In the beginning we just included ESLint in the nuxt project, but ESLint does not have any settings for nuxt at the moment and the most useful plugin for nuxt is eslint-plugin-nuxt. Let's install it:

npm i -D eslint-plugin-nuxt

Now let's create a .eslintrc.json file in the project root

Let's add this plugin to our .eslintrc.json

{
   "plugins": ["nuxt"] // the same as "eslint-plugin-nuxt"
}

Now let's add a new script to package.json:

"lint": "eslint .",

Now it looks like this

Let's try to run this script and we'll get the following error:

ESLint requires us to include a config, so let's do that, but first let's have a look at the open source of this plugin and find the recommended.js file

As you can see, here are the usual ESLint settings (as in any other config), and all because this is essentially a .eslintrc.json file, only encrypted in js format. and it extends base.js, let's look at that too

And here you can see the plugin connection

plugins: [
    'nuxt' // the same as "eslint-plugin-nuxt"
],

That is, this config connects the main plugin eslint-plugin-nuxt and configures it by specifying various parameters (for example, connecting rules). You can literally copy this config and paste it into your .eslintrc.json and everything will work for you. Here's a minimalistic example of config, which just control single rule from the plugin

{
    "plugins": [
        "nuxt"
    ],
    "rules": {
        "nuxt/rule-name": 2
    }
}

But again, it’s inconvenient to configure everything yourself and each plugin already has ready-made configs, like this recommended.js. So we can simply use them based on the plugin documentation. If you know OOP and programming, then you know the extend operation from there, and here it works similarly. Well, now let's write the config connection for the plugin

{
  "extends": [
    "plugin:eslint-plugin-nuxt/recommended"
  ]
}

Remember what I said about the plugin: prefix? This is where it is used, since the config is loaded directly from the plugin. In this case, we may not add the plugin connection to plugins "plugins": ["nuxt"]. As mentioned above, also we can omit eslint-plugin- and we get

{
  "extends": [
    "plugin:nuxt/recommended"
  ]
}

But this config is already deprecated, and we can connect another one that includes its own npm package. Let's install @nuxt/eslint-config and connect in .prettierrc.json

npm add -D @nuxt/eslint-config

And extend it in .eslintrc.json

{
   "extends": [
     "@nuxt" // The same as @nuxt/eslint-config
   ]
}

Now let's write the following code in app.vue:

<template>
  <div>
    <div class="hello"></div>
  </div>
</template>

And run the npm run lint command

As you can see ESLint works now! You can experiment with the name of the extended config

Also let's look at the repository of this config

Here we are using the basic eslint-config, but as you can see there are other options, such as eslint-config-legacy, which works for older versions, etc. But if you try to connect it by simply writing something like this, nothing will work

{
   "extends": [
     "@nuxtjs/eslint-config-legacy-typescript"
   ]
}

That's because this config only works for version 2 of nuxt, as you can verify through the code on github:

In general, keep in mind that each plugin has its own internal structure, and you need to delve into open source to connect everything correctly. As a result, you can notice that we installed only one plugin eslint-plugin-nuxt, and we can connect different configs to it (plugin:prettier/recommended, which comes in the box with the plugin and @nuxt/eslint-config, which is installed separately). So there are no restrictions here, you can customize any plugins individually and write your own configs. And if you, for example, connected a config and want to override some settings, then simply specify them in the root .eslintrc.json. But consider the order in which you extend your configs! The order of the configurations in the extends array matters. The configurations listed later will override conflicting rules from earlier configurations.

module.exports = {
  extends: [
    'eslint:recommended', // Base configuration
    'plugin:react/recommended', // Extending a specific plugin configuration
    'airbnb', // Extending a third-party configuration
    'prettier', // Extending a configuration for code formatting
  ],
  rules: {
    // Your additional or overridden rules go here
  },
};

Prettier & ESlint

There are 2 packages: eslint-plugin-prettier and eslint-config-prettier. They eliminate potential conflicts between ESLint and Prettier for your application and give ESLint the ability to follow the rules in Prettier. Always connect them together, otherwise conflicts will arise. They complement each other. Let's connect them

npm add -D eslint-plugin-prettier eslint-config-prettier

And now we add the corresponding configs to extends

{
  "extends": ["@nuxt", "plugin:prettier/recommended", "prettier"] // The same as "@nuxt/eslint-config", "plugin:eslint-plugin-prettier/recommended", "eslint-config-prettier"
}

In general, we are finished, but we still need to add the following parameters to .eslintrc.json for it to work correctly

{
  "extends": ["@nuxt", "plugin:prettier/recommended", "prettier"], // The same as "@nuxt/eslint-config", "plugin:eslint-plugin-prettier/recommended", "eslint-config-prettier"
  "env": {
    "browser": true,
    "node": true,
 },
}

Configure .prettierc

Now let's create just an empty .prettierrc file

Open app.vue

In VSCode go to command palette:

Restart ESLint server. This procedure is needed simply to update ESLint in VS Code

And now if you remove the space, ESLint will start displaying an error related to prettier

Now go back to the command palette and select format document

The document is formatted and there are no errors. Now let's try to add a parameter to the prettier config

Let's go back to app.vue and restart ESLint server

And we get ESLint errors

Also if you write npm run lint in the console, then errors will be displayed there too

Now let's format the document again:

Plugins in prettier

Only ESLint can be configured to adapt to prettier. The opposite is not possible. Keep in mind that prettier plugins are not related to ESLint in any way, and only ESLint can change depending on prettier. Plugins in prettier also start with prettier-plugin-, but the prefix cannot be omitted! Let's install the plugin - npm add -D prettier-plugin-tailwindcss. And connect it to prettierrc

For this plugin to work we need to install tailwindcss in the project. Do it according to the guide. I already have another application where all this is connected, so don’t be alarmed that the name of the project has changed. Let's try to write the classes in the following order and run them through the linter

As you can see, an error has arisen that we need to change the order of the classes and let's take advantage of the linter's hint and use the --fix flag

And everything worked exactly the same as if we formatted using prettier, but it’s just more convenient to use in VSCode, and it will be more correct. But just know that you can format your files this way too. That is, here, using the eslint-plugin-prettier plugin and the eslint-config-prettier config, ESLint adapts to prettier and causes errors that come from it.

About prettier/prettier

prettier/prettier is exactly the rule that is defined in ESLint through prettier. For example, if you specified tabWidth: 5 in the .prettierrc.json file, then the ESLint configuration will throw a prettier/prettier error. And the most interesting thing is that it can also be configured, for example, replacing error with warn

Conclusion

Prettier and ESLint are very powerful tools that require at least a basic understanding to perform to their full potential. I also plan to write identical articles about these tools, since there is really very little information and even on native js it is difficult to intuitively deploy them. I hope this article helped you!