DEV Community: Kelvin Amoaba

What Actually Determines a File's Type

Kelvin Amoaba — Sat, 13 Dec 2025 06:13:45 +0000

Every file format has a specification, “an agreed-upon structure that defines how the bytes in that file are organized”. Just like we have standards for internet protocols, we have standards for file types. When an application opens a PDF or parses a PNG, it’s reading bytes according to that format’s predefined rules.

We usually identify files by their extension: .zip, .txt, .jpg. But extensions are really just hints for humans and the operating system. They’re convenient labels, not the actual source of truth, which is why renaming photo.jpg to photo.png doesn’t convert the image.

Extensions are just hints, the real determining of the type is done through “Magic Numbers”

Magic Numbers

A magic number is a sequence of bytes, located at the beginning or specific offsets of a file that serves as a unique signature to identify the file format or type.

Each file format has the universally agreed upon magic number, this is what applications check anytime they need to or have to determine the file format of a file regardless of what the extension claims.

Eg, for PNG files, this magic number is 89 50 4E 47, for zip files, it’s 50 4B 03 04. Bitmap images start with 42 4D, which is just BM in ASCII (short for “bitmap”).

Here is an example that reads a file with a bmp extension, but actually digs into the bytes to confirm whether or not it’s a bitmap image

package main

import (
    “bytes”
    “fmt”
    “io”
    “log”
    “os”
)


func main() {
    f, err := os.Open(”sample.bmp”)
    if err != nil {
    log.Fatal(err)
    }
    defer f.Close()

    // Read the first 2 bytes (The Magic Number)
    header := make([]byte, 2)
    if _, err := io.ReadFull(f, header); err != nil {
        log.Fatal(err)
    }

    // BMP signature is 0x42, 0x4D
    bmpSig := []byte{0x42, 0x4D}

    if bytes.Equal(header, bmpSig) {
        fmt.Println(”Valid BMP detected”)
    } else {
        fmt.Println(”Invalid file format”)
    }
}

The file command on Unix uses these signatures to identify files regardless of extension. After the signature, most formats include metadata describing the content, dimensions for images, sample rate for audio, author information for documents, etc.

Categories of File Structures

File formats generally fall into a few structural categories:

Binary formats with rigid structure (PNG, JPEG, MP3): every byte position has specific meaning according to the spec. Programs parse these by reading exact offsets.
Text-based structured formats (JSON, XML, HTML, CSV): human-readable text following grammar rules. Easier to debug but larger file sizes.
Container formats (ZIP, MP4, PDF): these are like filesystems within a file, containing multiple embedded files or streams. An MP4 might contain separate video, audio, and subtitle tracks. A DOCX is actually a ZIP containing XML files.

Essentially, knowing how to move bytes around and going through specs, you can write your own parsers for lots of file types, I will demostrate this in another writing of a simple script to convert images to greyscale by modifying the bytes that make up the image.

Logs Multiplexing in Docker

Kelvin Amoaba — Fri, 17 Oct 2025 12:36:02 +0000

Logs multiplexing is the way that docker sends logs from containers to whatever client might be requesting for those logs. Logs multiplexing is when the various data from the output streams of the process being run in the container is combined into one stream and passed to clients.

The Problem Docker Tried to Solve

Whenever programs are being executed, there are 2 available streams on which they can channel results / outputs to, we have the standard output (stdout) and the standard error (stderr); there is standard input (stdin) but that is mostly for receiving inputs into programs. Whenever you run the command like docker logs <container> the problem was now how docker is going to ensure that those outputs from the different streams arrive in the exact order they were being produced inside the container and also making sure that the different streams could be identified by the clients making the request to view those logs.

The naive approach could be managing two different networks on which results from stdout could be passed on one and the results from stderr could also be passed on the other. But then that would mean managing two different network streams and the whole complexity associated with that. Assuming one network stream goes down, what happens? How do we keep track of the order that the outputs were produced, these among many more reasons are the reason for multiplexing.

Multiplexer

In electronics, a multiplexer looks like something like this.

Image source

From the simple eye view, you can see that there are a number of input streams that are combined to form one output. You can think of docker logs multiplexing as the same concept, combining the various streams into one single stream.

Decoding the Multiplexed Stream

