DEV Community: Ferdynand Odhiambo

Understanding Role-Based Access Control (RBAC) in Authentication

Ferdynand Odhiambo — Thu, 25 Sep 2025 11:47:06 +0000

In the vast digital landscape, user authentication answers the question: "Who are you?" But a much trickier, and arguably more important, question for any application is: "What are you allowed to do?"
This is the domain of authorization, and for large-scale, complex systems—from enterprise software to social media platforms and SaaS products—Role-Based Access Control (RBAC) is the industry-standard answer.

RBAC isn't just a technical implementation detail; it's the architectural blueprint that defines how your users interact with your product, ensuring a seamless, secure, and personalized experience. Whether you're building a simple content management system or a multi-tenant application serving thousands of businesses, a solid RBAC structure is what prevents a customer service rep from accidentally deleting a production database or a free-tier user from accessing premium features.

Why RBAC is More Than Just Security
While RBAC is a bedrock of cybersecurity (enforcing the principle of least privilege), its true power lies in its ability to manage complexity and feature segmentation across your entire application.

Instead of writing custom logic for every single user ("User Robin can edit, User Wanjiru can view"), RBAC allows you to define functional Roles (like "Admin," "Editor," or "Basic User"). These roles act as elegant containers for specific Permissions, simplifying your codebase and making your access management infinitely more scalable.

Ready to dive into architecture? Let's explore the core concepts, flow, and real-world implementation/use cases of the access control system powering nearly every professional web application today.

What is Role-Based Access Control (RBAC)?
At its core, RBAC is a method of restricting system access to authorized users. Instead of assigning permissions directly to individual users, RBAC groups permissions into "roles," and then assigns these roles to users. This indirect assignment simplifies management, improves security, and enhances scalability.

Imagine a company with various departments and employees. Each employee needs access to specific resources, but not necessarily all resources. Instead of individually granting or denying access to every single file, folder, or application for each employee, RBAC allows you to define roles like "Marketing Manager," "Sales Representative," or "Software Engineer." Each role is then given a specific set of permissions relevant to that job function.

Key Concepts in RBAC:

Users: Individuals or entities who need access to system resources.
Roles: Collections of permissions that represent a specific job function or responsibility within an organization.
Permissions: Specific actions that can be performed on a resource (e.g., read, write, delete, execute).
Resources: The assets or information within the system that need protection (e.g., files, databases, applications, features).

Here's a simple diagram illustrating the relationship between these concepts:

How RBAC Works
The process of RBAC can be broken down into these steps:
Define Permissions: Identify all the individual actions that can be taken on various resources within your system. For example:

view_customer_data
edit_product_catalog
publish_blog_post
delete_user_account

Create Roles: Group these permissions into logical roles based on job functions or responsibilities.

Admin Role: view_customer_data, edit_product_catalog, publish_blog_post, delete_user_account (all permissions)
Editor Role: view_customer_data, edit_product_catalog, publish_blog_post
Viewer Role: view_customer_data

Assign Roles to Users: Assign one or more roles to each user. A user can have multiple roles, inheriting the combined permissions of all assigned roles.

Enforce Access: When a user attempts to perform an action, the system checks if the user's assigned roles possess the necessary permissions for that action. If they do, access is granted; otherwise, it's denied.
A Visual Representation of Role Assignment:

Advantages of RBAC
RBAC offers numerous benefits for organizations looking to streamline and secure their access management:

Simplified Management: Instead of managing individual permissions for hundreds or thousands of users, administrators only need to manage a smaller number of roles and assign them to users. This significantly reduces administrative overhead.
Improved Security: By enforcing the principle of least privilege (giving users only the access they need to perform their job), RBAC minimizes the risk of unauthorized access and data breaches. When an employee changes roles or leaves the company, simply changing or revoking their role assignments instantly updates their access.
Enhanced Scalability: As an organization grows, adding new users or resources is straightforward. You simply assign existing roles to new users or update roles with new permissions.
Reduced Errors: Manual permission assignments are prone to human error. RBAC standardizes access, leading to fewer mistakes and inconsistencies.
Better Compliance: Many regulatory frameworks (like HIPAA, GDPR, PCI DSS) require organizations to demonstrate granular control over who can access sensitive data. RBAC provides a clear and auditable framework for achieving this.
Clearer Audit Trails: With roles clearly defined, it's easier to audit and understand who had what access at any given time, which is crucial for incident response and compliance.

Use Case Illustrations
Let's explore some practical examples of RBAC in action:
Use Case 1: A Content Management System (CMS)

Consider a blogging platform where different users have varying levels of access to content.

Permissions: create_post, edit_own_post, edit_any_post, publish_post, delete_post, manage_users, view_analytics.
Roles:
- Author: create_post, edit_own_post
- Editor: create_post, edit_own_post, edit_any_post, publish_post
- Administrator: create_post, edit_own_post, edit_any_post, publish_post, delete_post, manage_users, view_analytics
- Reader (Authenticated): view_analytics (for their own posts, if applicable)

When a new blog contributor joins, you simply assign them the "Author" role. If an author is promoted to manage other writers, you assign them the "Editor" role. This is far more efficient than individually granting edit_any_post and publish_post permissions to them.

Use Case 2: An E-commerce Platform
In an e-commerce platform, various teams need access to different parts of the system.

Permissions: view_orders, process_orders, manage_products, update_prices, view_customer_info, process_refunds, access_marketing_tools, manage_discounts.

Roles:
- Customer Service Rep: view_orders, view_customer_info, process_refunds
- Warehouse Manager: view_orders, process_orders
- Product Manager: manage_products, update_prices
- Marketing Specialist: access_marketing_tools, manage_discounts
- Administrator: All permissions This setup ensures that a customer service representative cannot accidentally (or maliciously) change product prices, nor can a warehouse manager launch a marketing campaign. Each role has precisely the access required for its function.

Bridging the gap: From axios to gRPC interceptors in Go

Ferdynand Odhiambo — Sun, 20 Jul 2025 21:56:22 +0000

)

🌟 Introduction

In my previous article on Axios interceptors in Next.js, I explained how to handle tokens, log requests, and catch errors before they hit your actual API call.

Now let’s switch lanes — same logic, different side of the stack.

But wait… gRPC? Go? Interceptors?? Sounds like a Marvel multiverse of concepts. 😅

