DEV Community: Nick

Integrate Google OAuth2 Social Authentication into your Django Web App

Nick — Wed, 18 Sep 2024 11:25:40 +0000

Introduction

Many modern web apps are using social authentication methods as an authentication option. Social authentication involves using third party apps, usually social media apps or Google, as a sign up or login option. The use of third-party apps such as Google, Facebook, Twitter/X, or Github to authenticate users improves user experience. Users do not have to go through the long and tedious process of manually creating an account. As a result, authentication is fast and effortless.

Moreover, on the business side, authenticating with trusted third parties significantly buffers a web app’s security. Facebook, X, and Google have rigorous authentication processes themselves. If a prospective user account is deemed as "not malicious" by Google, then the account most likely poses a lower security risk for your app.

This article walks Django developers through the process of adding Google social sign in as a login option to their authentication flow. Let us dig in.

Prerequisites

A beginner-level understanding of Django web framework.
A VS Code editor installed.

Building your Project

Getting Started

We are going to create a sample Django project with which to integrate Google social authentication. Proceed to open your VS Code editor then create a directory called Google-OAuth2, which will host your entire application code.

If you already have a project and only need to start integrating Google social authentication, jump to here.

Setting up your Development Environment.

You need to create a Python virtual environment to isolate and install software dependencies you will need for this project. We obviously need to install the Django framework itself. Then we will install a package known as django-allauth. django-allauth is a Django project, available on Github. The project contains all the necessary routes (URLs), logic (views) and rendering mechanisms (HTML templates) that facilitate social login with major third parties such as Google, Twitter and Facebook. You can check out the project for a deeper understanding.

Open a new VS code terminal and ensure you are inside your project directory. Create a Python virtual environment using the venv python module like this:


 -m venv venv

info: The first venv command line argument is the Python virtual environment module while the second venv argument is a custom name you give as an identifier of your virtual environment. You could name your virtual environment anything you want—env, myenv, env1, my_env, etc.

After the Python interpreter has successfully created a virtual environment for you, you should see a new directory named as the custom name of your virtual environment inside your Google-OAuth2 folder. Now activate the virtual environment by running the command venv\Scripts\activate. You should see your virtual environment name, enclosed by parentheses, preceding your terminal’s command prompt:


 users\user\Desktop\Google-OAuth2:

Perfect. Now install django and django-allauth inside the environment using pip.



pip install django django-allauth

Warning: You can install several packages using one pip command like above. However, it is best practice to install a package at a time. If one fails to install, it is easier to pin-point which package failed.

Now we Build

Inside your root directory, create a Django project like this:


 startproject core .

Django will create a new directory called core in the current working directory.

warning: Remember to include the period at the end. Otherwise, Django will create a project directory called core within another directory with the same name.

Next, create an application called authentication:


 manage.py startapp authentication

The above command invocation will create an app directory called authentication at the same level as your project directory core. Proceed to include your new application in the list of INSTALLED_APPS section of the newly created settings.py file:



# core/settings.py
INSTALLED_APPS =  [
    ...
    'authentication',
    ...
]

Create a User Data Model

Next, you need to create a user data model that defines how your application will store user information.

Think about the utility of the application you are creating for a minute. Why are you integrating Google social authentication in the first place? You want to extend the built-in user model by allowing a user to log in using their email instead of a username. Remember that social authentication is usually built on top of the traditional Django authentication system. For the traditional authentication, a user registers with a username, email (optional), and password as primary credentials. Therefore, your user data model should have all these fields.

Django ships with a built-in user model, a Python class object, called User. The model has the three primary fields above in addition to other fields. You can extend the User model by creating your own custom fields and methods to suit your unique project needs.

For instance, the default username field in the built-in model requires a username. You may override this condition if you want your users to use email addresses as their usernames instead, as we will do in this project.

To include extra custom fields, your User class object should inherit from another Django class object called AbstractUser. This superclass allows you to include custom fields and customize the default fields.

With this information in mind, edit your authentication/models.py file like this:



# authentication/models.py
from django.db import models
from django.contrib.auth.models import AbstractUser

class CustomUser(AbstractUser):
    username = models.CharField(max_length=100)
    email = models.EmailField(max_length=100)
    password = models.CharField(max_length=100)

    USERNAME_FIELD = 'email'
    REQUIRED_FIELDS = ['username']

Our custom user model extends the built-in AbstractUser model. Even though username, email and password fields exist in the built-in model, you explicitly redefine them here to customize the allowable lengths for the username, email, and password strings you want to accept from the user during registration.

Furthermore, you override the default username field to use an email instead of a username.

Next, to use your custom user model, you need to register your model in settings.py file. Head over to core/setttings.py and add this line:



# Custom user model
AUTH_USER_MODEL = 'authentication.CustomUser'

Note: This directive overrides the default User by stating the path to the custom model, which is in the authentication app.

Next, you need to initialize and apply a database schema to an SQLite database that ships with Django. Run the following two commands in your VS Code terminal:



Python manage.py makemigrations
Python manage.py migrate

Proceed to register your custom user model with the admin so you can access and edit your database entries as admin:



# authentication/admin.py
from django.contrib import admin
from django.contrib.auth import get_user_model

CustomUser = get_user_model()

admin.site.register(CustomUser)

Finally, using a VS Code terminal, create a superuser account that can access the admin dashboard:



python manage.py createsuperuser

Run a development server:



python manage.py runserver

A local development server will start on port 8000. Visit http://127.0.0.1:8000/admin to log into the admin panel. You should see your model under Models. You can create a few user entries for testing purposes.

Integrate Google OAuth2

Time to bring in the big guns. As you have already installed the django-allauth dependency, let’s proceed to configure our backend to support authentication with Google.

django-allauth is a django project similar to the one you're building here, with several apps. You therefore need to register the required django-alluth apps in your INSTALLED_APPS section.

Add the following django-alluth apps to the section. You could label the apps as "allauth apps" to distinguish them from other installed apps:



INSTALLED_APPS = [
    …
    #allauth apps
    'allauth',
    'allauth.account',
    'allauth.socialaccount',
    'alluth.socialaccount.providers.google',
    …

Next, you need to update the middleware settings under the MIDDLEWARE section. Insert this middleware at the bottom of the middleware list:



MIDDLEWARE = [
    ...
    'allauth.account.middleware.AccountMiddleware',
]

Next, you need to configure AUTHENTICATION_BACKENDS. When you issue this directive in the settings.py, you are providing a way for your project to handle the authentication credentials passed into sign up and login endpoints.

Now, by default, Django uses ModelBackend to parse authentication credentials, i.e., it verifies your sign up or login schema against the built-in or custom user model.

Note: When you initialize a Django project, the AUTHENTICATION_BACKENDS directive is not explicitly stated. (You will not see this directive when you open your settings.py file). Nonetheless, it's default value is ModelBackend. If you do not need to use any other authentication backend, it is needless to explicitly state this directive. Django will use the ModelBackend.

django-allauth relies on its own authentication backend that extends the default. Therefore, you need to provide an additional authentication backend to cater to allauth authentication. Hence, you must explicitly state the AUTHENTICATION_BACKENDS directive. Add the following setting:



AUTHENTICATION_BACKENDS = [
    # Needed to login by username in Django admin, regardless of `allauth`
    'django.contrib.auth.backends.ModelBackend',

    # `allauth` specific authentication methods, such as login by email
    'allauth.account.auth_backends.AuthenticationBackend',
]

Next, add social provider settings:



SOCIALACCOUNT_PROVIDERS = {
    'google': {
        'SCOPE': [
            'profile',
            'email',
        ],
        'AUTH_PARAMS': {
            'access_type': 'online',
        },
        'OAUTH_PKCE_ENABLED': True,
    }
}

Notice that the above are Google provider specific settings. allauth provides similar settings for tons of other third-party authentication providers. See a full list here.

And finally for settings.py, add these extra allauth email account configurations:



# Django allauth config
SITE_ID = 1
ACCOUNT_EMAIL_VERIFICATION = 'mandatory'
ACCOUNT_EMAIL_REQUIRED = True
ACCOUNT_AUTHENTICATION_METHOD = 'email'

Include allauth URLs

django-allauth ships with its URLs. You can use or override the URLs in your project. For this project, you will be using some of these default URLs. More specifically, you will utilize the URL that allows for login with Google, You can visit the documentation for more information.

In your project level urls.py file add this code:



# core/urls.py
from django.urls import path, include
from django.contrib import admin

urlpatterns = [
    path('admin/', include('admin.site.urls')),
    path('accounts/', include('allauth.urls')),
]

You are all set to use django allauth's URLs.

Set up an App in Google Developer Console

You need to set up an app in Google Console to enable users of your application authenticate with Google. The process involves two steps:

Configuring an OAuth consent screen
Setting up Credentials

OAuth consent screen

Visit Google developer console.
Create a new project with a suitable name from the dropdown menu.
Select to use the project you have just created from the dropdown menu.
In the displayed window, select OAuth consent screen and select the External option, then hit Create.
Fill in only the App information and Developer information details under Oauth2 consent screen.
Click on Save and continue.
Click on Save and continue button for both Scopes and Test users forms without filling in anything.
Confirm your Oauth2 details in the Summary section then click on Back to dashboard.

Set up Credentials

Locate Credentials under APIs and Services
Click on Create Credentials and select OAuth Client ID from the dropdown options.
Select Web application for the Application type field. You could use the default name under the Name field or provide a suitable name.
Select ADD URI under Authorized JavaScript Origins to add a Uniform Resource Identifier (URI).

Info: Adding a URI ensures only permitted domains can send requests to your OAuth2 app from a browser. Since you will be testing your Django app in development, add this local host URI:
http://127.0.0.1:8000
Select ADD URI under Authorized Redirect URIs and add the following URI:
http://127.0.0.1:8000/google/login/callback/

Info:This is the callback URL where Google will redirect to after a user grants or denies your application permission to authenticate with their Google account.
Hit the Create button and wait for a few seconds for your app to be ready. Your new app will generate a Client ID and Client secret. In the resulting window, download the JSON for these details or copy and paste the Client ID and Client secret somewhere. You will need these details in a few.

Set up a Social Account Provider

Next, you need to set up a Social Account with the client ID and secret you generated earlier in your admin console. Login in to the admin via http://127.0.0.1/8000/admin and locate the SOCIAL ACCOUNTS section. Under this section, click on SOCIAL APPLICATIONS then select ADD SOCIAL APPLICATION.

Under Provider, if you click on the dropdown icon, you will notice that Google is already available as a provider. This is because we already configured Google as a provider in our settings.py file, when we added this line:



# core/settings.py
INSTALLED_APPS = [
            ...
'alluth.socialaccount.providers.google',
]

Just to test it out, you could try commenting out this line and refreshing your current admin view. Google will disappear under providers.

Back to adding a social application, uncomment the above code if you commented it out. Select Google under provider and provide a suitable name for the Name field. For this purpose, call your social application Google.

Next, under Client id, paste the Client ID from Google console. Similarly, paste your Google console's secret key under Secret key. Finally, click on Save to save your social application credentials.

Everything is now set.

Testing and Troubleshooting

Now visit http://127.0.0.1:8000/accounts/google/login.

Try logging in via the Google third party.

django-allauth will hand over the authentication process to Google. Google will use the app you configured in the console to carry out the authentication for the Google account you select. Google will then return a response to your allauth app via the callback URL you provided in Google console's Authorized Redirect URIs section. Allauth will then handle the rest of the authentication flow from here.

If you had issued a LOGIN_REDIRECT_URL directive in your settings.py file, allauth will redirect the user to the URL provided for login redirect. For instance, you could create a home page and pass its URL as the LOGIN_REDIRECT_URL. Your app will redirect all successfully logged in users to your home page.

Conclusion

This tutorial walks the reader through the process of integrating social authentication into a Django web application using Google. The process involves defining a suitable user data model, configuring allauth in your Django app, and setting up an app in Google console, pointing it to your Django app. Finally you need to test the authentication flow. You can extend this application by integrating other third party authentication flows such Facebook, X, or Github using the django-allauth package. Hope this helps. Happy coding!

How to Deploy your FastAPI Backend with PostgreSQL Database to Render

Nick — Wed, 19 Jun 2024 13:54:16 +0000

Introduction

FastAPI is a popular Python backend web development framework. Many Python developers use FastAPI to built Application Programming Interfaces (APIs) and connect other backend infrastructure such as databases. FastAPI is suitable for API design for several reasons:

APIs built using FastAPI are fast in terms of performance.
FastAPI framework is simple to learn.
FastAPI comes with a built-in API documentation feature that saves the developer the time needed to manually document APIs.
FastAPI is generally optimized for API design.

This tutorial walks Python developers through the process of hosting APIs built using FastAPI to the Render cloud hosting service, and connecting a PostgreSQL database. The article assumes you have your FastAPI backend ready for deployment. However, I will walk you through the deployment checks involved to get your code ready, so you can apply the checks you might have missed. Let's go!

Prerequisites

A FastAPI backend
A registered Render account

Pre-Deployment

Deployment Checks

Assuming you have written the logic for all your APIs and have tested that everything is working as expected, there are five steps extra steps we are going to take to ascertain that our backend is ready for production:

1. Create a requirements.txt file

You obviously installed software packages to build your APIs inside your Python virtual environment. Among the packages is the FastAPI framework itself and all its dependencies. We will need to install the same packages to run our code in production. We need to pass to the Render build process a list of dependencies for our project.

In your local environment, create a file named requirements.txt. You could name it anything, but naming it as above is a standard convention. Next, run pip freeze > requirements.txt in your terminal. The command gathers the names of all the software dependencies and their version numbers from your virtual environment, and outputs the information in the requirements.txt file

2. Create a .env file

Next you need to hide any sensitive information in your codebase before you push your code to Github. In most cases, the sensitive information in most Python projects is your project's secret keys, database URL connection string, and database name, username and password. You could include database port and host if you deem them sensitive enough to be hidden.

Proceed to create a hidden file called .env. Do not forget the period at the beginning. Edit the file by providing key-value pairs of the secret information like this:

DATABASE_PORT=5432
DATABASE_NAME=fastapi
DATABASE_USERNAME=postgres
DATABASE_PASSWORD=testpass123
SECRET_KEY=123456HDUDCDHCHDUCDNCNDNCR

Remember to replace the environment variables values with your actual values.

3. Create a .gitignore file

This steps precedes pushing your code to Github and it involves instructing git to ignore directories and files you do not want checked into Github. By default, when you initialize a git repository as we will do in a moment, git tracks all files in the entire directory. We do not want version control to track the .env file. In addition, we do not want to check our virtual environment folder or the pycache directory into Github. This is because we can easily recreate our virtual environment. Furthermore, we do not want to pollute our Github repository with code we do not need, such as pycache files and virtual environment packages.

Untrack unnecessary files by editing the .gitignore file like this:

__pycache__/
venv/ # Use your virtual environment's name
.env

4. Create a build.sh file

This step involves creating a bash file called build.sh that will store our pre-deploy commands. We will run this file shortly when we host our code on Render.

Let's talk about pre-deploy commands. These are commands that should run before you start your production server. Most often, these are commands that set up your production database. They may involve commands that set up your database schema and tables and run database migrations. Additionally, you can run pre-deploy commands to upload your static files to a Content Delivery Network (CDN).

In most cases, with FastAPI and other Python frameworks such as Django, pre-deploy commands involve running database migrations to create schema and tables. Django, in particular, auto-generates migration files every time you make changes to your database. Therefore, with Django, you almost always have to write only these two database migration commands in your build.sh file:

python manage.py makemigrations
python manage.py migrate

However, FastAPI does not create any migration files when you make changes to your database. For a serious project, you usually have
to integrate a database migration tool like Alembic, which tracks changes to your database schema. If you integrated Alembic into your FastAPI backend, first write this database migration command in build.sh to set up your schema:

alembic upgrade head

However if you did not integrate any database migration tool, you typically wouldn't have to run pre-deploy commands on Render.
Assuming you do not need to make database migrations for your FastAPI, our build.sh file will contain only one command; the command to start our production server. Input the following command in your build.sh file:

uvicorn main:app --host 0.0.0.0 --port $PORT

Note

FastAPI ships with the uvicorn server by default. The above command presumes that the entry point to your backend, the main.py file, is located at the root directory of your project. If the file were located in some sub-directory, you would have to provide the relative path to the file, i.e relative path to the root directory

Also, take note of the host IP. The IP is set to the 0.0.0.0 address, which is a special network interface that accepts connections from all IPs. The port option specifies an environment variable PORT. Using an environment variable instead of hard-coding a specific port number is considered best practice. The hosting service build process will assign us a random port during the build. You could hard-code a port, say 5000 or 10000 and hope the port is not occupied by another process during the build.

5. Initialize a Github repository and push your code to Github

Go to your Github account, create a new public repository and copy the repository's URL. Back in your command line, enter these prompts, in order,
at the root of your project folder

git init # Initializes a local git repository
git add --all
git commit -m 'FastAPI backend' # Commit message could be anything you want
git branch -M main # Sets up a branch called 'main' on Github
git remote add origin [Your repository URL] # Sets up a remote repository on Github
git push origin main # Pushes all your code to the main branch of your Github repository.

All your code is now hosted on Github

Deployment

Set up a PostgreSQL Database on Render

Follow these steps to spin up a free PostgreSQL database on Render:

Login into your Render account. You will be redirected to your dashboard.
Click on new and select PostgreSQL from the dropdown menu.
Fill in the Database, Name and User fields with the database credentials you want to use.
Scroll down to Instance Type and select free instance. You can select a paid instance for an enterprise-level project.
Hit Create Database at the bottom of the page and wait for Render to create a new PostgreSQL database instance for you. Render will redirect you to a page with information about the newly created database.
Copy the generated Database Password and Database Internal URL somewhere. Note that we are using Internal URL and not external URL because both our service and database are hosted within the same server. Connecting using the internal URL speeds up the connection process and reduces latency.

Create a Web Service

Click on new again, and select Web Service from the dropdown.
Choose Build and deploy from a Git repository and press next. Render will connect to your Github and avail all your public repositories. Connect your FastAPI repository.
Fill in details about your web service in the resulting page:
1. Input a suitable unique name for your service under Name field
2. Scroll down to Runtime field and select Python3 from the dropdown
3. Input pip install -r requirements.txt command under Build Command
Run your build.sh file under Start Command field like this:
```
./build.sh
```
You could just input the command required to start our production server directly into the Start Command field since we do not have any other pre-deploy command. However, in a future event where you would need to run database migration commands, it is best practice to create a build.sh file to run all your commands at once.
Select the instance type of your choice. If it is a practice project, select the free instance type.
Add environment variables
You can proceed in either of the following ways in Render:
1. You can add your environment variables one-by-one from your .env file by clicking on the Add Environment Variable button.
2. You can also click on Add from .env which will provide an input field. Proceed to copy the contents of your .env file from your local machine and paste them in the input field provided, then click on Add variables.
Remember that we added the details of our new PostgreSQL instance, which are different from the database you were using locally. Return to the dashboard and you should see the PostgreSQL instance you just created, marked as available. Click on it and note the database name, database user, database password and database internal URL details. Then proceed in either of the two ways discussed above to set your environment variables on Render.
Click on Create Web Service to initialize the build process. The process will take a few minutes after which your new web service URL will be generated. You can visit your service on the browser by clicking on its URL. If the build process fails for some reason, Render will inform you. You should review the build logs to fix any errors.

Conclusion

Hosting your FastAPI backend with a PostgreSQL database on Render is a fairly simple process. First you will need to prepare your project for production by creating a requirements.txt file, a .env file, a .gitignore file and a build.sh file. Then you will need to push all your code to Github. Finally, you need to proceed to your Render account and create a PostgreSQL database instance, then create your web service by passing in a build command, a start command and your environment variables. Hope this helps. Happy hosting!

Do not Reinvent the Wheel: Utilize Django’s Built-in Auth App to Create a Robust Authentication System

Nick — Thu, 16 May 2024 22:45:56 +0000

Introduction

Many web applications implement a user authentication system for purposes of data security. A robust user authentication system protects user data against unauthorized access or loss. Many server-side programming frameworks like Django provide a ready-made user authentication system. Optionally, a developer can configure such a system from scratch based on project needs. The later is a risky endeavor, as such a system is less secure than a built-in one. Moreover, opting to create from scratch may be an overkill in many scenarios. As best practice, one should use the built-in authentication system which has already been tested and optimized. This article discusses Django’s built-in user authentication system and how you, as a Django developer, can configure it in your project.

Prerequisites

An understanding of how to build with Django.

Django's Auth App

If you peruse Django’s official docs or the source code available on Github, you should locate the auth app documentation. The auth app ships with Django, and is installed in your project when you run the django-admin start project command. Let us observe this in real-time by creating a Django project.

First create your project directory and install Django using your preferred Python virtual environment package. Do not forget to activate the virtual environment.

mkdir code && cd code
pipenv install django
pip shell

Next start a Django project to generate manage.py file and other config files.

django-admin startproject user-auth .
python manage.py migrate
Python manage.py runserver

You can visit http://127.0.0.1:8000 to confirm that you have successfully created a Django project.

Now open our settings.py file to confirm that an auth app exists. In your settings.py under INSTALLED-APPS, you should see this line
'django.contrib.auth'

# user-auth/settings.py
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',  # built-in authentication
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
]