Docker uses a simple framing protocol. Each chunk of data gets prefixed with an 8-byte header. The first byte identifies which stream it came from (0 for stdin, 1 for stdout, 2 for stderr), bytes 1-3 are reserved (always 0x00) and the next bytes (4-7) contain the payload size.

The header looks like this:

[STREAM_TYPE] [0x00, 0x00, 0x00] [PAYLOAD_SIZE]

The PAYLOAD_SIZE allows the client to parse the exact content in the stream coming in without buffering or figuring out where one chunk ends and the another begins.

This framing header lets the receiving end parse the stream unambiguously. The data stays intact and in order, but now it's carrying metadata about its origin. When you use commands like docker logs, you're actually reading from this multiplexed stream that Docker has stored. Docker can show you just stdout, just stderr, or both together because it knows which bytes came from which stream thanks to that multiplexing metadata. This solves the problem of how to manage two different network streams and the whole complexity associated with that, you just focus on having a single stream to deal with.

Breakdown of the 8-byte header

Byte 0 : Stream type (0 = stdin, 1 = stdout, 2 = stderr)
Bytes 1-3 : Reserved (always 0x00)
Bytes 4-7 : Payload size (big-endian uint32)
Bytes 8-n : Payload (the actual log data)

Here's a simple example of how you might parse this in Python when connecting to Docker's attach API:

import struct

def read_docker_stream(stream):
    while True:
        header = stream.read(8)
        if not header:
            break

        stream_type, _, _, _, size = struct.unpack('>BBBBI', header)
        payload = stream.read(size)

        if stream_type == 1:
            print(f"STDOUT: {payload.decode()}")
        elif stream_type == 2:
            print(f"STDERR: {payload.decode()}")

What goes over the wire for Hello?

Assuming your container outputs Hello to standard output, here is how docker will send it over the wire:

[1, 00, 00, 00, 00, 00, 00, 05] [48 65 6c 6c 6f]

where [48 65 6c 6c 6f] is the hex representation of the ASCII representation of the string "Hello". The 05 is the payload size and the 1 is the stream type, in this case, stdout.

This idea of multiplexing is not unique to Docker. It's a common pattern in systems engineering whenever there is a need to combine multiple logical channels into a single physical channel. HTTP/2 does this with web requests, SSH does this when you have multiple terminal sessions over one encrypted connection and so on.

Monotonic and Wall Clock Time

Kelvin Amoaba — Sun, 16 Mar 2025 13:17:26 +0000

Monotonic and wall clock time are two ways we measure time.

Wall clock time is the time we see on our clocks. It's the time we are all used to and respond with when someone asks "what time it is?". Monotonic time on the other hand, is one that simply continues to increase since the computer started. When used in programming, it's the time that has passed from the point the timer was started. Monotonic time is mostly used to measure the time that has elapsed between two events.

Monotonic times have two characteristics:

They tick forward at a regular rate
They are detached from current time of day

The value you get from reading a monotonic clock is typically a long integer. It's usefulness is greatly seen when it's compared with other monotonic times.

The reason why we need to keep track of the two types of time is because, wall clock time does not uniformly increase. It can be affected by the user's manual adjustments to the clock, daylight saving time, and other factors like network time changes. Since it can be affected by these factors, it's not a good idea to use it to measure the time that has elapsed between two events.

Using wall clock time in programming can cause weird bugs where your programs might be thinking a certain duration of time has passed, when in reality, it's been longer or shorter. One major assumptions people make is that "Time difference cannot be negative". Going back to our reason why we need to keep track of the two types of time, we can see why this might be the case. Assuming we have two times, t1 and t2, and we want to find the difference between them, we can do so by subtracting t1 from t2. Should time t1 be before time t2, the result will be negative, which breaks our assumption. Time t1 can always be before time t2 because we learnt that wall clock time can be affected by the user's manual adjustments to the clock, daylight saving time, and other factors like network time changes.

Time difference being negative actually caused a big issue one time for Cloudflare DNS.

In 2017, Cloudflare experienced a significant outage during a leap second adjustment. Their RRDNS software compared timestamps before and after the leap second was inserted, resulting in negative time differences. This violated the code's assumptions and caused the software to crash repeatedly. You can read more about it here