Fear not! If you’ve used Axios interceptors to attach tokens, handle errors, or log requests, you already understand half the concept.

Let’s explore how interceptors in Go (with gRPC) let you do cool backend ninja stuff, like:

Checking if requests are legit (Auth)
Logging what’s going on (Observability)
Rejecting bad vibes (a.k.a. invalid requests)
Making your code cleaner, smarter, and scalable

But First, What’s gRPC (and Why Should I Care)?

TL;DR: gRPC is a fast, efficient way for microservices to talk to each other — think of it like WhatsApp for backend services, but with strict message formats and no blue ticks.

Faster than REST
Uses Protocol Buffers instead of JSON
Strongly typed APIs
Supports unary and streaming calls If you’re building microservices in Go, gRPC is your best friend — and interceptors are the middleware party crashers who add their own magic to every request.

Axios vs gRPC Interceptors — Visual Time!

Here’s a mental model:

Just like in Axios, interceptors wrap around your actual logic and let you sneak in helpful behavior before/after your calls.

Let’s Write a Simple gRPC Unary Interceptor

Use Case: You want to reject unauthorized users and log the request path.

func AuthLoggerInterceptor(
    ctx context.Context,
    req interface{},
    info *grpc.UnaryServerInfo,
    handler grpc.UnaryHandler,
) (interface{}, error) {
    log.Println("New gRPC call to:", info.FullMethod)

    md, ok := metadata.FromIncomingContext(ctx)
    if !ok {
        return nil, status.Error(codes.Unauthenticated, "No metadata found!")
    }

    token := md["authorization"]
    if len(token) == 0 || token[0] != "Bearer secret123" {
        log.Println("Invalid token")
        return nil, status.Error(codes.Unauthenticated, "Invalid token!")
    }

    // All good? Forward the request to your actual method
    return handler(ctx, req)
}

Plug It Into Your gRPC Server

server := grpc.NewServer(
    grpc.UnaryInterceptor(AuthLoggerInterceptor),
)
pb.RegisterMyServiceServer(server, &MyService{})

And boom — every single request goes through your interceptor like a VIP security gate.

Bonus: What About Streams?

Just like in Axios you don’t always do GET — in gRPC, you can also stream data (think Netflix but backend-y).

Here’s how to intercept streaming RPCs too:

func StreamLoggerInterceptor(
    srv interface{},
    ss grpc.ServerStream,
    info *grpc.StreamServerInfo,
    handler grpc.StreamHandler,
) error {
    log.Println("Stream call to:", info.FullMethod)
    return handler(srv, ss)
}

And attach it:

server := grpc.NewServer(
    grpc.StreamInterceptor(StreamLoggerInterceptor),
)

Real-World Analogy: Coffee Shop

Imagine your gRPC server is a barista ☕.

You (the client) place an order.

The interceptor is the cashier who:

Checks your loyalty card (auth)
Writes your name wrong on the cup (logging lol)
Decides if you deserve a coffee today (validation)
Then your order goes to the barista (actual service logic).

That’s literally what interceptors do.

🎯 Why Should You Care?

Centralized logic — no need to sprinkle "check token" in every service method
Cleaner services — your actual gRPC methods stay focused
Cross-cutting concerns — logging, monitoring, and error handling become a breeze
Scalable AF — perfect for microservices that need to stay DRY and consistent

Want to Learn More?

Here are some golden nuggets to level up your Go + gRPC knowledge:

Wrapping Up

If you’ve already mastered Axios interceptors on the frontend, using interceptors in Go is just the next logical step. You’re now building the backend side of the same bridge — and it’s strong, fast, and clean. 🧱

Interceptors are your backend middleware ninjas — silent but powerful.

Have questions, feedback, or want to show off your microservice setup? Let’s connect. You can also go back and reread my Axios interceptors article if you need a frontend refresher. 💬

Stay curious. Write clean code. And intercept all the things. 🚀

Leveraging Axios Interceptors in Next.js

Ferdynand Odhiambo — Sun, 15 Jun 2025 08:24:14 +0000

🌟 Introduction

In modern web applications, managing API requests efficiently is crucial for delivering a seamless user experience. One of the most effective ways to handle this in a Next.js application is by using Axios interceptors. This article will guide you through implementing request interceptors in Axios to manage authentication tokens, ensuring secure communication with your backend. Let's dive in! 🎉

🤔 What are Axios Interceptors?

Axios interceptors are functions that Axios calls for every request or response. They allow you to modify requests or responses before they are handled by then or catch. This feature is particularly useful for:

🔑 Adding authentication tokens
📜 Logging requests
⚠️ Handling errors globally

🛠️ Setting Up Axios in Next.js

To get started, you need to install Axios in your Next.js project. Open your terminal and run:

npm install axios

Next, create an Axios instance with a base URL for your API. This instance will be used throughout your application for making API calls.

import axios from 'axios';

const api = axios.create({ baseURL: 'http://localhost:8080' });

✨ Implementing Request Interceptors

Now, let’s implement a request interceptor to automatically attach an authentication token to every request. This is how you can do it:

api.interceptors.request.use(
  (config) => {
    if (typeof window !== "undefined") {
      const token = localStorage.getItem("token");
      if (token) {
        config.headers.Authorization = `Bearer ${token}`;
      }
    }
    return config;
  },
  (error) => Promise.reject(error)
);

📖 Explanation:

The interceptor checks if the code is running in the browser (to avoid issues during server-side rendering).
It retrieves the token from localStorage and adds it to the Authorization header of the request if it exists.
If there’s an error in the request configuration, it is rejected.

🎯 Benefits of Using Interceptors

Centralized Logic: By managing authentication in one place, you reduce redundancy and improve maintainability. This means you can easily update your authentication logic without having to change multiple files. 🛠️
Error Handling: You can intercept responses to handle errors globally. For example, if a token is expired, you can redirect users to the login page or refresh the token automatically. 🔄
Cleaner Code: Your API calls remain clean and focused on their primary purpose without repetitive token management. This leads to better readability and maintainability of your code. 📚

📦 Example Usage

Here’s how you can use the configured Axios instance in your Next.js components:

import api from './path/to/your/api';