The built-in authentication system comes with its own URL routes and views. Before you configure the system in your project though, you have to include its URL routes in your project-level urls.py file. This is necessary to enable the use of the provided routes locally.

# user-auth/urls.py
from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    # Django admin
    path('admin/', admin.site.urls),
    # User management
    path('accounts/', include('django.contrib.auth.urls')), # This

                                    ...
]

We are prefixing all our user authentication routes with accounts/ as a convection. You could use any prefix though.

Let's inspect the URL routes that ship with the auth app. You can inspect the docs or Django source code for the routes. Auth app provides the following routes:

accounts/login/ [name='login']
accounts/logout/ [name='logout']
accounts/password_change/ [name='password_change']
accounts/password_change/done/ [name='password_change_done']
accounts/password_reset/ [name='password_reset']
accounts/password_reset/done/ [name='password_reset_done']
accounts/reset/<uidb64>/<token>/ [name='password_reset_confirm']
accounts/reset/done/ [name='password_reset_complete']

Implement Login and Logout

Now it's time to configure a simple login and logout. In the routes above, we can see that similar URLs exist.

An important thing to note: The built-in auth app provides the URLs and the views necessary to handle login, logout and other user authentication-related functionality. However, it is up to the Django developer to create templates that render various authentication pages.

We are going to create three pages for rendering purposes: a home page, a login and a logout page

A Simple Homepage

We are going to create a dedicated pages app to render our homepage

python manage.py startapp pages

Then we configure the URL route for the home page

# config/urls.py

from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    # Django admin
    path('admin/', admin.site.urls),
    # User management
    path('accounts/', include('django.contrib.auth.urls')),
    # Local apps
    path('', include('pages.urls')), # This
]

Then create a urls.py file inside the pages app and update it with the home page route

# pages/urls.py
from django.urls import path
from .views import HomePageView

urlpatterns = [
    path('', HomePageView.as_view(), name='home'),
]

Next we need to provide a view logic which the home page URL should resolve to, and a template to
render the page(This article assumes you are sufficiently familiar with the flow of building a web page using Django).

# pages/views
from django.views.generic import TemplateView


class HomePageView(TemplateView):
    """Renders the home page"""
    template_name = 'home.html'

Now we create a home page template. We need to update our settings.py file to create a route to our templates directory. Also, we need to create a templates directory inside our project-level directory.

# config/settings.py
…
TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [str(BASE_DIR.joinpath('templates'))], # update template DIRS like this
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]
…

Then create a templates directory:

mkdir templates

Finally create the home page. We want the page to have a login link if a user is logged out, and
a logout link if a user is logged in. We will use conditional rendering.

<!--templates/home.html-->
<!DOCTYPE html>
<html>

  <head>
    <title>home</title>
  </head>

  <body>
    <div>
      <h1>Home page</h1>
      {% if user.is_authenticated %}
      <span>Hello, {{ user.username }}</span>
      <span><a href="{% url 'logout' %}">Log Out</a></span>
      {% else %}
      <a href="{% url 'login' %}">Log In</a>
      {% endif %}
    </div>
  </body>

</html>

Note the login and logout links provided in the page. They use similar namespaces provided in the auth/urls.py file. Now visit http://127.0.0.1:8000 to confirm if the home page renders correctly.

However, If you click on the login link, you will encounter a TemplateDoesNotExist Error since we do not yet have a login template.

If you inspect auth/views.py file, the login template provided is located at registration/login.html. It means we need to create a login template under a "registration" directory. You could create it under any directory. However, that would mean overriding the built-in LoginView provided by the auth app, which we do not want. Therefore, a suitable option is to create a similar directory structure within our templates directory

mkdir templates/registration
touch templates/registration/login.html

Create a simple login

Our login page looks like this:

<!--templates/registration/login.html-->
<!DOCTYPE html>
<html>

    <head>
        <title>Login</title>

    </head>

    <body>
        <div>
            <h2>Log In</h2>
            <form method="post">
                {% csrf_token %}
                {{ form.as_p }}
                <button type="submit">Log In</button>
            </form>
        </div>
    </body>

</html>

Try accessing the page from your browser at http://127.0.0.1:8000/accounts/login /. If you click on the Log In button, you will run into a 404 error. That means the page you are requesting does not exist on the server. If you inspect the URL in your address bar, you will see that the login provided by auth redirects to /accounts/profile/ page by default. We have not configured such a page, hence the 404 error.

A simple solution is to change the redirect to point to a page we have already configured, in this case our home page. To implement a redirect to the home page, we need to set the LOGIN_REDIRECT_URL directive explicitly in our settings.py file to point to our home page

# config/settings.py
# Add this at the end
LOGIN_REDIRECT_URL = 'home'

Implement Logout

Auth does not provide a logout template. Only URL and view. We could create a custom logout page which the logout URL should resolve to, but that would be unnecessary. The only thing we need to do is to update the LOGOUT_REDIRECT_URL which should redirect a user to one of our existing pages when they log out:

# config/settings.py
LOGIN_REDIRECT_URL = 'home'
LOGOUT_REDIRECT_URL = 'home' # This

Both our login and logout are now redirecting to our home page

Configure Sign Up

Django does not provide a built-in sign up functionality. The Developer should configure it manually. Manually setting up user registration is beyond the scope of this tutorial.

Conclusion

Django is a mature and robust web development framework that comes with many pre-built features. This is intentional, as Django purposes to speed up development. Among the features that ship with Django is the auth app, which contains a pre-built user authentication functionality. The auth app avails login, logout and other user-authentication related functionality for easy configuration. You can, and probably should, leverage the built-in login and logout functionality to quickly set up a user authentication system, so that you can focus on other core features of your web app. Happy coding!

Containerize your Django Web Application with Docker

Nick — Thu, 16 May 2024 22:43:16 +0000

Introduction

Containerization is becoming commonplace in modern software development. The practice involves the development of software applications in isolated environments that mimic a desired operating system. Containerization has enabled developers, using different operating systems, to create applications and collaborate in a consistent environment. Containerization essentially standardizes the development environment for a team of software developers collaborating on a project.

Several containerization technologies exist in the market today, with the most popular one being Docker. This article walks Django developers through containerization using Docker. The article discusses how to set up a containerized development workspace, and the best practices involved. We will create a simple Django application and containerize it.

Prerequisites

• A Working knowledge of web development using Django.

• A Windows 10+ computer with Windows Subsystem for Linux (WSL) installed.

Setting up Docker on Windows

You will need to install Docker on Windows and create a Docker hub account. Follow the installation guidelines provided to set up Docker Desktop on your Windows. Ensure your system meets the specified requirements.

The Docker desktop app acts as a front-end where you can view your images and containers (More on this in soon). Your WSL acts as a backend, where you interact with the Docker Engine, which essentially builds your images and runs your containers. You interact with the Docker Engine by running Docker commands right from your WSL Command Line Interface (CLI).

As a best practice, it is advisable to run Docker as a non-root user using WSL. To set up a non-root user account in your WSL distro with Docker, follow this guideline. If you already have a non-root user and choose not to set up the user with Docker, you will have to preface all your Docker commands with the sudo command.
If you have followed the installation process successfully, run docker –version. Your terminal should display the Docker version you just installed:

$ docker --version
docker version 26.0.0, build 2ae903e

Docker ships with a pre-built "Hello Word" image. You can check if Docker is installed and running properly by confirming that this image exists. To do so, run this command on WSL:

$ docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete
Digest:sha256:b8ba256769a0ac28dd126d584e0a2011cd2877f3f76e093a7ae560f2a5301c00
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly. To generate this message, Docker took the following steps:

1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub. (amd64)
3. The Docker daemon created a new container from that image which runs the executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal.
To try something more ambitious, you can run an Ubuntu container with: 
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/
For more examples and ideas, visit: https://docs.docker.com/get-started/

Then run docker-info:

$ docker info
Client: 
  Debug Mode: false
Server: 
  Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
  Images: 1
  ...

Now we are ready to build and containerize our Django web application.

But Before we Build…

Let’s understand core Docker terminologies. When building with Docker, you should familiarize yourself with these three fundamental terms:

A Docker image
A Docker container
A Docker host

A Docker image is, basically, a list of instruction that the Docker engine follows to build your project. A Docker image can also be construed as a snapshot in time of your software project. You rebuild your image every time you update software packages in your project, or when you change some key code, as in settings.py. You write an image inside the Dockerfile.

A Docker container is a running instance of a Docker Image. You build your project (an image) inside Docker, then you run it, in which case the image is now known as a container. Docker Host is the underlying Operating System that runs Docker containers. One host could run several containers.

Now we Build...

Create a Basic Django application

We are going to build a basic blog application where users can blog on various topics of interest. This article assumes you are already familiar with the flow of building any Django project, hence it will not go into details about building with Django.

Let us think for a moment about the structure and functionality of our project. We want our blog web application to enable a user input a topic and a brief blog about the topic. Each topic could have one or several blog entries. Thus, we will model a topic with a blog entry for each topic.

For this project, we only want to display a list of all available topics though, so we will write a view logic that queries the database to retrieve a list of all topics available. Finally, we will write a template that renders the list of topics on the user interface. We could develop a full blog website. However, for Docker demonstration purposes, we will use this minimalist application.

Let’s get started…
From your CLI:

Create a project directory named code, or any name you prefer, and change into this directory.

mkdir code && cd code
Install the pipenv python virtual environment package if you do not have it already.

pip install pipenv
Install Django using pipenv.

pipenv install django
Activate a virtual environment using the shell command.

pipenv shell

You should see the name of your directory preceding your WSL distro prompt like this:

(code) nick@DESKTOP-TOB16R4:~/

This indicates that your environment is active

Pipfile and Pipfile.lock

Note that when you installed Django, pipenv created two files:

Pipfile
Pipfile.lock

The Pipfile contains a list of dependencies for your project. It serves the same purpose as a requirements.txt file. A Pipfile.lock locks down all project dependencies you installed and the order in which you installed them.

The Pipfile.lock file enforces a deterministic build; you will achieve the same result regardless of the number of times you, or anybody in your team, installs the locked software packages. Without locking down the dependencies and their order, team members may have a slightly differentiated build installations, which could result in conflicts. Remember we want a consistent development environment when working with Docker.

A Containerized Blog App

While your virtual environment is still active, run:

django-admin startproject config .