When dealing with time, you should never ever think that time difference cannot be negative, never think that time cannot go backwards. Having these ideas in your mind will help you build programs that are more robust and reliable. Wall clock time is suitable for displaying time to users and scheduling based on the time of day, but it's inappropriate for measuring elapsed time due to its susceptibility to adjustments. Monotonic time, with its steady forward progression, is the correct choice for duration measurements, timeouts, and performance profiling.

A 5-Step Approach to Problem Solving (DSA)

Kelvin Amoaba — Sat, 18 Nov 2023 07:00:49 +0000

When starting to practice the data structures and algorithms you've learned on platforms such as Leetcode, Codewars or Hackerrank, you can go from being pretty excited to pretty down in a matter of few minutes behind a problem.

I encountered this a lot. It makes you start to question a whole lot of things, from whether it's your brain that cannot process much to whether you are not built for this field and a whole lot of other things.

But then, after spending some time questioning my skills and going back and forth between problems, it turned out that I was not really doing some things right from the onset and that had to do with the way I approached the problems I tried to solve.

In this article, I will try and explain why certain things should be avoided or embraced as I go over the 5 steps I used to improve at solving these problems.

1. Understand the question, like seriously, take time to understand the problem

So for me, one major mistake I made immediately starting to think about concepts to solve the problem as I read the problem. I believe this was the main ingredient in preventing me from solving these problems correctly. The reason why this is an issue is that you do not get to really get into the ins and outs of the question before you start thinking about implementation.

Note that, understanding the question is also part of the answer.

One time, I rushed into writing code for a problem when I had not even finished reading the problem and instead of returning an array of integers from the function, I was returning a single integer 🤦‍♂️. As you can tell, after countless times questioning why I was failing the test cases, it was going back to really read the problem that made me finally pass them.

As simple as a problem might be from the introductory sentences, please and please refrain from shifting focus to finding the right algorithm or data structure to use. Just take time to read and digest, before doing anything else.

2. Pseudocodes and Paper Solutions Still Rock

The second thing was that I jumped into coding real quick after lazily skimming through the question. This is the biggest mistake you can ever make, once you don't understand how something should work really well or the type of inputs your function will take, you know that you are definitely doomed and you cannot really do anything tangible.