const fetchData = async () => {
  try {
    const response = await api.get('/data-endpoint');
    console.log(response.data);
  } catch (error) {
    console.error('Error fetching data:', error);
  }
};

In this example, the fetchData function makes a GET request to the specified endpoint. The interceptor ensures that the authentication token is included in the request headers automatically. 🎉

🏁 Conclusion

Using Axios interceptors in your Next.js applications can significantly enhance your API interaction strategy. By automating the process of attaching authentication tokens, you can focus more on building features rather than managing boilerplate code.

If you have any questions or want to share your experiences with Axios and Next.js, feel free to reach out! Let's connect and share knowledge! 💬 Happy coding! 🎈

Cache Invalidation: The Silent Performance Killer

Ferdynand Odhiambo — Wed, 21 May 2025 05:20:18 +0000

The Cache Invalidation Problem
What Is Cache Invalidation?
Why Developers Overlook It
How to Handle Cache Invalidation Like a Pro
- Time-Based Invalidation
- Event-Based Invalidation
Tools to Make It Happen
Real-World Example
Pitfalls to Avoid
Visualizing Cache Invalidation
Conclusion
Keep Learning

The Cache Invalidation Problem

Picture this: you've just built a snappy web app, and you're feeling pretty good about it. You've added Redis to cache frequently accessed data, and your app is flying—pages load in milliseconds, users are happy, and you're a rockstar. But then, a user updates their profile, and… oops. The app still shows their old info. Or worse, a new blog post doesn't appear on the homepage. What's going on? Welcome to the sneaky world of cache invalidation, a concept that can improve your app's performance and reliability.

As a developer, you might think caching is a magic bullet: store data in Redis, serve it fast, and call it a day. But keeping that cached data fresh is where things get tricky. Cache invalidation is often overlooked, and poor strategies can lead to stale data, frustrated users, and late-night debugging sessions. Let’s break it down, explore why it matters, and learn how to tame this silent performance killer.

What Is Cache Invalidation?

At its core, cache invalidation is about ensuring the data in your cache (like Redis) matches the latest data in your database. Think of your cache as a snapshot of your database at a specific moment. When the database changes—say, a user updates their profile or a new blog post is published—that snapshot can become outdated. Cache invalidation is the process of updating or removing the stale snapshot so users always see the right data.

For example, imagine a blog app where the homepage shows the latest posts. You cache the post list in Redis to make the page load faster. But when a new post is added, you need to either update the cache with the new list or clear it entirely so the app fetches the fresh data. If you don't, users might miss the latest content, and your app starts looking like it's stuck in the past.

Why Do Developers Overlook It?

Cache invalidation sounds simple, but it’s one of the trickiest parts of system design. Developers often fall into the “set and forget” trap, assuming that once data is cached, their job is done. After all, Redis is fast, so why complicate things? But ignoring invalidation is like leaving dirty dishes in the sink—eventually, it’s going to stink lol.

The complexity comes from balancing two goals: keeping data fresh and maintaining the speed that caching provides. Get it wrong, and you’re either serving outdated data or losing the performance benefits of caching. Plus, invalidation isn’t something you notice until it fails, making it easy to overlook during development.

How to Handle Cache Invalidation Like a Pro

Don’t worry—cache invalidation doesn’t have to be a nightmare. There are two main strategies to keep your cache in sync, and both are easier than they sound. Let’s explore them with practical examples.

Time-Based Invalidation

The simplest way to handle cache invalidation is to give your cache entries a time-to-live (TTL). This is like setting an expiration date on your cache—after a set time (say, 10 minutes), Redis automatically deletes the entry, and your app fetches fresh data from the database.

How it works: When you store data in Redis, use the SETEX command to set a TTL. For example:

SETEX homepage_cache 600 post_list

caches the post list for 600 seconds (10 minutes).
When to use it: Great for data that doesn’t change often or where slight staleness is okay, like a list of trending articles.
Example: In our blog app, you cache the homepage posts with a 10-minute TTL. Even if a new post is added, the cache will refresh within 10 minutes, keeping things mostly up-to-date.

Event-Based Invalidation: React to Changes

For more precise control, use event-based invalidation. This means clearing or updating the cache whenever the underlying data changes, like when a user updates their profile or a new post is published. It's like telling your cache, "Hey, something changed, let's start fresh."
How it works: When your app writes to the database (e.g., a new post is saved), you trigger a cache update. In Redis, you can use the DEL command to clear a specific cache key or the SET command to update it with new data.
When to use it: Ideal for data that needs to stay fresh, like user profiles or real-time feeds.
Example: In the blog app, when a new post is added, your code runs

DEL homepage_cache

to clear the cached post list. The next request rebuilds the cache with the updated posts. For more complex apps, you can use Redis Pub/Sub to broadcast changes and trigger invalidation across servers.

Tools to Make It Happen

Redis: The star of the show for caching. Use commands like SETEX, DEL, and SET for invalidation.
Pub/Sub: Redis’s publish/subscribe feature lets you notify other parts of your app when data changes, perfect for event-based invalidation.
Your App Framework: Whether you’re using Node.js, Python (Flask/Django), or Java, your app needs logic to trigger invalidation on database writes.

A Real-World Example

Let’s put it all together with our blog app. You’re using Redis to cache the homepage’s list of recent posts, stored under the key homepage_cache. Here’s how it works:
Initial Request: A user visits the homepage. Your app checks Redis for homepage_cache. If it’s empty, it queries the database, caches the post list with SETEX homepage_cache 600 post_list, and serves the page.
New Post Added: Someone publishes a new post. Your app saves it to the database and runs DEL homepage_cache to invalidate the cache.
Next Request: The next user visits the homepage. Redis has no homepage_cache, so your app queries the database again, caches the updated post list, and serves the fresh page.
This keeps the homepage fast (thanks to caching) and up-to-date (thanks to invalidation). You can even combine strategies: use a TTL for general freshness and event-based invalidation for critical updates.

Pitfalls to Avoid

Cache invalidation isn’t foolproof, and there are a couple of traps to watch out for:
Over-Invalidating: If you clear the cache too often (e.g., on every minor database change), your app will hit the database constantly, negating the benefits of caching. Be selective about when to invalidate.
Under-Invalidating: If you let stale data linger too long, users will see outdated content. For example, a TTL of 24 hours might be too long for a dynamic feed.
Race Conditions: In event-based invalidation, multiple updates happening at once can mess up your cache. Use Redis’s atomic operations or locks to stay safe.