Django will create a project level directory called config in the current working directory. Do not forget the period after the command, or Django will create an extra directory for our project. We want the project-level directory to be in the current working directory. You could name your project anything else other than config.

Next, we need to migrate our database. The action will apply the default user model and other admin settings to the database.

python manage.py migrate

Next we need to confirm that our project is working as expected:

python manage.py runserver

If you visit http://127.0.0.1:8000 on your browser, you should see the default Django successfully installed page.
If everything is OK, return to your terminal and exit your virtual environment by typing the command exit.

Build your Image

Our project is working as expected in our local setting. Now we need to host it on Docker. It should show a similar page. To containerize it, we will need to build an image of the project. As mentioned earlier, this is a list of instructions that Docker will run to set up our project. Create a file called Dockerfile in your root directory:

Dockerfile

# Pull base image
FROM python:3.10
# Set environment variables
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1
# Set work directory
WORKDIR /code
# Install dependencies
COPY Pipfile Pipfile.lock /code/
RUN pip install pipenv && pipenv install --system
# Copy project
COPY . /code/

The Dockerfile is executed top to bottom. Thus, the first command must be the FROM command. This command pulls over our base image from an online repository, which is python 3.10 in this case. You could specify any Python version you want based on your project needs.

The ENV command set two basic environment variables: PYTHONDONTWRITEBYTECODE prevents Python from writing .pyc files, which we do not need. PYTHONUNBUFFERED formats Docker’s output to the console.

Next we are setting up a working directory called code using the WORKDIR command. This step is essential when we are executing commands within our container. If we do not specify a working directory, we would have to type in a long path. By setting a default directory as above, Docker automatically executes commands within this directory.

Next, we install project dependencies using pipenv. Remember that our project contains one dependency, Django, so far. We begin by copying over the contents of our Pipfile and Pipfile.lock into our working directory (code), that we just created. Then we install the dependencies globally within Docker by appending the –system flag at the end of the install command. We use the --system flag to instruct pipenv to install the software packages globally within Docker. This is because pipenv, by default, looks for a virtual environment to install packages, and Docker now acts as our virtual environment.

Next we copy over the rest of our local code into our Docker working directory.

Now let’s build our image with a single command.
Run:

$ docker build .

Docker will output a lot of information on the console. Check the last part of the output to confirm whether Docker successfully built your image.

Next, we need to get this image running so we can interact with our web app from the browser. To accomplish that, we would need to create a
docker-compose.yml file.

docker-compose.yml

version: '3.8'
services: 
  web:
    build: .
    command: python /code/manage.py runserver 0.0.0.0:8000
    volumes: - .:/code
    ports: - 8000:8000

Let’s explain the contents of this file:

The first line specifies the Docker compose version, which is 3.8 in this case.

The services command specifies the containers to run, which is a just web service container in this case. As mentioned earlier, you can specify several containers to run.

The build command instructs Docker to look for a Dockerfile within the current working directory. Next, we start our server at port 8000, which is Django’s default port.

The volumes mount syncs Docker’s file system with our local file system, meaning we do not have to edit the files locally once we edit them inside Docker.

Finally, we expose port 8000 within Docker.

Time to run our container. Type this command:

$ docker-compose up

You should get the following output:

Creating network "code_default" with the default driver
Building web
Step 1/7 : FROM python:3.8 ...
Creating code_web_1 ... done
Attaching to code_web_1
web_1 | Watching for file changes with StatReloader
web_1 | Performing system checks...
web_1 |
web_1 | System check identified no issues (0 silenced).
web_1 | May 03, 2024 - 19:28:08
web_1 | Django version 3.1, using settings 'config.settings'
web_1 | Starting development server at http://0.0.0.0:8000/
web_1 | Quit the server with CONTROL-C.

If you visit your browser at http://127.0.0.1:8000, you should see the default Django successfully installed page as before. This means that you have successfully containerized your Django project using Docker.
Since Docker stores a running container in RAM, and a container takes a lot of space (A simple container could be over 1GB), it is advisable to stop the container when not in use. To do so, run:

$ docker-compose down

Building within Docker

We can start our docker container in detached mode. Running a container in detached mode allows you to use a single terminal without having to stop your server or use multiple terminals. To use a container in detached mode, run:

$ docker-compose up –d

Building within Docker is no different from building locally. The only exception is we now have to preface any command we run with docker-compose exec web.

We are going to create an app called blog then create the necessary model, view and template for our blog web app.

Run:

$ docker-compose exec web python manage.py startapp blog

# blog/models.py
from django.db import models

class Topic(models.Model):
    topic = models.CharField(max_length=200)

    def __str__(self):
        return self.topic


class Entry(models.Model):
    topic = models.ForeignKey(Topic, on_delete=models.CASCADE)
    text = models.TextField()

    def __str__(self):
        return self.text[:50]

Then migrate your database to apply these new models

docker-compose exec web python manage.py makemigrations blog
docker-compose exec web python manage.py migrate

Finally, you should register your models with the admin site at blog/admin.py so you can interact with them via them admin panel at http://127.0.0.1:8000/admin. You can try adding a few topics and entries via the admin.

Next configure URL routes for the blog app:

# config/urls.py
from django.urls import path, include

urlpatterns = [
    path('admin/', include(admin.site.urls)),
    path('', include('blog.urls')),
]

# blog/urls.py
from django.urls import path
from .views import TopicListView
urlpatterns = [
    Path('', TopicListView.as_view(), name='topics'),
]

Write a view to list all topics available in the database:

# blog/views.py
from .models import Topic
from django.views.generic import ListView

class TopicListView(ListView):
    """Lists all topics"""
    model = Topic
    context_object_name = topic_list
    template_name = 'topics.html'

Render the topics list to the user interface

<!--templates/topic.html-->
<!DOCTYPE html>
<html>
    <h1>Topics</h1>
<ul>
    {% for topic in topic_list %}
        <li>{{ topic }}</li>
</ul>
</html>

After you have updated your app files like above, try visiting the local host URL to check if it lists all the topics you have added. If you are encountering any errors, Docker provides an error log. Run:

docker logs

A Summary of Steps

In summary, follow these steps to containerize your Django application:

Create a virtual environment locally and install Django
Create a new project
Exit the virtual environment
Write a Dockerfile and then build the initial image
Write a docker-compose.yml file and run the container with docker-compose up
Rebuild your image every time you install a software package
Restart Docker every time you make changes to your settings.py file
Run docker logs if you encounter any errors

Conclusion

Modern web development involves working in teams. Therefore, the development necessitates building using containers such as Docker. It is important for beginners in backend development familiarize with Docker as early as possible. This article covers the fundamentals of getting started with Docker. It discusses fundamental Docker concepts and commands. Whereas there is more to containerization and the Docker technology that requires further learning, this article is an excellent starting point for beginners. You can start here and work your way up to becoming an expert. Docker itself has a steep learning curve, and it takes more than what we have discussed here to gain proficiency. Nevertheless, you can start here and build small, containerized Django applications to familiarize yourself with the basics. Happy containerization!

The Django ORM: The Magic between the Application and the Database

Nick — Sun, 17 Mar 2024 20:03:59 +0000

Introduction

Applications that constitute a database allow users to interact with the application’s data through Object Relational Mappers (ORMs). ORMs are the intermediaries between an application and a database. They provide a set of functionality that enable CRUD database operations. Many server-side programming frameworks like Python’s Django provide ORMs that allow developers to write database queries in the pure server-side language. The ORM then performs a database operation in a language understood by the database type in use. This article discusses the Django ORM, including the functionalities that the ORM provides to facilitate database interactions.

A Brief Overview

When building a backend application using Django, you would typically install Django in a virtual environment. Django installs a SQLite database by default, which comes with the Django ORM to allow database operations. You may have interacted with the Django ORM functionality without noticing. For instance, every time you have used .get() or .filter() methods somewhere in your views.py file, you were using Django ORM methods to query the database.

Django ORM methods can broadly be classified into two types:

Those that interact with a queryset
Those that interact with a model object

In simple terms, a queryset is single or several database records. A database record is basically a data row in a database. Therefore, queryset methods act on database records. A model object is an instance, or a definition if you may, of a database record. A model object provides information about a database record. That is, what fields does the database record have? For instance, a database record could have ID, name, URL, image or Foreign Key fields. Django ORM has methods that can manipulate these database record fields.

Django ORM Methods

This section discusses the most commonly used Django ORM methods. The methods are grouped based on related functionality. That is, the methods that perform a similar functions are discussed together. Note that based on the broad classification discussed above, methods within the same category could interact with either a queryset or a model object.

Filtering Methods

Filtering methods return querysets depending on the lookup parameters passed to the methods.

`.filter(**kwargs)`

.filter() returns a queryset that matches the lookup parameters passed to the method. For instance, assume you are a querying a database field, name, for all database records containing the name bob. In this case you would need to filter your database by bob as a keyword argument. Django ORM provides a magic method, __icontains, that attaches to a database field, which is useful for string and substring matching. You would implement this operation like this:

from models import YourModel
bob_records = YourModel.objects.filter(name__icontains="bob")

Another common example where you would use .filter() is when you have implemented user accounts in your Django application. You may want to restrict each user to their data. In this case, if a user requests some data, you want to show them only the data that belongs to them. You would typically use .filter() method to avail data by the user making the request:

your_data = YourModel.objects.filter(owner=request.user)

Assuming in your data model you have a field called owner that associates data and users

`.excludes(**kwargs):`

Works the same way as .filter() but returns database records that do not match the lookup parameters.

`.get(**kwargs):`

This method is among the most commonly used. Like .filter(), the method is used to retrieve the data that matches the lookup parameters passed to it as keyword arguments. However, .get() returns only a single database record while .filter() returns one or more records. .get() raises a MultipleObjectsReturned error or DoesNotExist error exception if multiple objects are found or no object is found, respectively. Below is an example of how you would use .get()

data = YourModel.objects.get(id=1)

This queryset returns a database record with an id 1

`.first()`

Returns the first object matched by the queryset or None if the queryset is empty.

`.last()`:

Returns the last object matched by the queryset or None if the queryset is empty.
.first() and .last() are usually used with .filter() incase one needs only the first or the last item returned by .filter():

bob_records = YourModel.objects.filter(name__icontains="bob", owner=request.user).first()

Aggregation Methods

Aggregation methods perform arithmetic calculations on querysets. They include:

`aggregate(*args, **kwargs)`:

Performs aggregate calculations (e.g., Count, Sum, Avg, etc.) on the queryset

`.count()`

returns the number of objects in a queryset

`.exists()`

Evaluates to true if a queryset contains any results, else false. This method could be combined with .filter() in a real-world use case. Assume you want to add a record to the database, but only if no similar record already exists. Say you want to add a name bob to a database field name:

If not YourModel.objects.filter(name="bob").exists():
  model_instance = YourModel(name="bob")

Ordering Methods

Ordering methods sort a queryset based on declared model fields.
Assume you have this model

class Names(models.Model):
    Name = models.CharField(max_length=200)
    date_added = models.DateTimeField(auto_now_add=True)

Names.objects.order_by('date_added'): returns a queryset based on the date they were added to the database. The first added entry is returned first. Assuming you want to return a queryset based on the most recently added record, you would reverse the order like this:

Names.objects.order_by('-date_added'). # The '-' sign indicates 'reverse'

Alternatively, Django ORM provides a .reverse() method for reversing the order of querysets:

Names.objects.order_by('date_added').reverse()

Alternatively, you could sort the entries of the above model like this:

class Meta:
    Ordering = ['date_added']

In this case, you provide a Meta class inside your model class and define the desired ordering using the attribute ordering

Update and Delete

Methods for updating or deleting objects in the database.
.update(**kwargs): Updates all objects(fields) in the queryset with the given values.

YourModel.objects.get(id=1).update(name="bob")

The above query updates the model field "name" with value "bob"
You can update more than one field with .update()

YourModel.objects.get(id=1).update(name=”bob”, gender=”male”)

.delete(): Deletes all objects in the queryset.

YourModel.objects.get(id=1).delete()

The above query deletes a database record with id 1. Note that while .update() can act on a part of a database record(a field), .delete() acts on the entire record(all fields);.delete() erases the entire record at once from the database.

Other Methods

.values(*fields, **expressions): Returns a queryset that returns dictionaries instead of model instances, with values according to the specified fields and expressions.

.values_list(*fields, flat=False): Similar to values() but returns tuples instead of dictionaries.

.values() and .value_list() are helpful when you want to return specific database fields while excluding others.
Assume you have this model:

from django.db import models
from django.contrib.auth.models import User

# Create your models here.

class PasswordEntry(models.Model):
    """Defines password's data structure"""
    website_url = models.URLField(max_length=200)
    username = models.CharField(max_length=100)
    password = models.CharField(max_length=500)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)
    owner = models.ForeignKey(User, on_delete=models.CASCADE, default=1)

    class Meta:
        ordering = ['-created_at']
        verbose_name_plural = 'password entries'

    def __str__(self):
        """Returns a string rep of password entry"""
        return f"{self.username}-{self.website_url}-{self.password}"

This is a password entries model that allows a user to store passwords to their various user accounts. If you are building a similar Django application, you may want to implement a functionality that allows users to search for specific passwords. In this application, you may want to display the password entries by website URL or username instead of the actual password, for security reasons

Your search functionality may look something like this. Notice how .values_list() comes in handy when you want to choose the fields to display:

def search_entry(request):
    """Searches for a password entry by site name"""
    query = request.GET.get('q')
    if query:
        entries = PasswordEntry.objects.filter(website_url__icontains=query, owner=request.user).values_list('id', 'website_url')
    else:
        entries = PasswordEntry.objects.filter(owner=request.user).values_list('id', 'website_url')
    context = {'entries': entries}
    return render(request, 'manager/search_entries.html', context)

.values_list() and .values() act on model instances instead of querysets. Attempting to apply the methods on querysets will raise an attribute error.

Conclusion

Object relational Mappers (ORMs) are a useful technology. They allow backend developers to query databases without having to write raw statements in a standard database query language like Structured Query Language (SQL). ORMs, therefore, reduce the chances of database injection attacks. The attacks can occur if users access the database directly using languages like SQL. Moreover, developers do not have to necessarily understand a query language; ORMs conduct most of the heavy lifting.

Django provides its own ORM, the Django ORM. The Django ORM avails different types of methods that enable developers to perform CRUD operations on the database. The methods perform operations such as filtering, aggregation, ordering, updating and deleting. Several errors are bound to rise if the methods are used inappropriately. This article mentions several errors such as AttributeError, MultipleObjectsReturnedError and DoesNotExistError. Nevertheless, the Django ORM is a powerful tool for executing database transactions. Try it out, and happy querying!

Understanding Http Redirections in Django

Nick — Thu, 22 Feb 2024 06:12:43 +0000

Introduction

As a web developer, you may need to perform Http redirections in your backend logic. You may implement Http redirections under several circumstances:

When redesigning a website URLs
When rerouting traffic to HTTPS
When enforcing authentication and authorization to protected resources
When using canonical URLs
When implementing a shortened URL functionality

This article briefly discusses the above circumstances. Moreover, the article explains the Http redirection types you would typically perform. Finally, it elaborates on how you may implement temporary Http redirections in Django. The article provides a useful starting point for engineers getting started with Http redirections in Django. Additionally, the article could be an informative piece for general learning.

How to Read this Article

The article has two sections, one that provides an overview of Http redirections in general, and the other that gets into Http redirections in Django. You can start from the beginning or jump to implementing Http redirections in Django.

Why Redirect URLs?

When Redesigning your Website URLs

As a web developer, you may perform major backend updates from time to time. The updates may involve changing the structure of your URLs or updating the URLs to new routes. In such a case, your website's users may encounter a Page Not Found Error if they visit your old URLs. To prevent the error, you would let users make requests using the URLs they are used to, and then handle Http redirections to the new URLs.

When Implementing a URL shortening functionality.

Sometimes you may want to convert long URL strings to shorter strings that are memorable. Implementing a URL shortening functionality may be necessary in this case, to enhance user experience. When users request resources from your server using the shortened URLs, they should be redirected to the actual URLs. In your backend logic, you would need to map the shortened URLs to their corresponding longer versions.

When Re-routing Web Traffic to HTTPS

Many website applications reroute non-HTTPS traffic to HTTPS for security reasons. HTTPS is a secure protocol with which a web server and client computers communicate. System engineers typically configure web servers such as NGINX and Apache to redirect all non-HTTPS traffic.

When Enforcing Authentication and Authorization

Websites restrict access to protected content by requiring prior user authentication and authorization. In such cases, if an unauthenticated or unauthorized user tries to access a protected resource, the website would redirect them to login or registration page. A backend engineer implements the Http redirection.

When using Canonical URLs

A canonical URL is the preferred URL(s) in a list of URLs that can access the same web resource. In some cases, web apps may have different URLs that map to the same resource. In such cases, web developers may implement canonical(read preferred URLs), for search engine optimization purposes. The idea is to map the least preferred URLs to the canonical URLs. In addition to optimizing search engines, canonicalization ensures predictable and consistent browsing experience for a website's users. Canonicalization can be implemented both on the front-end and back-end.

Types of Redirection

In a Django Project, and based on the above Http redirection circumstances, a Django engineer would implement both temporary and permanent Http redirections. A temporary URL redirection means that, while a web resource can be internally accessed via a new URL, the client should continue using the old/original URL to request the resource.

Suppose you are changing your URL formats but want the user to continue using previous URLs, which they are used to. You would implement a temporary redirection. When users visit your web resources using the previous URLs, your app would redirect them to the new URLs

You may also implement a permanent redirection. You use this redirection type where the structure of a URL has changed fundamentally. Permanent redirections instruct clients (browsers and search engine crawlers) to cache the new URL and use it to make future requests.

HTTP status codes in the range 3XX represent the different types of Http redirections. The server returns status codes 302 and 307 for temporary redirections. In contrast, codes 301 and 308 signify permanent redirections. When running a Django web server in a development environment, you can inspect the server response header of a URL endpoint to check the Http redirection type.

How to Implement a Temporary Redirection in Django

Here is how you would implement a temporary redirection in your Django project. You would typically implement the redirection in your views.py file. Suppose you need to redirect users to the home page after they have logged into their accounts. In this case, you would implement the Http redirection in your login view logic, after a user has been authenticated.
Assume you have this login view function:

# views.py
from django.contrib.auth import authenticate, login
from django.http import HttpResponseRedirect
from django.urls import reverse

def login_user(request):
    """Logs in users into their accounts"""
    email = request.data.get('email')
    password = request.data.get('password')

    user = authenticate(request, email=email, password=password)
    if user is not none:
        login(request, user)
    return HttpResponseRedirect(reverse('myapp:index'))

In the above code, take note of the following lines:

from django.http import HttpResponseRedirect
from django.urls import reverse

return HttpResponseRedirect(reverse('myapp:index'))

You would need to import the HttpResponseRedirect class object and the reverse function from the correct libraries as above. After you have defined the logic for your view function and need to perform a redirection, return HttpResponseRedirect class, passing the reverse function to it. Additionally, you need to pass the URL you want the view to redirect to as a parameter of the reverse function

The HttpResponseRedirect Class

This is a Python class object used to perform Http redirections to specified URLs. The class takes a single parameter, the URL to redirect to. Below is the class's definition:

class HttpResponseRedirect(HttpResponse):
    def __init__(self, redirect_to, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.['Location'] = iri_to_uri(redirect_to)
        self.status_code = 302

The redirect_to parameter represents the URL the client should be redirected to. This URL is set in the Location header of the server response.

The reverse() Function

The reverse function dynamically generates a URL string based on a view's namespace or its URL pattern. The namespace is defined in a Django app's urls.py configuration file. Below is the reverse function's signature:

def reverse(viewname, urlconf=None, args=None, kwargs=None, current_app=None):

The viewname parameter is the main argument. This parameter is required. viewname is the namespace of a view function or the associated URL pattern specified in your app's url.py file. Returning to our login example above, in a Django app called 'app', you might have configured your index page URL configuration like this:

# urls.py
url_patterns = [
    path('/index/', views.index, name='index'),
                                ...
]

index is the namespace for the index view function, or namespace for your index URL pattern. A namespace can be understood as an identifier for a particular view or URL. You can reference a URL or a view anywhere in your Django app using its namespace.

Other parameters passed to reverse are optional.

urlconf: allows you to specify a URL pattern for the redirect URL. When building a Django project, you define several patterns in different apps for your URLs. By default, the root URL pattern for the current app is selected.
args: allows you to pass positional arguments to reverse as a list or tuple.
kwargs: a dictionary containing keyword arguments you may need to pass into reverse. You cannot pass args and kwargs at the same time
current_app: Specifies the name of the app that the namespace belongs to.

The reverse function constructs and returns a URL string when the resolver finds a URL pattern matching the namespace. If no match is found, the resolver raises a NoReverseMatch exception.

Use Cases

In some cases, you may pass a URL string as an argument directly to the HttpResponseRedirect class instance. In this case, you are hardcoding the redirection. In case you change the structure of your redirect URL, you would need to explicitly update the URL string passed to HttpResponseRedirect.

# views.py
from django.http import HttpResponseRedirect

def my_view(request):
    # Assuming redirect_url is the URL you want to redirect to
    # Redirect URL could be a relative or absolute path of a URL
    # within your Django project
    redirect_url = "/some/redirect/url"
    return HttpResponseRedirect(redirect_url)

However, it is considered best practice to use HttpResponseRedirect with reverse. The technique offers more flexibility and makes it easier to maintain and read code.

Take this use case for example:

# views.py
from django.http import HttpResponseRedirect
from django.urls import reverse

def my_view(request):
    # Some logic to determine view name or URL pattern dynamically
    if some_condition:
        view_name = 'app_name:view_name_1'
    else:
        view_name = 'app_name:view_name_2'

    url = reverse(view_name)
    return HttpResponseRedirect(url)

In the above case, if you change the structure of a URL, you only need to update the value of view_name variables. Moreover, you can dynamically redirect to different URLs based on custom conditions. The approach offers more freedom.

A Complex Case

As discussed above, the reverse function takes other optional parameters. Sometimes you may need to redirect to a URL that takes additional parameters in the URL string. In this situation, you need to pass the additional parameters either as positional or keyword arguments to reverse.

Assume you are writing a view that updates the information about an object stored in a database. The view retrieves the object by ID and should redirect to a URL that returns the updated object. In such a case, you may pass the object's ID as a keyword argument to reverse. Look at the example below:

# views.py
from django.http import HttpResponseRedirect
from django.urls import reverse

def update_object(request, pk):
    """
    Updates an object by id
    args:
        request: request object
        pk: object id
    """
                ...
    return HttpResponseRedirect(reverse('myapp:some_view_name', 
        kwargs={'pk': pk}))

Conclusion

A Django engineer may occasionally need to perform Http redirections for various reasons. Understanding the various redirection types and implementation strategies is key to executing successful redirections. Python provides tools that facilitate Http redirections. The HttpResponseRedirect class object takes in a URL string and redirects the current view to the redirect URL, which is the URL string argument passed to the class instance. When the class object is used with the reverse function, Http redirection becomes more flexible. The reverse function takes in a namespace, representing a view or the view's URL pattern. Then a URL resolver engine matches the namespace to a configured URL pattern and executes the redirection. That's all. Have fun implementing Http redirections in your Django project!

Handling JSON Data Serialization when Working with Django REST Framework APIs

Nick — Fri, 02 Feb 2024 15:50:10 +0000

Introduction

Website development, and computer programming in general, involves handling and manipulating data. Many web apps constitute database serves that hold various types of data. Client computers frequently need to retrieve or update the data, which necessitates data transmission back and forth, between the front-end and back-end.

Applications transmit data in several formats between origin and destination entities, with encoding and decoding of the data taking place at source and destination respectively. This article discusses the encoding and decoding of data in Python backend applications using JSON format, with a specific focus on Django Rest Framework APIs.

Prerequisites

A basic understanding of the concept of serialization
A basic understanding of the Django REST Framework

A Simplistic Overview

As mentioned, software systems transmit data in various formats. Common formats include JavaScript Object Notation(JSON), XML, and CSV. However, web applications widely implement the JSON transmission due to JSON's compact structure and readability. Moreover, since JSON's syntax closely resembles a JavaScript's object syntax, and JavaScript is the primary language for modern web browsers, JSON enjoys robust browser and server-side support.

Serialization

In simple terms, serialization basically means "encoding" of data. Serialization is the practice of converting a data object that constructed in one of a programming language's native data types into a format suitable for transmission, such as JSON. Python data objects, for instance, could be of any native Python data types—string, integer, list or dictionary. Serializing such an object involves converting its format from, say, a Python string to a JSON string.

Deserialization

Deserialization could be understood as "decoding" of data at the destination. The concept is the opposite of serialization. In this case, a JSON or XML data structure is reconverted into a native type. For instance, a Python string that was processed into a JSON string at the source is reverted into a Python string. The data could then be stored in a database or used in some other Python program.

Why Serialize Data?

Serialization of data intends to achieve various efficiency metrics in applications. The metrics include performance, responsiveness, speed, security etc. In the context of web applications, serializing data facilitates:

Seamless portability of data between front-end and back-end systems written in different programming language
Reduced network bandwidth during the transmission process since data is compacted
Reduced network latency during transmission.
Easy conversion of data from a complex type to a string of bytes for network transmission
Validation and implementation of security checks for the data being transmitted

How is Data Serialization and Deserialization achieved in Python?

Python has built-in modules that facilitate serialization and deserialization in common data formats. The most popular Python data modules include json and csv. For purposes of this article, we will not discuss working with these modules for basic implementation of serialization in Python. For more information regarding JSON and CSV formats in Python, check out this tutorial.

JSON Serialization in Django REST Framework APIs

Understanding data serialization comes in handy when working with Application Programming Interfaces (APIs). One of the primary functions of APIs is to avail data to front-end applications. When building APIs that deliver data to the front-end, backend engineers define data serialization mechanisms in the backend logic.

In Django REST Framework (DRF), it is common practice for backend engineers to create a serializers.py file that defines an application's data serialization logic. The serialization logic, in this case, constitutes one or several Python class objects. The class objects are defined therein, imported into views.py file and applied to API view classes or functions.

To recap a typical Django web application file structure, assume you are designing APIs of a restaurant web app. Your app’s file structure, including the serializers.py, might look something like this:

  ->Project’s root directory
    ->manage.py
    ->restaurant_app directory
      -> urls.py
      -> views.py
      -> models.py
      -> serializers.py

Your project’s root directory might host several applications with different APIs defined. Each application should have its serializers.py file.

A Typical Serializer Class

To define a typical serializer Python class object for your API, you need to provide the following inside your serializer class definition:

A nested Meta class
Your model
The model fields to be serialized

Assume in your restaurant’s model.py file you have defined the following fields:

from Django.db import models

# Create your models here
class Available_Foods(models.Model):
    """Food types in my restaurant"""
    id = models.IntegerField(primary_key=True)
    food_name = models.CharField(max_length=255, null=True)

The model above has two fields that need to be serialized: id and food_name. Your serializer.py might look something like this:

# serializer.py
from rest_framework import serializers
from .models import Available_Foods

class Available_Foods_Serializer(serializers.ModelSerializer):
    """Serializes my model fields"""
    class Meta:
        model = Available_Foods
        fields = ['id', 'name']

In this typical serializer class, you need to import the serializers module, which DRF provides. The module contains a Python class object known as ModelSerializer which will act as a super class to all the classes you define in the serializers.py file.

Inside your custom serializer class, you need to provide a nested class, Meta, that specifies the model whose fields need to be serialized. Additionally, you need explicitly state the model fields to include in the serialization. In some cases you may not need to serialize all fields, and hence, DRF serialization offers this flexibility. If you need to serialize all fields without explicitly stating them in the fields variable array, you can replace the fields array value with this Python magic method:

fields  =  __all__

After you have defined your serializer class and the fields you need serialized, you can go ahead and apply the serializer class(es) to your API views like this:
1.Import your custom serializer class(es) into your views.py file

from .serializers import Available_Foods_Serializer

2.Define your view class(es), if not already defined.
3.Enter your serializer class at the beginning of your API definition, after the line that defines the queryset which the API will act upon.

class ListFoods(generics.ListAPIView):
    """Lists all available food items"""
    queryset = Available_Foods.objects.all()
    serializer_class = Available_Foods_Serializer

Sending Serialized Data to a DRF API Endpoint

Using our restaurant project, assume you want to create a food item that your restaurant offers, identified by ID and name, and store it in the database. In a development environment, you will need to enter the API endpoint, which should already be defined in your application's urls.py file, in a browser, with some JSON formatted data. Look at the example below:

Assume you have this endpoint for populating your database with available foods:

/root_url/restaurant_app/create-food-item/

DRF’s browsable API provides an effective platform for working with DRF APIs in your browser. Your POST request data to the above endpoint might look something like this:

{
    "id": 1,
    "food_name": "pizza"
}

Note the format of the request data. The format is JSON—key-value pairs with all strings in double quotations. The data is said to be JSON serialized, ready for transmission. If you send a POST request with this data to the above endpoint, the data will be deserialized into a Python object and stored in the database.

The server may send a similar response as below if your create operation was a success. Note that the response contains the object you just created in JSON format.

POST /restaurant_app/create-food-item/
HTTP 201 CREATED OK
Allow: POST
Content-Type: application/json

{
    "id": 1,
    "food_name": "pizza"
}

If you inspect the server's response header’s Content-Type field value, it displays application/json. The Content-Type field returns the data format of the response body, which, in this case, is JSON.

Conclusion

Working with the JSON data format when DRF APIs could be challenging for first timers. While this article provides useful information for those getting started with data serialization in DRF APIs, it is certainly not exhaustive.

This article fails to mention the mistakes that developers can commit while defining models and serialization classes in Django. The mistakes mess up serialized outputs and throw errors when sending requests to endpoints. Additionally, a backend engineer may need to develop more complex serialization class objects, not captured in this article, based on the front-end consumer application’s needs.

Nevertheless, this article offers a decent entry point to those who are getting started with API serialization in Django. Happy coding!

How to Deploy your Django Web App and connect a MySQL Database in cPanel

Nick — Tue, 23 Jan 2024 14:52:01 +0000

Introduction

With many businesses going online, there is an increasing demand for web hosting services. Hosting services provide a platform where web developers can store web application files in a production environment.

Several hosting services exist in the market. The services cater to a range of client needs, which includes the volume of traffic a web service is expected to receive, security needs and performance.

Hosting services such as Digital Ocean are suitable when a web application is expected to receive huge traffic. However, such hosting sites are usually cost-prohibitive. In contrast, hosting services such as cPanel can efficiently host sites that handle medium to low traffic at lower costs. Moreover, cPanel is a convenient to-go service for practice projects. This article guides on how to host a Python Django project in cPanel.

Prerequisites

An existing Django project
A cPanel account with a domain name
A zipped file of your website (Should be a .zip extension)

Meeting the Prerequisites

If you do not have an existing Django project, use one here. For a cPanel account and domain set up, check this out. Now that you are ready to go with a Django project and a cPanel account, create a zipped file of your website like this:

Linux

Navigate to the directory that hosts your project's folder
Type the command below. Remember to replace archive.zip and your_project_folder with actual names. bash zip -r archive.zip your_project_folder

Windows

Navigate to your project's folder location.
Right click on the folder and select Add to archive. A .zip file will be created.

Upload your Files

Log in to cPanel using the username and password you set with the hosting provider
Navigate to the File Manager section on the cPanel dashboard. Click and select Public_html under File Manager.

Note: This is only applicable if you are uploading the web app for the main domain and not the add-on domain or subdomain as they are located in a different folder within the file manager.
Click on Upload then Select File. You will be prompted to select a file from you PC.
Select the zipped file from your PC and hit upload. Alternatively you could drag and drop the .zip file to cPanel. Once the file finishes uploading, click on go back to return to the Public_html directory.
Locate your zipped file and right click on it, then select extract to extract subfolders and files within it.

Now your files are ready

Set up a MySQL Database

Note: You need to perform this step before you set up your Django app. To set up a MySQL database:

Locate the Databases section on the cPanel dashboard.
Select MySQL Databases.
Create a database with a suitable name in the provided Create New Database field.
Input user credentials, a username and password, in the Create New User field to create a new user. Copy the password somewhere as you will need it to configure the database.
In the User Privileges section, check All Privileges
Confirm that the database has been created by clicking on the phpMyAdmin option under Databases section.
Configure a MySQL database in your settings.py file.
In development, you most likely have been using an SQLite database. Since we have switched to a MySQL database, you need to configure the new database settings.

Locate the DATABASES section in your project's settings.py file and replace the existing database settings with the code below. Remember to replace the NAME (database name), USER, and PASSWORD fields with actual values:
```
#settings.py

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'mysql_db_name',
        'HOST': 'localhost',
        'PORT': 3306,
        'USER': 'my_sql_user',
        'PASSWORD': 'password',
    }
}
```
Save and close the file.

Your database is now configured.

Set up Your Django App

Create Your App

Locate the Software options in the cPanel Dashboard
Click on Setup Python App
Select CREATE APPLICATION to begin setting up your Python app.
Select a Python version. The latest is recommended.
Input the root directory of your project under the Application root field. For instance, if your application root folder is called Django-project and you uploaded it to Public_html, your application root becomes Public_html/Django-project
Select a domain name for your application. The main domain is selected by default.
Leave the Application startup file and Application Entry point fields empty. The build process will fill them appropriately.
Hit the CREATE button in the top right bar to create your application.
Notice that the build process has filled the two empty fields. We will need the passenger_wsgi.py file in a moment.
Edit the passenger_wsgi.py file.

When you created your web app, the build process generated a file named passenger_wsgi.py and stored it in the root directory of your project. You need to edit this file so that the production server can serve your application. Right click on the file and select the edit option. Once the file is opened, delete all contents in the file except the two import statements at the top. Next, add the following line below the imports:

# passenger_wsgi.py
import os
import sys

from wsgi_directory.wsgi import application

The line imports your application object from the wsgi.py file located in the same directory as your settings.py. Remember to replace wsgi_directory with the actual name of the directory. Next, save and close the file.

Your have created a basic application

Note: For subsequent steps, you might run into errors when installing dependencies and/or when running migrations. Such errors could, most likely, be a result of issues in your source code. You can inspect the stderr.log file for error details. This file was created together with your app, and is located in your project's root directory. Read the error log and fix any problems in your source code before you proceed.

Set up a Virtual Environment

Activate a Python virtual environment. This is necessary to store and separate your project's dependencies.

Note 1: A virtual environment link was generated when you created the application. It can be accessed at the top of the page.

Note 2: You need to copy the link and paste it in a bash terminal provided by the hosting service. The terminal should be under Advanced section on the cPanel dashboard.
Note 3: Depending on your hosting plan, the terminal may not be available to you.

If you can access the terminal:

Paste the virtual environment path into the terminal and press Enter. The process activates a virtual environment and changes into your project's root directory.
Install project dependencies: python pip install -r requirements.txt
Create the database schema and tables python python manage.py makemigrations python manage.py migrate

If you do not have access to a terminal:

Select the Setup Python App option. You should see your app under WEB APPLICATIONS.
Click on the edit icon under Actions and scroll down to Configuration files.
Enter the name of your dependencies file, in our case the requirements.txt file, in the field provided, and click the Add button.
Click on Run Pip Install button, which will prompt you to select the requirements.txt file you just added.

Wait for a few moments while the build process installs dependencies in your virtual environment. You should get a successfully installed pop-up message as soon as the process completes
Enter the following commands, one at a time, in the Execute python scripts field and press the Run Script button. This step is crucial to create database schema and tables, based on your models.py file, in the database you set up earlier.
```
manage.py makemigrations
manage.py migrate
```
Note: If you uploaded your files to Public_html and entered the commands exactly as above, it should work. However, if you uploaded your files to a different directory, you would need to specify the full path to the manage.py file. Additionally, if you have more than one project in the Public_html directory, you may need to specify the path to a specific manage.py file. This tutorial assumes only one manage.py file is available in Public_html directory.
Set Your Environment Variables

This step is crucial if you used any environment variables within your app. For instance, you might have used an environment variable as a place holder for the SECRET_KEY variable in your settings.py file.

Conclusion

This tutorial provides a comprehensive guide to correctly hosting your project in cPanel. Hosting your Django web app with cPanel essentially involves three major steps:

Uploading your project .zip extension file
Configuring a database
Setting up your app

Deploying your Python project to cPanel could be challenging for beginners. However, in this author's opinion, cPanel has a gentler learning curve compared to other hosting sites. The above guidelines have expounded on the steps above in detail, including providing information on potential pitfalls. Happy hosting!

Need to Create a Simple Content Aggregator Website using Django? It's a Minimalist Task

Nick — Thu, 04 Jan 2024 03:07:03 +0000

Introduction

The web contains a lot of content housed in thousands of websites. Different websites contain related content that one website could efficiently host. The nature of distribution of related content on the web forces users to visit different websites for the same information, which could be hectic and time consuming.

Several content gathering websites exist to enhance user experience. The sites gather information about various topics in one place so that users do not have to scour the web unnecessarily. This article discusses the engineering behind these content aggregator sites. Developers interested in designing content aggregators may find this article helpful.

Prerequisites:

An understanding of Python basics and the Django framework
Basic knowledge of RSS feeds

RSS feeds

Content aggregator sites collect content from Really Simple Syndication (RSS) feeds. RSS feeds are XML files that many websites, which host frequently changing content, create to track content records. An RSS feed typically contains important information about a piece of web content. For instance for a news content, the feed could contain the following information:

Name of the publishing site
Title of content
Publication date
URL of the content

Python's feedparser library

A Python library known as feedparser is a useful tool that a content aggregator site developer can use to parse and extract content from RSS feeds. However, before using the library, the developer should decide the kind of data to retrieve from RSS feeds. If one is building a news aggregator website, one would perhaps need to retrieve the metadata listed in the previous section for each news item at the minimum.

To use the feedparser library to parse RSS feeds:

Create a Python virtual environment and install Django
Install the feedparser library using pip
```
pip install feedparser
```
Create a Django project and app

Create a database table in models.py file with the necessary columns. For instance, for a news website, a database table could be something like this:

 # app/models.py
 from django.db import models

 # Create your models here
 class News(models.Model):
     title = models.CharField(max_length=200)
     pub_date = models.DateTimeField()
     link = models.URLField()
     site_name = models.CharField(max_length=100)

     def __str__(self) -> str:
         return f"{self.site_name}: {self.title}"

Run Django migrations to include your table in the database

 python manage.py makemigrations
 python manage.py migrate

To test the working of the feedparser, one can manually retrieve content from an RSS feed and display it in the terminal. To achieve this:

Start a terminal session inside your virtual environment
Import the feedparser library
Use the parse function to extract data from an RSS feed

In code,

(venv) python manage.py shell
>>> import feedparser
>>> data = feedparser.parse('some_rss_feed_url')
>>> site_name = data.channel.title
>>> print(site_name)

To make the project more robust and efficient, one can automate the data retrieval process. Additionally, it is paramount to implement a storage mechanism. For this purpose, it may be necessary to create a custom Django command.

A Custom Django Command

The file manage.py runs all commands within a Django project. It is possible to create a custom command in Django to utilize the manage.py file. To achieve this, the command should be created inside the project app directory in a subdirectory called management/commands. When the developer runs the manage.py file, it checks for custom commands in the directory and executes them. Furthermore, it is worth noting that all custom commands inherit from the BaseCommand object. Therefore, our command file should import BaseCommand.

Inside the app/management/commands directory:

Create a file with a suitable name that will contain the command code to execute
Import the necessary dependencies:
- BaseCommand object
- Feedparser library
- Your model
Create a command class that inherits from BaseCommand
Create a handle method that does two things:
1. Retrieves data from a feed
2. Stores the data in a database as illustrated below

# app/management/commands/news.py

from django.core.management.base import BaseCommand
import feedparser
from app.models import News

class Command(BaseCommand):
    # parses RSS feeds
    def handle(self, *args, **kwargs):
        feed = feedparser.parse("some_website_rss_feed_url")
        name = feed.channel.site

        # Stores parsed data in db
        for item in feed.entries:
            if not News.objects.filter(id=item.id).exists():
                news_item = News(
                    title=item.title,
                    pub_date=parser.parse(item.published),
                    link=item.link,
                    site_name = name
              )
              news_item.save()

With this set-up in place, when you execute the above command, the app will retrieve data from the specified RSS feed URL and store it in the database. One can access the model from the admin panel to inspect the data. To hook up URLs from several feeds into the project, follow this tutorial

Conclusion

The tutorial above discusses the main building blocks necessary to create a simple content aggregator website using Django. The main tools a developer needs are RSS feed URLs, clear understanding of the kind of data to retrieve from the RSS feeds, the feeparser library and a custom Django command. With these tools, the developer can conceptualize and construct a suitable data model, parse RSS feeds, and implement a command that handles how the data is stored in the project's database.

Servers, Application Servers and Web Servers. What are the distinctions?

Nick — Sat, 18 Nov 2023 06:02:57 +0000

Introduction

Understanding the differences between a server, a web server, and an application server can be challenging. In many cases, tech enthusiasts use the terms interchangeably. This article, targeted at newbies to the concept of servers, purposes to clarify the differences.

What is a Server

A server is broad term that computer professionals use to refer to a device that avails digital resources to other computers (clients) over a network. A server device could be a physical computer or a virtual machine.

Several types of severs exist. Web servers avails web pages to client computers. Application servers execute set functionalities for the client. Additionally, mail servers facilitate sending and receiving emails between clients. Furthermore, system engineers routinely configure servers to facilitate file storage and transfer, in which case the server becomes a File Transfer Protocol server.

Web Servers

A web server is a software device that serves web pages. This server type understands the Hyper Text Transfer Protocol communication; the server can communicate with client computers requesting web pages. A web server delivers static resources to clients. Static resources are digital content that are served as is, without any modification. Examples of popular web servers in the market include Apache and Nginx.

Application Servers

An application server is a software device that executes business logic. Business logic, in this case, refers to a website's core functionality. Consider an ecommerce website where customers can browse product listings. An application server runs the logic that involves the retrieval of product types from a database and display on the frontend.

Web Versus Application Servers

Web and application servers have one fundamental difference; web servers process static requests while application servers handle dynamic requests. As mentioned, servers deliver static resources to the client unchanged. Comparatively, when a client requests a dynamic resource—could be a list of the available products in an ecommerce website—an application server performs modifications on the existing resources to deliver the right content to the client.

Conclusion

To recap, a server is a physical computer or software component that hosts several software capable of serving web pages, mails, files and running business logic. A web server is a software device that servers web pages. An application server runs business logic. Furthermore, the basic difference between a web and application server is in the nature of resources they serve.

How to Initiate the Development Environment when building a Django App

Nick — Mon, 13 Nov 2023 10:15:56 +0000

Introduction

Django is a versatile web development framework. Many top companies, including Instagram, FireFox and Spotify use the framework to develop their websites. Django is useful when developing complex, large-scale web apps. However, many developers use it to create simple web apps. This tutorial guides new Django developers on how to set up a Django development environment to create their web apps. The tutorial will guide on how to set up a Django app in both Windows and Linux environments.

Prerequisites: Ensure you have a Python version 3.4+ installed on your system.

Setting up a Django application involves two major steps:

Setting up a Python virtual environment
Starting a Django project

Jump to Windows set-up
Jump to Linux set-up

Windows set-up

This set-up assumes you are running Windows 10

Follow these steps for Windows set up:

Create a project folder in your windows file system.

For example, create the folder named django_app in your desktop directory
Start a Windows terminal
1. Press Win + R to open a dialog box
2. Type cmd then press enter
Navigate to the project folder

cd Desktop\django_app
Create a virtual environment

Run python -m venv my_env

Note: my_env is a custom name you give to your virtual environment
Activate the virtual environment

Run .\my_env\Scripts\activate
Install Django using pip

pip install django
Start a Django project

Run django-admin startproject django_app .

Note: django_app is a custom name you give to your project.

Do not forget the dot at the end of the command or you may run into some configurations problems when deploying your app.
Change into the Django project directory

cd django_app
Create your Django application

Run python manage.py startapp my_first_app

Note: my_first_app is a custom name of the specific Django application you are creating
Add your application in the project's settings.py file
1. Locate a file named settings.py within your project folder. Hint: You can locate it manually within your project folder. It should be in a subdirectory with a similar name to your project.
2. Open the settings.py file using a code editor
3. Locate a section called INSTALLED_APPS
4. Add the name of your Django application at the end
5. Save and close the settings.py file
Create your app's database schema
1. Return to your terminal
2. Run python manage.py migrate
Note: It is necessary to run this operation to create a database that the app can work with
Start a development server

In your terminal, with the virtual environment still active, run python manage.py runserver

Note: The operation will start a local development server on port 8000
View your project in a browser

Open a browser and enter the URL http://127.0.0.1:8000/

Linux set-up

This set up assumes you are running an ubuntu version 20.04+

Open an ubuntu shell on your system
Create a project directory and switch into the directory

mkdir django-project && cd django-project
Create a virtual environment

python3 -m venv my_env
Activate the virtual environment

source my_env/bin/activate
Install Django using pip

pip install django

To install a specific Django version

pip install django==3.2.21
Start a Django project

django-admin startproject django_project
Switch into the Django project directory

cd django_project
Start a Django application

python3 manage.py startapp django_app
Add the new application to your settings.py file
1. Locate a file, settings.py within your shell
2. Open the file using a code editor
3. Locate a section named INSTALLED_APPS
4. Add 'django_app'at the end of installed apps list
5. Save and close the settings.py file
Create a database

python3 manage.py migrate
Start a development server on port 8000

python3 manage.py runserver
View your project in a browser

Run http://127.0.0.1:8000/

Conclusion

By following either steps depending on your operating system, you will have created a basic Django web application. Note that this is only a basic application, without any features. You need to build on the basic application by customizing it further to suit your project's needs or client's specifications

What Happens When you Type google.com in your Browser and Press Enter?

Nick — Fri, 10 Nov 2023 15:42:03 +0000

Introduction

Ever wondered what goes on “under the hood” when you type ‘google.com’, or any other phrase, into your browser’s address bar and press enter? Many people not familiar with web development are curious about the inner workings of a website. By reading this blog, readers from a non-technical background will gain a deeper understanding of the technologies that power their popular websites.

Website architecture (or web architecture) refers to the organization and structure of a website. Readers need to perceive the basic structure of a website to facilitate understanding. The web architecture consists of several components:

Client-Server Model: Is the fundamental structure of a website. A typical website assumes a client-server model. In this model, clients (web browsers) request resources from servers. Servers receive the client’s Hyper Text Transfer Protocol (HTTP) requests, process them and send specified resources back to the client, or perform an action.

Front-end: Is the user facing end of the website, for example a Chrome browser’s window.

Backend: Is a set of logic (code) that runs the website away from the front-end. The backend code processes requests coming from the front-end.

Database: Is a component that stores a website application’s data, such as user credentials.

Understanding the basic parts of a website creates a vivid visualization. A good understanding will help you follow along as this blog discusses the processes that run in the individual components.

Typing ‘google.com’ in your browser

When you type ‘google.com’ in your browser, you are essentially requesting a resource from one of several thousand Google servers. Clients can request several types of resources from Google servers. The resource ‘google.com’ is a static content, which is Google’s search engine main page.

The phrase ‘google.com’ is a domain name. A domain name is a human-readable and memorable address that a browser uses to identify and locate a server on the World Wide Web. Technically, a browser identifies a server by an Internet Protocol (IP) address and not a domain name. Therefore, when you type a domain name and press enter, the browser performs a Domain Name System (DNS) lookup. This process converts the wordy domain name into an IP address. Once the browser locates a server with the IP address specified in the address bar, the browser establishes a connection.

Manufacturers routinely configure client computers and servers with firewalls. Firewalls are software or hardware components that scrutinize website traffic to determine malicious content. Firewalls can allow or restrict outgoing requests and incoming server responses. Assuming both your web browser and the Google server contain non-restrictive firewall configurations for your type of request, they will establish a connection once the browser locates the server.

Computers need a communication method to facilitate the exchange of information. The Internet Assigned Numbers Authority (IANA) establishes and maintains a suite of computer communication protocols. The IANA protocols facilitate communication between computers of different architectures and operating systems. Your web browser communicates with a Google server using a communication protocol known as Transmission Control Protocol/Internet Protocol (TCP/IP). This communication standard governs the way data is transmitted between the two computers over the internet.

HTTP requests are human-readable, which poses a data security risk. Computer communications need to be discreet to prevent malicious actors from intercepting and deciphering communication in-between. For security purposes, browser and server manufacturers configure their software components with a security feature that allows the encryption of the data transmitted back and forth. This feature, known as the Secure Socket Layer (SSL), encrypts your HTTP request in transit and only decrypts it at the destination server.

Billions of people use the Google Search Engine daily, which can overload the servers. Companies that process such huge web traffic use software or hardware devices known as load balancers to distribute traffic between the different servers. This distribution solution aims to ease up workload on individual servers. Google engineers configure load balancers with distribution algorithms to route traffic from web browsers to various servers. Therefore, a load balancer will route your ‘google.com’ request to a server that can efficiently handle the request, based on factors such as server load and geographical location.

Once your request hits a server, the server will start processing it. A typical server contains within it a web server, an application server and a database. A web server processes static content. The server usually sends a static resource back to the client in an unchanged state. Static content includes HTML, CSS, JavaScript, and images files.

Servers also host dynamic content. A web server forwards dynamic content requests to an application server for further processing. An application server contains the server-side logic—a set of instructions to manage dynamic requests and route requests within the web framework).