Even if you understand the problem, you should not start with coding from your computer, just try and write some pseudocode on a piece of paper or notebook you have beside you or just say your thought processes out aloud (after all, you'll do this in a real interview). This is really going to improve your overall understanding of the problem and you might catch all the edge cases that come with the problem.

With your plan in place, it's just a matter of transcribing them into code using the correct syntax. Easy Peezy :)

3. Avoid Premature Optimization at all Costs

To add to my already existing stack of wrong approaches, I was also trying to code out the perfect algorithm from the start (Premature Optimization).

Premature Optimization: Trying to improve something especially with the goal of perfecting it when it's too early to do so.

When you start writing the solution to a problem and you start thinking in this way, it becomes a big issue. So rather than moving from the ground up, you try to hit the jackpot on the first try. Everyone knows that this is rarely even the case in casinos.

The best way to start solving a problem is to start off with the most basic and unoptimized approach, what we usually call the "Brute Force" solution, and slowly work your way up because, at this point, you have something that solves the problem but is inefficient that you just have to transform into an efficient solution. This is in contrast to you trying to optimize something you have not even written.

4. It takes time to get things right

Like it was or is in some of your university classes, it is not all the time you get a problem right on the first spot. It takes time and practice to become good at something. Don't get the wrong feeling for failing all the test cases, that is how we end up learning. As you fail these problems, you should spend some time trying to figure out what really went wrong rather than jumping into viewing the solutions that have been posted by other users. I found myself doing that and that really did not make me any better. It is much better to struggle a little bit more, if you still do not get it, you can go on and use the hints from the problem and also, log as much as possible, it is very important to know what is going on at each point in your code.

5. Compare and Contrast

One of the best feelings you can get is the satisfaction of being able to solve a problem correctly. You get really excited and happy, feeling on top of the world, cool right? One thing though is that you should not jump on to the next problem but then, try to always view solutions posted by other developers on the problem. Look, you will really learn a lot by going through it.

This is really something I use to my advantage and I learn a lot of handy handy functions, methods and even parameters to some functions.

This will also make you see the thought process of others and get a complete overview of the problem from other points of view.

To Conclude

I can assure you that fully utilizing this thought process is going to really improve how well you do in solving problems relating to DSA and programming in general. Also, do note that although it will be great to jump into practising problems on algorithms, you should make sure you have really learnt enough and mastered some very necessary foundational algorithms and data structures as these are mostly what other algorithms are based on and problems require you to understand.

All the best in your journey 🎊

Deep Dive into Stacks: A Practical Guide for Software Engineers

Kelvin Amoaba — Thu, 09 Nov 2023 20:08:47 +0000

What is a Stack?

A stack is a very important data structure that is used to work on data temporarily.
Unlike other data structures that are built into a language, a stack is rather a layer added to an existing data structure, such as an array or linked list. In this tutorial, however, we will focus on the array-based implementation of a stack.

So just like arrays, the data added to a stack is stored in contiguous memory. The main difference between a stack and an array is how operations on data are performed. A stack behaves differently from an array due to a set of rules that are added to the behavior of the array.

Data structures that are built on top of rules from other data structures are called abstract data types. Another type of abstract data type is the queue, which we will discuss in another post.

The stack data structure is a very important data structure used in various areas of computer science, like recursion. A stack helps to implement various things. The undo and redo functionalities of your IDE are based on a stack; your browser navigation, forward and back, is also based on a stack.

How does it differ from an array?

The following rules differentiate how a stack operates from how an array operates.

You can only add to the end of the stack
You can only read from the end of the stack
You can only delete from the end of the stack

In a typical array, one can insert data into any index they want, but in a stack, that is prohibited. If this rule is broken, then it is no longer a stack but something else. (#1)

Reading from a typical array does not restrict where in the array you read from. You can read from the beginning of the array, the middle, or the end, wherever you want to read from. But then, in a stack, it is mandatory to only read from the end of the stack.

The third rule states that you can only delete from the end of the stack. This is a very different behavior from a normal array because, in an array, one can delete at any index they want.

It should be noted that these rules are not pre-written in most languages but are implemented when the stack data structure is built. It is typically not a built-in structure but rather something that the programmer explicitly creates.

The end of the stack is referred to as the top. This is because we look at the stack not like a horizontal array but as a vertical array.

Scenario

You can think of a stack data structure as stones placed on top of each other, like in the preview picture above. To add another stone, you place it on top of the already existing stones, not below or in the middle (Rule #1)

If the stones were colored and you want to see (read) the color of the most recent one, you will obviously look down at the stones. The latest one simply refers to the one you just added to the stack. (Rule #2)

Also, to remove a stone, you would have to remove the one from the top first, as this is the only logical way to go about it if you don't want your stone empire to come crumbling down (Rule #3)

This behaviour of the stack is referred to as the LIFO This is an acronym for Last In, First Out. This basically means that the first thing you add to the array is the last thing that comes out.

Operations Performed on a Stack

The operations performed on a stack are:

Reading, aka "Peeking"
Adding, aka "Pushing to the stack"
Removing, aka "Popping from the Stack"

Implementation of a Stack in Python

class Stack:
    def __init__(self):
        self.data = []

    def push(self, value):
        self.data.append(value)
        return len(self.data) - 1 # return the index of the item

    def peek(self):
        # Return the last value if the data array is not empty else
        # return None
        return self.data[-1] if len(self.data) > 0 else None

    def remove(self):
        # Here too when the user tries removing the last item, return
        # it if there are elements in the array else return None
        return self.data.pop() if len(self.data) > 0 else None

Code Explanation

We define the Stack class; as previously stated, the stack is a data structure that you create and does not come pre-built in most programming languages.

In the __init__ method, we create an empty array and attach it to the object. As you can see here, the stack we are implementing is based on the array data structure.

Next, we define the push method, the push method is responsible for inserting a new value onto a stack. This is accomplished by invoking the append method and passing in the user-supplied value. The append method adds to the end of the list, which is referred to as the TOP in a stack. The index of the last item is then returned.

Next, we define the peek method, the peek method simply returns the last item in the array if there are items in it; otherwise, it returns None.

The remove method is next. Here, we return the last item in the array. This is done by calling the pop() method on a list. This will remove the last item in the list and return it.

Let's quickly go through an example of this implementation.

s1 = Stack()
s1.push(1) # This adds 1 to the stack
print(s1.peek()) # This prints out 1, since it's the item at the top
s1.push(2)
s1.push(3)
print(s1.peek()) # This prints out 3, since it's the latest item at the top

s1.remove()
print(s1.peek()) # this prints 2 since 3 has been removed from the stack

Walkthrough

As you can see from above, the LIFO behavior is working in full effect. The first item added will be the last item to leave.

Real-world use cases

Browser Forward and Back Navigation
Web browsers implement forward and back navigation using two stacks: the undo stack and the redo stack. As the user navigates between pages, the current URL is pushed onto the undo stack. Pressing the back button pops the URL from the undo stack and pushes it onto the redo stack, allowing the user to move backward and forward through their browsing history. This dual-stack system ensures efficient navigation between visited pages. This is a very simple breakdown; a lot gets built on this, though :D
Function Call Management:
In programming, a call stack is a stack data structure that controls a function call. When a function is called, its parameters, local variables, and return address are pushed onto the call stack. As functions complete execution, they are deleted from the stack, returning the program to the previous execution context. This is mostly used in recursive programming.
Solving Algorithmic Problems
Several problems you will encounter will require some comprehension of stacks in order to solve them efficiently. Some include:
- First-depth search problem
- Reversing items in a list or string

Understanding Python Functions

Kelvin Amoaba — Wed, 25 Oct 2023 20:52:25 +0000

Well, let's dive straight into it.

Functions are blocks of code written to perform a particular task. Well, this definition is quite simple and straightforward. This simply means, your functions should do only one thing.

Defining Functions In Python

To create a function, python provides a special keyword, def. This keyword is used in combination with a user defined name you give to the function. Let's take a look

def name_of_function():
   # function block

Every function should have a name, but not every name is allowed because some are reserved by Python itself.

Inside the function block is where you write what the function should do when called.

Parameters

When writing a function, you can define parameters that you want the function to take in.

A parameter is used to represent data you want as input to the function

Parameters are defined inside the parenthesis in the function definition.

Example, let's say you want to write a function that adds two numbers, we will name the function, add.

def add(a, b):
    print(a + b)

In the above example, the function add has two parameters, a and b which we are using to represent the two numbers we will pass in.

Calling Functions

Once a function is written, then it must be used somewhere. I mean, I'm not sure you will write a function without the intention of using it 😅

To use a function, you call the function with its name.

def add(a, b):
    print(a + b)

add(2, 4)

From the above example, we called the function with it's name and passed in the parameters it requires.
Suppose the function had no parameters, you will just call it with its name and the brackets. add()

Parameters and Arguments - Revisited

In the above section, I explained what parameters are. Reiterating, a parameter is used to represent data you want to pass as input to a function.

When calling a function that has some parameters, the actual values you pass in to that function are called the Arguments.

Let's go over the example again

def add(a, b):
    print(a + b)

add(2, 4)

When we were defining the functions, we passed a, b inside the brackets, those are called the function parameters.

The real/actual values we pass to the function when calling it are what we call the arguments. In our "add" example, "2" and "4" are the arguments.

Arguments are also called "Actual Parameters" and the parameters specified in the function definition are called "Formal Parameters"

Parameters are specified in the function definition and arguments are the values passed into the function when calling it

Types of Functions

There are two types of functions in Python:

User-Defined Functions: These are the functions you create, like the "add" function we defined. You choose the name and define what it does.
Built-In Functions: Python comes with a collection of pre-made functions that perform common tasks. These are functions like print(), len(), and input(), which are available for you to use without defining them yourself. Built-in functions save you time and effort, as they are already part of the Python language.

To conclude, functions are really powerful and understanding it will really be important in your programming journey.
Here are some importance of functions:

Improving code reusability: Once a function is defined, it can be used over and over and over again.
Code Organisation: It helps to divide the large programs into small groups to read the code and debug it faster and better.
Functions can be shared and used by other programmers.

Safeguarding Critical Keys

Kelvin Amoaba — Wed, 09 Aug 2023 03:03:01 +0000

These days, almost any service you interact with through an API will require some sought of permissions to be able to use it. These permissions are done through the use of what is known as API keys, which is a sequence of some characters. These act like the username and password you use when logging in to any website and we all know how much we would not want to share those credentials with others. That is how we have to treat these keys as well, because when they get into the wrong hands, they can be used to perpetuate acts you have not yet prepared for. Some might include:

Unauthorized Data Access: A malicious actor could misuse stolen API keys to gain unauthorized access to sensitive data.
Resource Overuse: An attacker might use compromised keys to overload a service, causing downtime or additional costs.

Securing API Keys: Best Practices

To bolster the security of API keys, a fundamental approach is to leverage Environment Variables within your source code. Environment variables are external to your program and should never appear explicitly in your codebase. As the name suggest, they are variables, and we all know variables store values. But then, when you reference the variable, you get the value in place of it, and this value, you might not be aware of. When you reference an environment variable, you retrieve its value, which remains concealed from your code. These variables are typically configured at the system level and can be accessed by the executing program. A typical way of getting environment variables in python is using the os module.


import os

secret_key = os.environ.get("HIGHLY_IMPORTANT_SECRET")

The actual value of secret_key isn't known until runtime, and it can vary based on the environment, enhancing security by keeping sensitive information hidden.

Embracing Security Audits

As we grow in the field on engineering and software building, we should not only take into consideration that because a code is running, it is okay to be pushed to the general public. As engineers, we also need to sit down, analyze typical bugs we might have present and also, the security of the code we have written. Rushing to deploy features might lead to exposing private information unintentionally. For instance, directly embedding an API key without proper handling can be a security risk. An example will be you passing an API key directly into a variable without using a method like we discussed about, due to the rush to get things done.

We must learn to add to the pipeline before deploying, the need to sit down and perform some auditing before going ahead to push out our changes. These days, any slight loophole an attacker gets within your system, they tend to really do great dame with it.

Libraries we use in our codes can also contribute to the overall security weakness of our application. We should really try as much as possible to stay away from packages or libraries that have not been maintained in a really long time. While the advice against reinventing the wheel is well-known, choosing a package that hasn't been updated in five years might end up causing more harm than spending a bit of time to create it yourself.

For code checks and auditing, there are various 3rd party services that we can use, some even, directly within our IDEs. By integrating these tools, you can identify and mitigate security concerns before they become real threats.. I will leave some links below so you check them out.

In conclusion, safeguarding API keys and fortifying your application against security risks are paramount. Employing environment variables, conducting thorough security audits, and leveraging third-party tools all contribute to maintaining a robust and secure software ecosystem.

@mentions Notifications Design

Kelvin Amoaba — Fri, 05 May 2023 00:32:31 +0000

So we have all used platforms where we receive notifications whenever we are mentioned in a post or a comment. These notifications are to keep us engaged in conversations.

I am going to be explaining at the high level how to build out a simple @mentions notifications feature in any system. Note that this post is only giving you a fair idea about how to go about the whole implementation and not showing you how to actually do it in code.

Steps

Receive the incoming post / comment text from your UI, this data could be from an endpoint that your frontend sends posts requests to.
Once this data is retrieved, you would need to parse the content of the post to find every instance of an @mention. This can be done by by using regular expressions. An example is given by r'(^|\s)@(\w+)', this would match all mentions like @someone and not weird cases like some@One.
Note that, you would have to store every mention in some form of data structure to be referenced later, probably storing it in an array.
Next, you would have to filter the mentions to see if they are actually present in your users table. If not, you eliminate them from the final list of users to send the notifications to.
Finally, you can pass these users to the notification service to then send the notifications via your favorite channel, either In-app, email or other media.

Final Takeaway

Note that, if the above steps are done in the request-response cycle, it will not be very convenient as your users will be waiting for all these steps to complete before you send back a response to them. To overcome that, you can use tools such as Redis or RabbitMQ as a message broker and Celery to perform these steps in the background.

That's it, a high level overview of the implementation. Let me know if you have any questions in the comments.
Cheers 🥂

Creating a Custom Authentication Backend In Django

Kelvin Amoaba — Wed, 22 Jun 2022 00:08:09 +0000

You may have noticed that the built in authentication system in Django has quite some few limitations. For example, it only allows your website's users to only log in using their username and password. But in modern day websites, you might want to enable your users to be able to log in to your site using either their username or email address. If your website is for a company, you can even implement an authentication backend to make users log in using lets say a secret key.

What is an authentication backend in django?
An authentication backend is a python class which provides two methods for authenticating a user and also retrieving a user.

To implement a custom authentication backend, you need to define a python class with two(2) methods. One for retrieving a user and the other for authenticating a user. The two methods are, get_user() and authenticate() respectively.

The authenticate() method takes in a request object and the user credentials as parameters. It then returns a user object that matches the given credentials, if they are valid. It returns None if the credentials are not valid.
get_user() method takes a user ID as a parameter and has to return a user.

In this tutorial, we are going to create a new authentication backend to allow users login using their email addresses also.

NOTE: THIS TUTORIAL ASSUMES YOU HAVE ALREADY CONFIGURED A VIRTUAL ENVIRONMENT AND ALSO CREATED A NEW DJANGO PROJECT.

Let's create a new django application called account by running the command in your project root directory.:



python manage.py startapp account

Add account to your installed applications.

The account app should have the following directory structure.

Next, create a new file called authentication.py in the account app.
In authentication.py, we add the following code:



from django.contrib.auth.models import User
class EmailAuthBackend:
    """
    Custom authentication backend.

    Allows users to log in using their email address.
    """

    def authenticate(self, request, username=None, password=None):
        """
        Overrides the authenticate method to allow users to log in using their email address.
        """
        try:
            user = User.objects.get(email=username)
            if user.check_password(password):
                return user
            return None
        except User.DoesNotExist:
            return None

    def get_user(self, user_id):
        """
        Overrides the get_user method to allow users to log in using their email address.
        """
        try:
            return User.objects.get(pk=user_id)
        except User.DoesNotExist:
            return None

Remember, the authenticate() method will be used to authenticate your users, and will be called when you call the authenticate() method in your view.
In the authenticate() method above, we are having the parameters request, username and password. The entered email address will be found in the username parameter and the password in the password parameter.

We are using a try, except block because, fetching a user that does not exist will raise a DoesNotExist error.
We retrieve a user with the incoming email address, note that the email address must be set to unique=True otherwise a MultipleObjectsReturned error will be raised if more than one user has the same email address. This can be done by creating a custom user model. If you're not familier with a custom user model, let me know in the comments.

Next, we're using the method, user.check_password(). This will take the password argument, hash it and then compare it with the hashed password in the database. If there is a match, it will return True, else False.
In our case, if the result is True, we return the user, else we return None.
Also, if there is no user in the database with that email address, in that case a user.DoesNotExist error will be raised. If there's no user, we return None.

The get_user() method takes a user_id as an argument. It returns the user if it exists or else it returns None.

Thats it, we are done with our custom authentication backend. Phew.
But now, users will still not be able to log in using their email address. This is because, we have not told django to add our authentication backend to the list of authentication backends available. To do that we need to edit our settings.py file.
Add the following to it.



AUTHENTICATION_BACKENDS = [
    'django.contrib.auth.backends.ModelBackend', # This is the default that allows us to log in via username
    'account.authentication.EmailAuthBackend'
]

Now, django is aware of our authentication backend.

But how does django apply our authentication backend?
When we call the authenticate() method from django.contrib.auth in our view, django authenticates the user agains each of the authentication backend specified in the AUTHENTICATION_BACKENDSsetting. In other words, it calls the authenticate method of each of the authentication backends specified.
Django will stop at the first backend that authenticates successfully.

Go ahead and run your development server and try out your new authentication method.
You can extend this to authenticate against whatever you wish.

Thanks for reading. If you have any questions, please let me know in the comments section. And also, dont forget to follow for more tutorials.
If you would like to request for a tutorial, let me know. Thanks and happy coding.

Speeding up Django Project Setup

Kelvin Amoaba — Fri, 20 May 2022 14:36:32 +0000

Since I’ve started to work on a lot of Django projects lately.
I realized I was spending much time working on the configurations of the project. Such as creating a new virtual environment for each project, installing prerequisites and the likes. This shifted the time needed to build the project to rather configuring it.
Working on a Linux machine, I decided to create a little bash script that can automate the process right from creating a new project to setting up the directory structure for the project and installing dependencies.
Here’s a link to the project for those who might be interested.

https://github.com/AmoabaKelvin/django-starter/tree/v0.1.0

If you have some time to spear kindly go through it and tell me ways I can improve it.
If you would like to contribute, I’ll be very glad.
Also don’t forget to leave a star☺️