Visualizing Cache Invalidation

To get cache invalidation, it helps to see it in action. Here’s a visualization that walks through the process:

A user updates their profile (e.g., changes their username).
The app writes the update to the database.
The app sends a DEL user_profile_cache command to Redis.
The next request fetches the updated profile from the database and re-caches it.

Conclusion

Cache invalidation might seem like a small detail, but it’s a cornerstone of building reliable, high-performance apps. Get it right, and your app stays fast and accurate, delighting users and saving server resources. Get it wrong, and you’re stuck with stale data, confused users, and a lot of extra coffee to fix those bugs.
As a developer, mastering cache invalidation shows you’re thinking beyond code—you’re considering how systems work together.

Keep Learning

Ready to dive deeper? Here are some next steps:
Play with Redis: Set up a local Redis instance and experiment with SETEX and DEL. Try caching a simple JSON object and invalidating it.
Read Up: Check out the Redis documentation at redis for more on TTL and Pub/Sub.
Explore Real Apps: Look at open-source projects on GitHub to see how they handle caching. Search for “Redis cache invalidation” to find examples.
Recommended Book: Designing Data-Intensive Applications by Martin Kleppmann has a great section on caching and consistency.
Cache invalidation doesn’t have to be a silent performance killer. With the right strategies, you can keep your cache fresh, your app fast, and your users happy. So go forth, invalidate those caches, and build something awesome!

PointaFam: Connecting Farmers with Urban Retailers

Ferdynand Odhiambo — Fri, 20 Sep 2024 18:53:34 +0000

Introduction

PointaFam is a platform designed to bridge the gap between local farmers and urban retailers. This project addresses the challenges that local farmers face in accessing urban markets, providing a streamlined, user-friendly experience for both farmers and retailers.

I developed PointaFam as a solo project, serving as the Backend Developer. The timeline for the project spanned 7 weeks, focusing on building the core functionalities of a marketplace platform. I used Go, GORM, and PostgreSQL for the backend, while the frontend was developed with HTML, CSS, JavaScript, and Bootstrap.

This project was created to serve both farmers and retailers, offering farmers a way to showcase their products and urban retailers a reliable source for fresh produce. It also simplifies the process for retailers to search, filter, and add products to their carts.

My focus for this project was on the backend architecture, ensuring the smooth interaction between users and the data.

Why PointaFam?

Growing up, I spent many years living in a rural area where farming was a way of life. I remember how hard it was for local farmers to transport their produce to urban centers. Many of them had high-quality products but lacked the means to access a reliable market, resulting in waste and missed opportunities. Witnessing this inefficiency firsthand stayed with me, and it fueled my passion to solve the problem using technology.

I wanted to create a platform that empowered local farmers, making it easier for them to reach urban retailers and grow their businesses. Developing PointaFam was a personal project, combining my desire to give back to the farming community with my interest in backend systems and marketplace platforms.

What We Accomplished

PointaFam successfully connects local farmers with urban retailers by providing a platform where retailers can easily find and purchase fresh produce.

Architecture Overview:

The core of PointaFam is built using a Go backend, GORM ORM for database interaction, and PostgreSQL for data storage. For the frontend, I used HTML, CSS, and JavaScript to create a responsive user interface. The goal was to build a lightweight platform while ensuring scalability and efficiency.

Key features:

Search & Filter: Retailers can search for specific products and filter them by categories, pricing, and availability.
Add to Cart: Retailers can add products to their cart, making the shopping experience seamless.
Responsive Design: The platform works well on both desktop and mobile devices, allowing retailers to access it from anywhere.

My Most Difficult Challenge

The most difficult technical challenge I faced was integrating the cart functionality with the backend. Initially, I struggled with ensuring that the cart would persist across sessions. I wanted the retailers to be able to leave the platform and come back to find their cart intact.

Situation:

Early in the project, I realized that a cart persistence feature would be essential for improving user experience. If retailers added products but left the site before completing their purchase, I needed a way to store that data and restore it when they returned.

Task:

I had to design a system that would save the cart’s state both in the frontend and backend while maintaining security and performance.

Action:

I researched session-based storage and database design patterns for storing cart data. Using Go’s session management libraries and PostgreSQL, I implemented a system that saved cart items in the database tied to user sessions. I also set up a secure cookie-based mechanism to track logged-in users while keeping the session data encrypted.

Result:

After a few iterations, I successfully implemented the feature. Now, retailers can return to the platform and pick up where they left off without losing their cart items. This was a critical step in improving user retention and overall experience.

Lessons Learned

Through this project, I deepened my understanding of backend development, specifically in relation to marketplaces. I learned how to optimize database queries to handle complex searches efficiently, implement session management securely, and design systems that are user-friendly and scalable.

One takeaway from this experience is the importance of scalability. While building PointaFam, I realized that making decisions that favor scalability early on prevents many issues as the platform grows. In the future, I plan to further develop my skills in system architecture to handle larger-scale applications.

About Me

I’m a passionate Full Stack Developer(Backend Heavy) with experience in Go, C, Python, Javascript, PostgreSQL and building scalable systems. Check out my PointaFam project on GitHub and the deployed platform. Feel free to connect with me on LinkedIn.

Mastering CORS in Golang: A Comprehensive Guide.

Ferdynand Odhiambo — Wed, 04 Sep 2024 00:10:26 +0000

In today's interconnected web ecosystem,Cross-Origin Resource Sharing (CORS) plays a crucial role in securing API interactions. Developers working with Go, a powerful programming language for building web applications, often encounter CORS-related challenges.

This comprehensive guide aims to demystify golang cors implementation, providing developers with the knowledge and tools to handle cross-origin requests effectively.

The article will explore the fundamentals of CORS and its significance in modern web development. It will then delve into practical implementations of CORS in Go, covering basic setup and advanced configurations.
Readers will gain insights into best practices for securing their Go APIs while ensuring smooth communication between different domains.
By the end, developers will have a solid understanding of how to master CORS in their Go projects, enhancing the security and functionality of their web applications.

Understanding CORS and Its Importance

Cross-Origin Resource Sharing (CORS) is a crucial mechanism in modern web development that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served. This mechanism plays a vital role in enabling communication between different domains while maintaining security.