Additionally, servers host databases that store an application’s data. A typical web application could store users’ login credentials in the database. Servers can host several categories of databases.

Conclusion

To recap, when you request ‘google.com’ from your web browser, the web browser will conduct a DNS lookup using the domain name to connect to a Google server where the requested resource lives. An SSL feature in your browser will encrypt the request data. A TCP/IP protocol will then transmit the request data through the internet to a Google server. A load balancer will route your request to a server. A web server will then process the request since you are requesting a static content. The server will return an encrypted response to your web browser. Your browser will then decrypt, render and display the response. Finally, your browser and server will close the connection.

DEV Community: Nick

Integrate Google OAuth2 Social Authentication into your Django Web App

Introduction

Prerequisites

Building your Project

Getting Started

Setting up your Development Environment.

Now we Build

Create a User Data Model

Integrate Google OAuth2

Include allauth URLs

Set up an App in Google Developer Console

OAuth consent screen

Set up Credentials

Set up a Social Account Provider

Testing and Troubleshooting

Conclusion

How to Deploy your FastAPI Backend with PostgreSQL Database to Render

Introduction

Prerequisites

Pre-Deployment

Deployment Checks

1. Create a requirements.txt file

2. Create a .env file

3. Create a .gitignore file

4. Create a build.sh file