What is CORS?

CORS stands for Cross-Origin Resource Sharing. It's a web security feature that browsers implement to control and restrict web requests made across different origins (domains, protocols, or ports). In essence, CORS is an HTTP header-based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources.
The CORS specification defines a way for browsers to make cross-domain requests on behalf of a web application. This is done by adding an HTTP header specifying which domains can send requests. These CORS headers enable servers to define which origins are permitted to access their resources, which is vital in preventing unauthorized access, reducing the risk of data breaches, and enhancing overall security.

The Same-Origin Policy

To understand CORS, it's essential to grasp the concept of the Same-Origin Policy (SOP). The SOP is a critical security mechanism that restricts how a document or script loaded by one origin can interact with a resource from another origin . It helps isolate potentially malicious documents, reducing possible attack vectors.
Two URLs have the same origin if the protocol, port (if specified), and host are the same for both .
This policy ensures that a web page can only access resources from the same origin it belongs to. For example, JavaScript can only retrieve data from a resource that shares the same origin (same domain, protocol, and port)
The Same-Origin Policy is based on three components of an origin:
1. Origin Domain: The domain name of the web page where the resources originate, e.g., "example.com".
2.Protocol: The communication protocol used to access the web page, e.g., "https://" or "http://".
3.Port: "80" or "443" as default .

Why CORS is Necessary

CORS is necessary because it allows browsers to enforce the Same-Origin Policy while providing a controlled mechanism for cross-origin resource sharing.
Without CORS, a malicious script could make a request to a server in another domain and access resources that the user of the page is not intended to have access to CORS overcomes the limitations imposed by the Same-Origin Policy, allowing web browsers to relax the restrictions and grant access to its resources for requests coming from a different origin . This is particularly important in scenarios where legitimate cross-origin requests are required, such as when loading data from another website or making an AJAX request.
When a web browser makes a request to a different origin, it initiates a CORS process to determine if the requested resource should be accessible. The server, in response, includes the "Access-Control-Allow-Origin" header in its HTTP response, specifying the allowed origins that are permitted to access the requested resource.
By implementing CORS, developers can create more flexible and interconnected web applications while maintaining a high level of security. It allows for the controlled sharing of resources across different domains, enhancing the functionality and user experience of modern web applications.

Implementing CORS in Golang

Implementing Cross-Origin Resource Sharing (CORS) in Golang involves handling HTTP requests and responses with appropriate headers. This section explores different approaches to implement CORS in Go applications.
Using the net/http Package
The standard net/http package in Go provides a straightforward way to handle CORS. Developers can check the request method in the handler function and respond accordingly. For instance:

This approach allows for custom handling of different HTTP methods, including the crucial OPTIONS method used in CORS preflight requests.
Handling Preflight Requests
Preflight requests are a key component of CORS. They are sent by the browser to check if the actual request is safe to send. To handle these, developers can create a separate handler for OPTIONS requests:

This wrapper function allows for reusable CORS logic across different endpoints.
Setting CORS Headers
To properly implement CORS, specific headers must be set in the HTTP response. Here's an example of setting these headers:

These headers define which origins, methods, and headers are allowed in cross-origin requests.
It's crucial to carefully configure these headers to maintain security while enabling necessary cross-origin functionality.

Advanced CORS Configurations in Golang

Allowing Specific Origins
When implementing CORS in Golang, developers can configure specific origins that are allowed to access resources.
Instead of using the wildcard "*", which allows all origins, it's more secure to specify exact domains.
For instance, developers can set the Access-Control-Allow-Origin header to http://localhost:3000
This approach restricts access to only the specified origin, enhancing security.
For more dynamic control, the AllowOriginFunc, option can be utilized. This custom function validates the origin, returning true if allowed or false otherwise It overrides the AllowedOrigins list, providing flexibility in origin validation.

Configuring Allowed Methods and Headers
CORS configuration in Go allows fine-tuning of allowed HTTP methods and headers. The AllowedMethods option specifies which HTTP methods are permitted for cross-origin requests. By default, it includes simple methods like HEAD, GET, and POST
Developers can expand this list to include other methods as needed.
Similarly, the AllowedHeaders option controls which non-simple headers can be used in cross-origin requests. If set to "*", all headers are allowed
This configuration is crucial for controlling what type of requests and data can be sent from different origins.

Handling Credentials
The AllowCredentials option is vital for scenarios involving user authentication. When set to true, it adds the Access-Control-Allow-Credentials: true header to the HTTP response . This allows the inclusion of user credentials like cookies, HTTP authentication, or client-side SSL certificates in cross-origin requests.
Developers should exercise caution when enabling this option, as it can have security implications. It's recommended to use this in conjunction with specific origin settings rather than wildcard origins to maintain security.
By leveraging these advanced configurations, developers can create more secure and flexible CORS implementations in their Golang applications, tailoring the cross-origin resource sharing to their specific needs while maintaining robust security measures.

Common Pitfalls and Debugging

Pitfalls

When dealing with Cross-Origin Resource Sharing (CORS), developers often encounter several common pitfalls that can lead to frustrating debugging sessions. Here are some of the most frequent issues:

Incorrect CORS Headers: One of the most common mistakes is misconfiguring the CORS headers on the server side. If the Access-Control-Allow-Origin header is not set correctly, browsers will block requests from different origins.
Preflight Requests: Many developers overlook preflight requests, which are sent by browsers to determine whether a cross-origin request is safe to send. Failing to handle OPTIONS requests properly can result in blocked requests.
Credentials Misconfiguration: When making requests that require credentials (like cookies or HTTP authentication), forgetting to set withCredentials in XMLHttpRequest or Fetch API can lead to issues.
Mismatched Protocols: Mixing secure (HTTPS) and insecure (HTTP) protocols can also cause CORS errors, as browsers enforce stricter rules for security reasons.

Solutions

To effectively debug CORS-related issues, developers can utilize browser tools and logs as follows:

Inspect Network Activity: Use your browser's developer tools (usually found under "Network" tab) to inspect all network activity related to your application. Look for any failed requests and examine their headers and responses.
Check Console Logs: The console log will often provide detailed error messages related to CORS failures. Pay attention to any warnings or errors that indicate what's wrong with your request.
Verify Server Configuration: Ensure that your server is configured correctly by checking its response headers for Access-Control-Allow-Origin. You might need additional headers like Access-Control-Allow-Methods or Access-Control-Allow-Headers.
Test Preflight Requests: Manually test preflight OPTIONS requests using tools like Postman or cURL to ensure they return correct responses from your server.
For example here’s a simple guide on how you can test preflight OPTIONS requests using Postman:
Steps:
1. Open Postman and create a new request.
2. Set the Request Method to OPTIONS.
3. Enter the URL of the endpoint (e.g., https://api.example.com/endpoint).
4. Under the Headers tab, add the following headers: ◦ Origin: https://your-site.com ◦ Access-Control-Request-Method: POST (or the method you're testing) ◦ Access-Control-Request-Headers: Content-Type, Authorization
5. Click Send to see the response. Expected Response: You should see a response with CORS headers, similar to the example mentioned above. If there’s a CORS misconfiguration, the response will typically contain an error message.
Use Browser Extensions: Consider using browser extensions designed for debugging CORS issues, such as "CORS Everywhere" for Firefox or similar tools available for Chrome, which temporarily disable CORS policies during development.

By understanding these common pitfalls and employing effective debugging strategies, developers can navigate CORS challenges more smoothly and ensure their applications communicate seamlessly across different origins.

Security Practices in CORS

When it comes to web security, minimizing Cross-Origin Resource Sharing (CORS) vulnerabilities and handling credentials securely is essential for protecting sensitive data. Here are some best practices to follow:

Restrict Origins: Always specify the exact origins that are allowed to access your resources. Avoid using wildcards (*) in the Access-Control-Allow-Origin header, as this can expose your application to potential attacks from untrusted domains.
Implement Preflight Requests: For complex requests, ensure that you have configured preflight requests properly. This allows browsers to check permissions before sending actual requests, providing an additional layer of security.
Use HTTPS: Ensure that your application is served over HTTPS instead of HTTP. This encrypts data in transit and protects against man-in-the-middle attacks that could intercept sensitive information.
Limit Allowed Methods: Specify only the HTTP methods that are necessary for your application in the Access-Control-Allow-Methods header (e.g., GET, POST). Limiting methods reduces the attack surface.
Handle Credentials Securely: If you need to allow credentials such as cookies or HTTP authentication in cross-origin requests, set Access-Control-Allow-Credentials to true but ensure you’re still restricting origins appropriately.
Validate Input Data: Always validate and sanitize input data on both client and server sides to prevent injection attacks and other malicious activities targeting your API endpoints.
Regularly Review CORS Policies: Periodically review and update your CORS policies as needed based on changes in your application architecture or deployment environment. By following these guidelines, developers can significantly reduce CORS-related vulnerabilities while ensuring secure handling of credentials within their applications.

Conclusion

Mastering CORS in Golang has a significant impact on creating secure and flexible web applications. This guide has explored the basics of CORS, its importance in modern web development, and how to implement it effectively in Go.
From handling preflight requests to setting up advanced configurations, developers now have the tools to build robust APIs that can communicate across different domains while maintaining strong security measures.
To wrap up, the knowledge gained from this guide empowers developers to create Go applications that can seamlessly interact with resources from various origins. By applying these CORS techniques, developers can enhance the functionality of their web applications, enabling smoother data exchange between different domains. This leads to more dynamic and interconnected web ecosystems, all while keeping security at the forefront of development practices.

Postmortem: A Guide to Learning from Failure

Ferdynand Odhiambo — Sun, 09 Jun 2024 12:23:33 +0000

Introduction

In the world of software development, postmortems are a crucial step in ensuring that we learn from our mistakes and improve our processes. A postmortem is a detailed analysis of a project or incident that identifies what went wrong, what went right, and what we can do better next time. In this blog, we will explore the importance of postmortems, how to conduct a successful postmortem, and provide a template to help you get started.
Why Postmortems Matter
Postmortems are essential for several reasons:

Learning from Failure: Postmortems help us identify the root causes of failures and provide actionable steps to prevent them from happening again.
Improving Processes: By analyzing what went well and what didn't, we can refine our processes and make them more efficient.
Enhancing Communication: Postmortems promote open communication among team members, ensuring that everyone is on the same page and working towards the same goals.

Conducting a Successful Postmortem

To conduct a successful postmortem, follow these steps:

Schedule the Meeting: Schedule the postmortem meeting as close to the project's completion as possible.
Prepare the Agenda: Create an agenda that includes the following sections:
    What Went Well: Identify the strengths and successes of the project.
    What Went Wrong: Identify the challenges and failures of the project.
    Lessons Learned: Document the lessons learned from the project.
    Action Items: Create a list of actionable steps to improve future projects.
Prepare the Team: Ensure that all team members are prepared for the meeting by providing them with a survey or questionnaire to fill out beforehand. This helps to gather their thoughts and opinions on the project.
Conduct the Meeting: Lead the meeting with a positive and objective mindset. Encourage open communication and ensure that everyone has a chance to share their thoughts and opinions.
Document the Meeting: Take detailed notes during the meeting and ensure that all action items are documented.

Postmortem Template

Here is a template you can use to conduct a successful postmortem: What Went Well

What were the core strengths of this project team?
What were the biggest weaknesses of this team?
Did we get the why? If no, why?

What Went Wrong

What were the biggest challenges faced during the project?
What were the most significant failures or setbacks?
What could we have done differently?

Lessons Learned

What did we learn from this project?
What would we do differently next time?
What are the key takeaways from this project?

Action Items

What are the actionable steps we can take to improve future projects?
What are the key changes we need to make to our processes?
What are the key skills or knowledge we need to acquire?

Here is an example of a postmortem i did as part of my project:

Postmortem: Outage of the E-commerce Website

Issue Summary

On June 7, 2024, at 10:45 AM UTC, our e-commerce website experienced an outage that lasted for approximately 2 hours and 15 minutes until it was fully restored at 1:00 PM UTC. The outage affected 30% of our users, causing them to experience slow loading times and occasional errors when attempting to place orders. The root cause of the outage was a misconfigured database connection.
Timeline

*10:45 AM UTC*: The issue was detected by our monitoring system, which alerted our DevOps team to a sudden spike in database query times.
*10:50 AM UTC*: The DevOps team investigated the issue, initially suspecting a high traffic volume due to a recent marketing campaign. They checked the server logs and monitored the database performance.
*11:15 AM UTC*: The team escalated the issue to the database administration team, assuming it was a database performance issue.
*11:30 AM UTC*: The database administration team investigated the issue, but their initial findings did not indicate any performance issues.
*12:15 PM UTC*: The DevOps team re-investigated the issue, this time focusing on the database connection configuration. They discovered a misconfigured database connection that was causing the slow query times.
*1:00 PM UTC*: The issue was resolved by updating the database connection configuration and restarting the database service.

Root Cause and Resolution

The root cause of the outage was a misconfigured database connection. This misconfiguration caused the database to take longer to respond to queries, resulting in slow loading times and occasional errors for users. The issue was resolved by updating the database connection configuration and restarting the database service. This ensured that the database was properly connected and queries were processed efficiently.

Corrective and Preventative Measures

To prevent similar outages in the future, we will:

Improve Database Connection Configuration: Regularly review and update database connection configurations to ensure they are properly set up.
Enhance Monitoring: Implement additional monitoring to detect potential issues earlier, such as monitoring database query times and connection configurations.
Database Performance Optimization: Regularly optimize database performance to prevent slow query times.
Database Connection Testing: Implement automated testing for database connections to detect misconfiguration.
Documentation: Update documentation to include detailed instructions for configuring database connections.

By implementing these measures, we can reduce the likelihood of similar outages and ensure a smoother user experience for our customers.

Conclusion

The outage of our e-commerce website on June 7, 2024, was caused by a misconfiguration in the database connection. The issue was detected by our monitoring system and resolved by updating the database connection configuration and restarting the database service. To prevent similar outages in the future, we will improve database connection configuration, enhance monitoring, optimize database performance, implement automated testing for database connections, and update documentation.

The Magical Journey of a URL: Unravelling the Mysteries of the Internet

Ferdynand Odhiambo — Sat, 18 May 2024 10:03:53 +0000

Have you ever wondered what happens when you type a URL into your browser and press Enter? It's like magic, right? One second you're staring at a blank page, and the next, you're scrolling through your favorite website. But, have you ever stopped to think about the incredible journey that URL takes to get from your keyboard to the screen?

In this post, we'll embark on an adventure to uncover the secrets of the internet. Buckle up, folks!

The DNS Detective: Cracking the Code

The first stop on our journey is the Domain Name System (DNS). Think of DNS as the internet's phonebook. When you type in a URL, your browser sends a request to a DNS resolver, which is like a super-smart detective. The resolver's job is to find the IP address associated with the domain name.

Imagine you're trying to find a friend's phone number. You ask a mutual friend (the DNS resolver) if they have your friend's number. They check their phonebook (DNS database) and give you the number. Now, you can call your friend (the website) directly.
Let's break down the DNS lookup process in a more relatable way:

You type a website address into your browser: When you type a website address like "www.example.com" into your browser, it's like asking for directions to a place you want to visit.
Your browser asks for help: Your browser then reaches out to a local guide called the DNS resolver, which is like your personal GPS for the internet, often provided by your internet service provider (ISP).
Checking the memory lane: The DNS resolver first checks its memory to see if it remembers the way to the website you're looking for. If it does, it quickly gives you the address (IP) so you can reach your destination faster.
Asking the big bosses: If the DNS resolver can't remember the way, it reaches out to the big bosses of the internet, the root nameservers, to get directions. Getting closer to the destination: The root nameserver points the way to the top-level domain (TLD) nameserver, like ".com" or ".org," which holds more specific directions.
Narrowing down the search: The TLD nameserver then guides you to the authoritative nameserver, which is like the local expert who knows exactly where the website is located.
Receiving the final directions: The authoritative nameserver finally provides the exact address (IP) of the website you're looking for.
Heading to your destination: Armed with the correct address, the DNS resolver gives you the directions, and your browser sets off to visit the website by contacting the server at that address.
Possible detours: Sometimes, there may be extra stops or detours if the directions are not readily available or if the website uses advanced services like load balancing or content delivery networks.
Remembering the way: Once you've found the website, your DNS resolver and browser remember the directions for a while (TTL) so that future visits to the same site are quicker and smoother. This process is like a digital journey where your browser navigates the internet landscape with the help of these DNS guides to ensure you reach your desired online destinations efficiently.

TCP/IP: The Dynamic Duo

Once we have the IP address, it's time to establish a connection. This is where Transmission Control Protocol (TCP) and Internet Protocol (IP) come into play. TCP ensures that data is delivered in the correct order, while IP routes the data packets between your computer and the server.

Think of TCP as a reliable postal service, guaranteeing that your letter (data) arrives at the correct address in the correct order. IP is like the postal truck, delivering the letter to the right mailbox (server).

Let's simplify the technical process of how a webpage loads in your browser:

Asking for directions: When you type a website address, your browser sends a request to the server's address (like sending a message to a friend to meet up).
Making a connection: The server gets your request and responds with a message to confirm it received your request (like waving back when someone acknowledges you).
Shaking hands: This back-and-forth is like a handshake between your browser and the server to agree to talk and share information securely.
Requesting the webpage: Once the handshake is done, your browser asks for the webpage you want (like ordering your favorite dish at a restaurant).
Receiving the webpage: The server gets your request and sends back the webpage's code (like receiving a package with all the ingredients to make your dish).
Putting it all together: Your browser gets the code and starts putting together the webpage on your screen (like following a recipe to cook a meal).
Getting the extras: Any extra stuff the webpage needs, like images or videos, are also requested and received to complete the full experience (like getting side dishes and drinks with your meal).

This process is like a friendly conversation between your browser and the server, where they exchange information to make sure you get the webpage you asked for in a way that's reliable and organized, just like meeting a friend for a meal and enjoying all the goodies together.

The Firewall: The Guardian of the Server

As the data packets travel to the server, they must pass through a firewall. This is like a security checkpoint, ensuring that only authorized traffic reaches the server.
Firewalls use different rules to decide if a request can pass through:

Source and Destination Rules: These rules decide if the request is allowed based on where it's coming from and where it's going. For instance, a firewall might say, "No entry from certain countries," or "Only specific addresses can come in."
Traffic Type Rules: These rules focus on the kind of traffic trying to get through. For example, a firewall might block certain ports known for trouble, like those used by bad software, or only let through safe types of traffic like web browsing (HTTP) or secure connections (HTTPS).
Allowing or Blocking: If the request fits the firewall's rules, it gets the green light to pass through to the website. This means your browser can reach the site and show you what you're looking for.
Blocking Unwanted Requests: On the flip side, if the request doesn't match the rules, the firewall puts up a "No Entry" sign. In this case, your browser won't be able to connect to the website because the firewall is keeping it safe by blocking anything that doesn't meet its security standards.

Imagine a bouncer at a nightclub, carefully screening each guest to ensure they're on the list. The firewall does the same, protecting the server from unwanted visitors.

HTTPS/SSL: The Encryption Express

Now, we need to secure the connection. This is where Hypertext Transfer Protocol Secure (HTTPS) and Secure Sockets Layer (SSL) come in. They encrypt the data, making it unreadable to anyone except the intended recipient.

Think of HTTPS/SSL as a secret code. Only the sender and the intended recipient have the key to decipher the message, keeping it safe from prying eyes.

The Load-Balancer: The Traffic Cop

If the website is very popular, it may use a load balancer. This is like a traffic cop, directing incoming traffic to one of many servers. This ensures that no single server is overwhelmed, providing a smoother user experience.

Imagine a busy highway with multiple lanes. The load balancer is like a traffic manager, directing cars (requests) to the least congested lane (server), keeping the traffic flowing smoothly.

The Web Server: The Content King

The request finally reaches the web server, which hosts the website's files and content. This is like a librarian, retrieving the correct book (file) from the shelf and handing it to you.

The Application Server: The Dynamic Dynamo

For dynamic content or interactive features, the web server may communicate with an application server. This is like a personal assistant, processing complex requests and executing scripts.

Imagine a concierge at a luxury hotel, taking care of your every need. The application server does the same, handling requests that require more processing power.

The Database: The Data Vault

If the request requires data retrieval or storage, the application server communicates with a database server. This is like a secure vault, storing and retrieving data as needed.

Think of a bank vault, where valuable information is safely stored. The database server does the same, providing secure access to data.

The Grand Finale: Rendering the Page

Let's think of rendering a webpage like a master chef preparing a delicious meal:

Receiving the Recipe: When your browser gets the response from the web server, it's like receiving a recipe book with all the ingredients and instructions to make a perfect dish (the webpage).
Preparing the Ingredients: The browser starts by interpreting the HTML code, which is like following the recipe to prepare the main ingredients (text, images, etc.). It then adds the CSS styles, which are like the seasonings and presentation instructions to make the dish look appealing.
Adding the Finishing Touches: If there's any JavaScript code, it's like adding a special sauce to the dish that makes it interactive and dynamic. The browser executes this code to bring the page to life.
Serving the Meal: Once all the ingredients are prepared and the finishing touches are added, the browser serves the fully rendered webpage to you. You can now enjoy your meal by interacting with the page, clicking on links, entering text, or exploring other elements on the page. In this way, the browser is like a skilled chef that takes the raw ingredients (HTML, CSS, JavaScript) and turns them into a beautiful, functional, and delicious webpage that you can enjoy. And that's it The URL has completed its magical journey, and your website loads on your screen. It's a remarkable process, involving many players working together behind the scenes.

Next time you type a URL and press Enter, remember the incredible journey it takes to get to your screen. It's a testament to the power of technology and the incredible complexity of the internet.

Conclusion

In this post, we've explored the fascinating world of URLs, from DNS to rendering the page. We've seen how each component works together to deliver the content you see on your screen. It's a remarkable process, and one that's essential to our daily lives.

So, the next time you're browsing the internet, take a moment to appreciate the magic that happens behind the scenes.

DEV Community: Ferdynand Odhiambo

Understanding Role-Based Access Control (RBAC) in Authentication

Bridging the gap: From axios to gRPC interceptors in Go

🌟 Introduction

Let’s Write a Simple gRPC Unary Interceptor

Plug It Into Your gRPC Server

Bonus: What About Streams?

Real-World Analogy: Coffee Shop

🎯 Why Should You Care?

Want to Learn More?

Wrapping Up

Leveraging Axios Interceptors in Next.js

🌟 Introduction

🤔 What are Axios Interceptors?

🛠️ Setting Up Axios in Next.js

✨ Implementing Request Interceptors

📖 Explanation:

🎯 Benefits of Using Interceptors

📦 Example Usage

🏁 Conclusion

Cache Invalidation: The Silent Performance Killer

Table of Contents

The Cache Invalidation Problem

What Is Cache Invalidation?

Why Do Developers Overlook It?

How to Handle Cache Invalidation Like a Pro

Time-Based Invalidation

Event-Based Invalidation: React to Changes

Tools to Make It Happen

A Real-World Example

Pitfalls to Avoid

Visualizing Cache Invalidation

Conclusion

Keep Learning

PointaFam: Connecting Farmers with Urban Retailers

Introduction

Why PointaFam?

What We Accomplished

Architecture Overview:

My Most Difficult Challenge

Situation:

Task:

Action:

Result:

Lessons Learned

About Me

Mastering CORS in Golang: A Comprehensive Guide.

Understanding CORS and Its Importance

What is CORS?

The Same-Origin Policy

Why CORS is Necessary

Implementing CORS in Golang

Advanced CORS Configurations in Golang

Common Pitfalls and Debugging

Pitfalls

Solutions

Security Practices in CORS

Conclusion

Postmortem: A Guide to Learning from Failure

Introduction

Conducting a Successful Postmortem

Postmortem Template

What Went Wrong

Lessons Learned

Action Items

Postmortem: Outage of the E-commerce Website

Root Cause and Resolution

Corrective and Preventative Measures

Conclusion

The Magical Journey of a URL: Unravelling the Mysteries of the Internet

The DNS Detective: Cracking the Code

TCP/IP: The Dynamic Duo

The Firewall: The Guardian of the Server

HTTPS/SSL: The Encryption Express

The Load-Balancer: The Traffic Cop

The Web Server: The Content King

The Application Server: The Dynamic Dynamo

The Database: The Data Vault

The Grand Finale: Rendering the Page

Conclusion