5. Initialize a Github repository and push your code to Github

Deployment

Set up a PostgreSQL Database on Render

Create a Web Service

Conclusion

Do not Reinvent the Wheel: Utilize Django’s Built-in Auth App to Create a Robust Authentication System

Introduction

Prerequisites

Django's Auth App

Implement Login and Logout

A Simple Homepage

Create a simple login

Implement Logout

Configure Sign Up

Conclusion

Containerize your Django Web Application with Docker

Introduction

Prerequisites

Setting up Docker on Windows

But Before we Build…

Now we Build...

Create a Basic Django application

Pipfile and Pipfile.lock

A Containerized Blog App

Build your Image

Building within Docker

A Summary of Steps

Conclusion

The Django ORM: The Magic between the Application and the Database

Introduction

A Brief Overview

Django ORM Methods

Filtering Methods

.filter(**kwargs)

.excludes(**kwargs):

.get(**kwargs):

.first()

.last():

Aggregation Methods

aggregate(*args, **kwargs):

.count()

.exists()

Ordering Methods

Update and Delete

Other Methods

Conclusion

Understanding Http Redirections in Django

Introduction

How to Read this Article

Why Redirect URLs?

When Redesigning your Website URLs

When Implementing a URL shortening functionality.

When Re-routing Web Traffic to HTTPS

When Enforcing Authentication and Authorization

`.filter(**kwargs)`

`.excludes(**kwargs):`

`.get(**kwargs):`

`.first()`

`.last()`:

`aggregate(*args, **kwargs)`:

`.count()`

`.exists()`