You can watch the video tutorial or read the text below.

Generate SSH Keys for GitHub

If you are a windows user or you face any difficulty while generating your ssh keys, you can follow this tutorial and come back to proceed further steps.

First, open your terminal and run

ssh-keygen -t rsa -b 4096 -C "youremail@domain.com"

Replace "youremail@domain.com" with your email

It will ask you a few questions, keep on pressing enter till you get the output something like below.

Generating public/private rsa key pair.
Enter file in which to save the key (/home/nitin/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in id_rsa
Your public key has been saved in id_rsa.pub
The key fingerprint is:
SHA256:5asd2MT5gasdUvqhKhmKsad2qasdSfSQ/ZPgtxVbxjFhfu/U raturi888@gmail.com
The key's randomart image is:
+---[RSA 4096]----+
| ..o. .+.  .     |
| .=  +o = . .    |
|  .++. . +.. .   |
| ..+.o . o  o .  |
|o...+ . D =.   F |
|+.oo .   * o     |
|==+ .     =      |
|A= .       .     |
|*=+              |
+----[SHA256]-----+

Now run the below command to print the key on the screen.

cat ~/.ssh/id_rsa.pub

Now copy the output generated.

ssh-rsa AA21adasdasd+VvPxRRYZ7EI354FsLXrsPX97K0XhstPhL3IOKhKUUmD0XuIw7CgNyJuQB7DN1keAM4JPgcfhlzA78RuVJAuUm4MqKrjworsDt4h1olj14FiEu0qpasdasdsadsadwrLGfLEeasdsadasdasdasdT6rqkvnjiIS4iugpbXRK/ykdmNKvBr3ijKmELIuoz5pH32ghDiPwX9u65R0Ss8CYqnODzuE7UxjryNDjyYhCo10TPhFaIwNPu8EP5FzaHBUiN6dm6D7mtORrGtZ8Hhtr5s9rxcuTIc0m1H9rZE799/nyI46Te72CPmNJFnaDT+asdasdasd4aX+CbJEEkQ== raturi888@gmail.com

Adding SSH Keys to Github

Github SSH keys are added inside the SSH and GPG keys settings

Follow the steps below to open SSH and GPG keys settings

• Visit github.com and log in.

• Click on the profile icon on the top right and click on settings.

• Now from the left sidebar click on the SSH and GPG keys

• You can also click here to open the SSH/GPG settings directly.

To add the key, click on New SSH key button at the top right, it will open up a form to fill the key.

• In this Title field, enter any name to differentiate your key from the keys you will enter in the future

• In Key field paste the key you copied earlier.

• Finally, click on Add SSH Key button

Setting Up Git Repository for using with SSH Protocol

If you are cloning a new repository then select the ssh tab while cloning

If you already have the repository cloned then follow the steps below:

• Open your terminal, change your directory to the cloned repository, and use the below command.

• git remote set-url origin git@github.com:<github username>/<repository name>

• Don't forget to change gitusername, repositoryname to yours, like I have set mine below

• git remote set-url origin git@github.com/nitinraturi/django-structure

Now ssh keys are set up, you can try pushing them to your Github repository, you will not be asked for a username and password.

I hope, by now you should be able to add ssh keys to your Github account.

You can follow this tutorial to learn basics of Github.

How to remove git commit history

Our approach is to tell Git that your current commit is the initial commit. For that first checkout to the commit, which you want to make as the initial commit. Then run the following commands :

git checkout --orphan latest_branch

git add -A

git commit -am "Initial commit message" #Committing the changes

git branch -D master #Deleting master branch

git branch -m master #renaming branch as master

git push -f origin master #pushes to master branch

git gc --aggressive --prune=all # remove the old files

The above commands will forcefully push the current source code to the master branch as the first command.

Note: You should delete all other branches and tags, because they may still contain the old history.

Django queryset can be converted to a list using the python's built-in list method (list(queryset.objects.all())) but note that it is not ideal to load the whole result into memory via list() in terms of memory and time optimization.

Let's cover other approaches we can work to convert django queryset to list.

Django queryset to list using list() method

Python's built-in list() method to convert a queryset to a list is not an optimized approach as this will load all the objects in your memory.

from apps.blog.models import *
articles = Blog.objects.all()

# This will return a queryset type
print(type(articles))

# Convert articles queryset to a python's list type
articles_list = list(articles)

# This will return a list type
print(type(articles_list))

<class 'django.db.models.query.QuerySet'>
<class 'list'>

Django Queryset to list using values_list() method

Django's built-in model.objects.values_list() method is one of the ideal ways of converting a queryset to a list.

It returns tuples when iterated over. Each tuple contains the value from the respective field or expression passed into the values_list(). For example:

from apps.blog.models import Blog
articles = Blog.objects.values_list()
print(articles)
print(list(articles))

<QuerySet [(32, 'List of useful websites for software engineers', 5, 'list-useful-websites-software-engineers', None, datetime.date(2022, 3, 3), datetime.date(2022, 4, 20), 18, 'List of useful websites for software engineers', '', None, 1, True, <StreamValue [<block richtext: <wagtail.core.rich_text.RichText object at 0x7f61cefeb20>>]>)]>

[(26, 'List of useful websites for software engineers', 5, 'list-useful-websites-software-engineers', None, datetime.date(2022, 3, 3), datetime.date(2022, 4, 20), 18, 'List of useful websites for software engineers', '', None, 1, True, <StreamValue [<block richtext: <wagtail.core.rich_text.RichText object at 0x7f61cefeb20>>]>)]

If you only want single values in a list, then you have to pass a single field and a flat parameter set as True.

from apps.blog.models import Blog

articles = Blog.objects.values_list('id',flat=True)
print(articles)
print(list(articles))

<QuerySet [87, 83, 35, 84, 86]>
[87, 83, 35, 84, 86]

If you want multiple values in a list, then you have to pass multiple arguments in values_list().

from apps.blog.models import Blog

articles = Blog.objects.values_list('id','category')
print(articles)
print(list(articles))

<QuerySet [(87, 18)]>
[(87, 18)]

If you want to read about Django queryset in detail then I want you to go through this guide on Django ORM in detail.

For example: You have a website tech.raturi.in and there is a query parameter mob=false i.e.,

http://tech.raturi.in/?mob=false

, that is used to render a mobile site. So everytime you have to modify your url mob=false and mob=true. Imagine if you have 10 or 20 or more, is not this a head ache to change the parameters everytime to render a different page. If you are having a similar kind of problem or is related than this extension is for you.

Refer to the github repo

Installation

• Open extension on store

• Click Add To Chrome

Usage

• To use it you have to create action buttons once.

• To create an action button, fill in the unique action name and action value with the query parameters you want attach in your urls whenever an action button is clicked.

• Dont include ? in your action value.

• Example for action value: m=t&a=t

• Now you can see an action button has been created. Click on it and thats it.

Contribute

If you found any bugs or have any improvements for this utility dont forget to contribute. Just create a pull request whenever you feel is the right time.

Repository Link

Prerequisite: Understanding Django’s class-based views is required before exploring Mixins.

How Mixin works in Django

Let me take an example, to help you understand the working of a mixin.

Suppose you want only logged-in users to have access to an URL. For this, you can use Django's built-in LoginRequiredMixin in your view, just like the code snippet below.

 from django.contrib.auth.mixins import LoginRequiredMixin

class MyView(LoginRequiredMixin, View):
    login_url = '/login/'
    redirect_field_name = 'redirect_to'

LoginRequiredMixin overrides one or more methods of the View class to achieve this functionality. You don't need to delve into the exact methods at this point for the sake of simplicity of this tutorial, this is just to give an idea of how mixin works. You will get a clear understanding, once you create a custom mixin.

Create a custom mixin in Django

Let's create a mixin that redirects a user based on some condition.

Before that, you need to know why to create a mixin. Well, if you don't create a mixin then you have to write the redirect logic to every view and also if you have to update redirect logic at a later point of time then you have to make changes at every view.

In Django's class-based views, there is a method called dispatch, that you will have to override to achieve any mixin-related functionality.

Let's consider the below code snippet as your view that is called when a user logged in.

from django.views.generic import TemplateView

class LoginView(TemplateView):
    template_name="account/login.html"

Now you have to create two python classes to create the redirect mixin. First, create a GENERIC mixin to be used by any other mixin for redirecting.

from django.core.exceptions import ImproperlyConfigured
from django.shortcuts import redirect

class RedirectMixin:
    """
    Redirect to redirect_url if the test_func() method returns False.
    """

    redirect_url = None

    def get_redirect_url(self):
        """
        Override this method to override the redirect_url attribute.
        """
        redirect_url = self.redirect_url
        if not redirect_url:
            raise ImproperlyConfigured(
                '{0} is missing the redirect_url attribute. Define {0}.redirect_url or override '
                '{0}.get_redirect_url().'.format(self.__class__.__name__)
            )
        return str(redirect_url)

    def test_func(self):
        raise NotImplementedError(
            '{0} is missing the implementation of the test_func() method.'.format(self.__class__.__name__)
        )

    def get_test_func(self):
        """
        Override this method to use a different test_func method.
        """
        return self.test_func

    def dispatch(self, request, *args, **kwargs):
        test_result = self.get_test_func()()
        if not test_result:
            return redirect(self.get_redirect_url())
        return super().dispatch(request, *args, **kwargs)

The above RedirectMixin class has two important things that make it a mixin, redirect_url which is going to be used by the final view, and test_func which is going to be used by the next specific redirect mixin.

Now create a mixin that uses the above RedirectMixin to redirect authenticated users.

class LoggedInRedirectMixin(RedirectMixin):
    def test_func(self):
        return self.request.user.is_authenticated

Notice, in the above LoggedInRedirectMixin, RedirectMixin is inherited and the test_func() method is overridden.

test_func() is a very important method here, as all the redirect logic is placed inside it.

Now you have created a mixin, which is going to be used in the LoginView you considered initially. Remember!

Note: You can create as many as mixins like LoggedInRedirectMixin based on different conditions, just try to create more generic ones as it's the whole purpose of creating mixins.

Finally, you can use this mixin just by inheriting it.

from django.views.generic import TemplateView

class LoginView(LoggedInRedirectMixin,TemplateView):
    template_name="account/login.html"
    redirect_url = "/some-url/"

Don't forget to add the redirect_url attribute in your view. Set it to the URL you want to redirect authenticated users.

You have successfully created a custom mixin. The next section covers a few of the built-in mixins in Django, you can skip 🚀 it if you are here only for custom mixins.

Types of Mixins

In Django, there are two types of mixins: built-in mixins, and custom mixins.

Custom Mixins: These are the mixins created by a user for their specific purpose just like the above LoggedInRedirectMixin.

Built-in Mixins: These are the default mixins that come with Django to provide out-of-the-box functionalities. Here are a list few built-in mixins in Django.

• LoginRequiredMixin

• TemplateResponseMixin

• SingleObjectMixin

• MultipleObjectMixin

• FormMixin

You can learn more about built-in class-based mixins in Django from official docs.

Example of Mixins

• JSONResponseMixin

JSONResponseMixin

Suppose you are writing a set of APIs and each view should return JSON instead of plain HTML. I am taking this code snippet from official Django documentation.

from django.http import JsonResponse

class JSONResponseMixin:
    """
    A mixin that can be used to render a JSON response.
    """
    def render_to_json_response(self, context, **response_kwargs):
        """
        Returns a JSON response, transforming 'context' to make the payload.
        """
        return JsonResponse(
            self.get_data(context),
            **response_kwargs
        )

    def get_data(self, context):
        """
        Returns an object that will be serialized as JSON by json.dumps().
        """
        # Note: This is *EXTREMELY* naive; in reality, you'll need
        # to do much more complex handling to ensure that arbitrary
        # objects -- such as Django model instances or querysets
        # -- can be serialized as JSON.
        return context

Use this mixin in your view like this

from django.views.generic import TemplateView

class JSONView(JSONResponseMixin, TemplateView):
    def render_to_response(self, context, **response_kwargs):
        return self.render_to_json_response(context, **response_kwargs)

More examples will be added in the future in this post.

There are two modern ways to create a custom user model in Django: AbstractUser and AbstractBaseUser. In both cases, we can subclass them to extend existing functionality.

However, AbstractBaseUser requires much, much more work. So here we will use AbstractUser.

We will also create a UserProfile model to store additional information about users with the help of a One-To-One Link. After this, we will extend the BaseUserManager functionality a little bit. We will also configure signals to automatically create UserProfile whenever a User object is created. Finally, we will customize the Django admin.

Note: This should be done at the begining of the project before running any migrations.

Step 1: New app

• Create app users using the command python manage.py startapp users

• Now register your app in your installed apps in settings.py: INSTALLED_APPS += [ 'users', ]

• Set AUTH_USER_MODEL in settings.py to the new user model: AUTH_USER_MODEL = 'users.User'

Step 2: Extend model and manager

Create a file constants.py inside users app directory

# users/constants.py
SUPERUSER = 1
STAFF = 2
STUDENT = 3
TUTOR = 4

USER_TYPE_CHOICES = (
      (SUPERUSER, 'superuser'),
      (STAFF, 'staff'),
      (STUDENT, 'student'),
      (TUTOR, 'tutor'),
  )

Extend the User model in your users/models.py

# users/models.py

from django.contrib.auth.models import AbstractUser
from django.db import models
from django.utils import timezone
from apps.users.managers import UserManager
from . import constants as user_constants

class User(AbstractUser):
    username = None # remove username field, we will use email as unique identifier
    email = models.EmailField(unique=True, null=True, db_index=True)
    is_active = models.BooleanField(default=False)
    is_staff = models.BooleanField(default=False)
    date_joined = models.DateTimeField(default=timezone.now)
    user_type = models.PositiveSmallIntegerField(choices=user_constants.USER_TYPE_CHOICES)

    REQUIRED_FIELDS = []
    USERNAME_FIELD = 'email'

    objects = UserManager()


class UserProfile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE, primary_key=True,related_name="user_profile")
    phone = models.CharField(max_length=255,blank=True,null=True)
    is_verified = models.BooleanField(default=False)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self):
        return self.user.email

Extend UserManager in users/managers.py

# users/managers.py

from django.contrib.auth.models import BaseUserManager
from . import constants as user_constants


class UserManager(BaseUserManager):
    def create_user(self, email, password, **extra_fields):

        if not email:
            raise ValueError('The Email must be set')
        email = self.normalize_email(email)
        user = self.model(email=email, **extra_fields)
        user.set_password(password)
        user.save()
        return user

    def create_superuser(self, email, password, **extra_fields):
        extra_fields.setdefault('is_superuser', True)
        extra_fields.setdefault('is_staff', True)
        extra_fields.setdefault('is_active', True)
        extra_fields.setdefault('user_type', user_constants.SUPERUSER)
        if extra_fields.get('is_superuser') is not True:
            raise ValueError('Superuser must have is_superuser=True.')
        return self.create_user(email, password, **extra_fields)

Step 3: Migrations

Run the commands below to make database changes

python manage.py makemigrations 
python manage.py migrate

Step 4: Create Signal

Now let's create signals for automatically creating a UserProfile instance in users/signals.py

# users/signals.py
from django.db import models
from django.db.models.signals import post_save
from django.dispatch import receiver
from .models import UserProfile, User

@receiver(post_save, sender=User)
def create_or_update_user_profile(sender, instance, created, **kwargs):
    if created:
        UserProfile.objects.create(user=instance)
    instance.user_profile.save()

Now, register your signals file inside users/apps.py by adding a method ready and importing the signals file path.

# users/apps.py
from django.apps import AppConfig

class UsersConfig(AppConfig):
    name = 'apps.users'

    def ready(self):
        import apps.users.signals

Now, add default_app_config to users/init.py

# users/__init__.py
default_app_config = 'users.apps.UsersConfig'

Step 5: Extend the admin form

Let's extend UserCreationForm and UserChangeForm in users/forms.py

# users/forms.py
from django.contrib.auth.forms import UserCreationForm, UserChangeForm
from .models import User


class CustomUserCreationForm(UserCreationForm):

    class Meta(UserCreationForm):
        model = User
        fields = ('email',)


class CustomUserChangeForm(UserChangeForm):

    class Meta:
        model = User
        fields = ('email',)

Step 6: Customize Django user admin

Let's customize Django's admin now

# users/admin.py
from django.contrib import admin
from django.contrib.auth.admin import UserAdmin
from .models import UserProfile, User
from .forms import CustomUserCreationForm, CustomUserChangeForm


class UserProfileInline(admin.StackedInline):
    model = UserProfile
    can_delete=False
    verbose_plural_name="User Profile"
    fk_name = 'user'  

class CustomUserAdmin(UserAdmin):
    add_form = CustomUserCreationForm
    form = CustomUserChangeForm
    model = User
    list_display_links = ['email']
    search_fields = ('email',)
    ordering = ('email',)
    # inlines = (UserProfileInline,)
    list_display = ('email', 'is_staff', 'is_active', 'is_superuser',)
    list_filter = ('email', 'is_staff', 'is_active', 'is_superuser', 'user_type')
    fieldsets = (
        (None, {'fields': ('username', 'password')}),
        (_('Personal info'), {'fields': ('first_name', 'last_name', 'email','user_type')}),
        (_('Permissions'), {
            'fields': ('is_active', 'is_staff', 'is_superuser', 'groups', 'user_permissions'),
        }),
        (_('Important dates'), {'fields': ('last_login', 'date_joined')}),
    )
    add_fieldsets = (
        (None, {
            'classes': ('wide',),
            'fields': ('email', 'password1', 'password2', 'is_staff', 'is_active', 'user_type')}
         ),
    )

    def get_inline_instances(self, request, obj=None):
        if not obj:
            return list()
        return super(CustomUserAdmin, self).get_inline_instances(request, obj)

admin.site.register(User, CustomUserAdmin)

Step 7: Verifying

You have successfully extended the user model. Let's create a user

python manage.py createsuperuser

#output
Email: develop@raturi.in
Password: ..........
Password (again): ..........
Superuser created successfully

Your user should be created by now, login in to your admin panel to see.

That's all.

We will then set up Nginx to reverse proxy to Gunicorn, giving us access to its security and performance features to serve our apps.

Prerequisites

• You have an ubuntu server with sudo privileges

• You already have your Django application running.

Installation

First, we will install the required packages and libraries one by one.

Python

# Python3 Installation

sudo apt-get update
sudo apt-get install python3
sudo apt-get install python3-pip

# Now check python version installed
python -V

Python 3.5.2

# Replace x below with your python version second digit which is 5 in my case
# sudo apt install python3.x-dev
sudo apt install python3.5-dev

sudo apt-get install build-essential

Virtual environment

# [OPTIONAL]
# Virtual environment installation

sudo apt-get install virtualenv

# Create a virtual environment
virtualenv -p python3 venv

# Activate virtual environment
source venv/bin/activate

Follow the python installation guide if you face any issue while install from above code. For production its a ideal way to use virtual environment and environment variables.

Postgresql

# Install Postgresql
sudo apt-get install libpq-dev  
sudo apt-get install postgresql
sudo apt-get install postgresql-contrib

Nginx

# Nginx Installation

sudo apt update
sudo apt install nginx

Gunicorn

# Gunicorn Installation

pip install gunicorn

# Install Postgresql package for django

pip install psycopg2

Create the PostgreSQL Database and User

We’re going to jump right in and create a database and database user for our Django application.

By default, Postgres uses an authentication scheme called peer authentication for local connections. Basically, this means that if the user’s operating system username matches a valid Postgres username, that user can log in with no further authentication.

During the Postgres installation, an operating system user named postgres was created to correspond to the postgres PostgreSQL administrative user. We need to use this user to perform administrative tasks. We can use sudo and pass in the username with the -u option.

Log into an interactive Postgres session by typing:

sudo -u postgres psql

You will be given a PostgreSQL prompt where we can set up our requirements. First, create a database for your project:

CREATE DATABASE myproject;

Next, create a database user for our project. Make sure to select a secure password:

CREATE USER myprojectuser WITH PASSWORD 'password';

Afterward, we’ll modify a few of the connection parameters for the user we just created. This will speed up database operations so that the correct values do not have to be queried and set each time a connection is established.

We are setting the default encoding to UTF-8, which Django expects. We are also setting the default transaction isolation scheme to “read committed”, which blocks reads from uncommitted transactions. Lastly, we are setting the timezone. By default, our Django projects will be set to use UTC.

These are all recommendations from the Django project itself

ALTER ROLE myprojectuser SET client_encoding TO 'utf8';
ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';
ALTER ROLE myprojectuser SET timezone TO 'UTC';

Now, we can give our new user access to administer our new database:

GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

When you are finished, exit out of the PostgreSQL prompt by typing:

\q

Setting Up Django

We need to configure settings.py and main urls.py

Next, find the section that configures database access. It will start with DATABASES. The configuration in the file is for an SQLite database. We already created a PostgreSQL database for our project, so we need to adjust the settings.

Change the settings with your PostgreSQL database information. We tell Django to use the psycopg2 adaptor we installed with pip. We need to give the database name, the database username, and the database user’s password, and then specify that the database is located on the local computer. You can leave the PORT setting as an empty string:

# /myproject/myproject/settings.py

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'myproject',
        'USER': 'myprojectuser',
        'PASSWORD': 'password',
        'HOST': 'localhost',
        'PORT': '',
    }
}

Configure staticfiles path and url.py

# settings.py

# You can set your own path or you can do the same

STATIC_URL = '/static/'
STATICFILES_DIRS = [os.path.join(BASE_DIR, "static")]
STATIC_ROOT = os.path.join(BASE_DIR,"static_root")

MEDIA_URL = '/media/'
MEDIA_ROOT = os.path.join(BASE_DIR,"media_root")

NOTE: Your project will probably also have static assets that aren’t tied to a particular app. In addition to using a static/ directory inside your apps, you can define a list of directories (STATICFILES_DIRS) in your settings file where Django will also look for static files.

# urls.py

from django.conf import settings
from django.conf.urls.static import static

if settings.DEBUG:
    urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
    urlpatterns += static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)

If your debug=False, then run the command to collect all static files to your static root

python manage.py collectstatic

Finally test your project, by running:

python manage.py runserver 0.0.0.0:8000


# Make sure you have your ssh service running.
# By default when [ufw](https://tech.raturi.in/how-set-firewall-ufw-ubuntu-debian/) is enabled it blocks ssh, which means you cannot log in to the server. 
# Do not close your terminal and start your ssh service by running:

sudo service ssh start or sudo service ssh restart
sudo ufw allow OpenSSH or sudo ufw allow 22

# If you have your ssh port something else then mention your port number
# sudo ufw allow <portnumber>

Note: If you are facing any problem related to port or firewall which might have blocked your port, checkout the ufw firewall tutorial.

Testing Gunicorn’s Ability to Serve the Project

gunicorn --bind 0.0.0.0:8000 yourproject.wsgi:application

Note: Change yourproject above to the name of your project folder where wsgi.py is located, basically its in the same folder where settings.py is located.This will start Gunicorn on the same interface that the Django development server was running on. You can go back and test the app again.

We passed Gunicorn a module by specifying the relative directory path to Django’s wsgi.py file, which is the entry point to our application, using Python's module syntax. Inside of this file, a function called application is defined, which is used to communicate with the application.

Creating Gunicorn service file

Open the file in: /etc/systemd/system/gunicorn.service and paste the following:

[Unit] 
Description=gunicorn daemon 
After=network.target 

[Service] 
User=ubuntu 
Group=www-data 
WorkingDirectory=/path/to/yourproject-directory 
ExecStart=path/to/venv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/path/to/project/project.sock yourproject.wsgi:application 

[Install] 
WantedBy=multi-user.target

Note: Replace WorkinDirectory , ExecStart path to your path

Now save and close the file. Next, load your service file using:

sudo systemctl daemon-reload

Now start your service by:

sudo service gunicorn start

By now, a socket file should have been created at your specified WorkinDirectory path: /path/to/project/project.sock if not, verify the process again and then proceed further To check gunicorn status, run:

sudo service gunicorn status

Configure Nginx to Proxy Pass to Gunicorn

Now that Gunicorn is set up, we need to configure Nginx to pass traffic to the process. Start by creating and opening a new server block in Nginx’s sites-available directory:

sudo nano /etc/nginx/sites-available/yourproject

Inside, open up a new server block. We will start by specifying that this block should listen on the normal port 80 and that it should respond to our server’s domain name or IP address:

Next, we will tell Nginx to ignore any problems with finding a favicon. We will also tell it where to find the static assets that we collected in our ~/myproject/static directory. All of these files have a standard URI prefix of /static, so we can create a location block to match those requests:

Finally, we’ll create a location / {} block to match all other requests. Inside this location, we'll include the standard proxy_params file included with the Nginx installation and then we will pass the traffic to the socket that our Gunicorn process created:

server { 
listen 80; 
server_name server_domain_or_IP; 
location = /favicon.ico { 
access_log off; log_not_found off; 
} 
location /static { 
alias /your-static-root-path/; 
}
location /media { 
alias /your-media-root-path/; 
}  
location / { 
include proxy_params; 
proxy_pass http://unix:/your/socket-file-path/yourproject.sock; 
} 
}

• Note: Change server_name, server_domain_or_IP to your domain or IP. For example example.com or 192.168.1.0

• Note: Change alias** /your-static-root-path/ to your static_root** path. For example alias /home/nitin/project/static_root/

• Note: Change alias /your-media-root-path/ to your media_root path. For example alias /home/nitin/project/media_root/

• Note: change proxy_pass http://unix:/your/socket-file-path/yourproject.sock to your .sock file path

Save and close the file when you are finished.

Now, we can enable the file by linking it to the sites-enabled directory:

sudo ln -s /etc/nginx/sites-available/yourproject /etc/nginx/sites-enabled/

Test your Nginx configuration for syntax errors by typing:

sudo nginx -t

If no errors are reported, go ahead and restart Nginx by typing:

sudo service nginx restart

You should now be able to go to your server’s domain or IP address to view your application.

That's all. If you want to add HTTPS or SSL certificates to your website, check out this tutorial.

How does Django middleware work

Middleware in Django is a hook or a plugin system for altering request and response objects.

For example, let's say you have two types of users in your application i.e., free and paid.

There are few URLs or views that a free user cannot access, so in this case either you can handle free users at every view or you can create a middleware that can handle all the free users in one place.

Now, let's discuss the types of middleware in Django.

Types of Middleware in Django

Django's middleware can be divided into 2 types: built-in and custom.

Built-in Middleware: These are the default middlewares that come with Django. Few of the built-in middlewares are:

• Cache middleware

• Common middleware

• GZip middleware

• Message middleware

• Security middleware

• Session middleware

• Site middleware

• Authentication middleware

• CSRF protection middleware

Some default middleware from settings.py.

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

Custom Middleware: These are the middleware that a user creates for their purpose.

Now let's check out some of the built-in middleware.

Examples of Middleware in Django

Here, you will learn about a few of the built-in middlewares. This will help you create your custom middleware in the coming section.

Authentication middleware

Authentication middleware adds the user attribute, representing the logged-in user, to every incoming request object. If the user is not logged in then it will be set as an AnonymousUser object.

Session middleware

Session middleware helps you to store arbitrary data on a per-user basis like username, email, etc on the server side.

On every request and response, a session_id is attached to the cookies that you can check in your browser through the console.

Every time a request is made, session middleware gets the stored session data for the particular session_id and attaches it to the request object.

Read more about the session middleware from the official doc.

Message middleware

Message middleware is used to display some notification message aka flash message to the user after form submission.

You can store the message to the request object in your view and then show the message on your front end. You can check out official documentation for detailed usage.

CSRF middleware

CSRF middleware prevents Cross-Site Request Forgery attacks by adding hidden fields like CSRF_TOKEN to the POST forms and later validating for the correct value.

Now let's focus on another important aspect of middleware i.e., ordering

Ordering of middleware in Django

Order of the middleware is very important because a middleware can depend on the other middleware. For example Authentication Middleware depends on Session Middleware to store the authenticated user in session (request.session['user']) therefore, it must be placed after session middleware.

Custom Middleware in Django

**Custom middleware in Django is created either as a function style that takes a get_response callable or a class-based style whose call method is used to process requests and responses. It is created inside a file middleware.py. A middleware is activated by adding it to the MIDDLEWARE list in Django settings. **

Very often you would have used request.user inside the view. Django wants user attribute to be set on request before any view executes. Django takes a middleware approach to accomplish this. So Django provides an AuthenticationMiddleware which can modify the request object.

%[

A middleware factory is a callable that takes a get_response callable and returns a middleware. A middleware is a callable that takes a request and returns a response, just like a view.

A middleware can be written in two ways

• As a function

• As a class

The first step is to create a file midleware.py inside your app. Mine structure looks like this after creating the file

custom_middleware/
├── admin.py
├── apps.py
├── __init__.py
├── middleware.py
├── migrations
│   └── __init__.py
├── models.py
├── tests.py
└── views.py

Now You can follow any of the two ways of creating a middleware as a class or as a function.

Django Middleware: As a function

You can use this function based middleware code snippet inside middleware.py

def simple_middleware(get_response):
    # One-time configuration and initialization.

    def middleware(request):
        # Code to be executed for each request before
        # the view (and later middleware) are called.
        print("before response")
        response = get_response(request)
        print("After response")
        # Code to be executed for each request/response after
        # the view is called.

        return response

    return middleware

Django Middleware: As a Class

You can use this class based middleware code snippet inside middleware.py

class SimpleMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
        # One-time configuration and initialization.

    def __call__(self, request):
        # Code to be executed for each request before
        # the view (and later middleware) are called.

        print("before response")
        response = self.get_response(request)
        print("After response")
        # Code to be executed for each request/response after
        # the view is called.

        return response

Activating Custom Middleware

Activating a middleware is very simple, you have to add it inside the MIDDLEWARE list in settings.py. In the middleware list, each middleware component is represented by a string that is the full python path of the middleware. You can add your SimpleMiddleware at the last of the middleware list.

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',

    'custom_middleware.middleware.SimpleMiddleware', # Class based custom Middleware
    'custom_middleware.middleware.simple_middleware', # Function based custom Middleware
]

Order of the middleware is very important because a middleware can depend on the other middleware. For example Authentication Middleware depends on Session Middleware to store the authenticated user in session (request.session['user']) therefore, it must be placed after session middleware.

After adding your middleware, run your server and visit the URL

http://localhost:8080/

python manage.py runserver 0:8080

Now check your terminal for the print statements.

Django version 3.2, using settings 'conf.settings'
Starting development server at http://0:8080/
Quit the server with CONTROL-C.
before response
After response

If you can see the print statements before response and After response, it means you have successfully created your own custom Django middleware.

You can check out this middleware.py file and all the implementation. You can also contribute new or different ways of making and working with middlewares in the same above repository.

Now, you can build a basic middleware but there is more about how Django's middleware works. Therefore let's understand the middleware structure.

Django Middleware Structure

First of all, middleware is a python class or object that is capable of processing each request and response object. Here is a complete structure of a middleware:

class SimpleMiddlewareStructure:

    def _init_(self, get_response):
        self.get_response = get_response

    def _call_(self, request):

        # Code that is executed in each request before the view is called

        response = self.get_response(request)

        # Code that is executed in each request after the view is called
        return response

    def process_view(self, request, view_func, view_args, view_kwargs):
        # This code is executed just before the view is called
        pass

    def process_exception(self, request, exception):
        # This code is executed if an exception is raised
        pass

    def process_template_response(self, request, response):
        # This code is executed if the response contains a render() method
        return response

Let's understand the structure and lifecycle of middleware.

You can also overwrite these methods instead of __call__ method:

• __init__(get_response)

• __call__()

• process_view(request, view_func, view_args, view_kwargs)

• process_exception(request, exception)

• process_template_response(request, response)

Let's cover each method one by one.

Only the first two methods, __init__ and __call__, are required by the Django framework for your middleware to work properly. The other three are special hooks that allow you to invoke your middleware under specific conditions. Therefore, the other three are optional.

Method 1: init() in middleware

The first method, init, is the constructor for our Python class. It is called only once, at the time the server starts up. It takes get_response as a parameter, which is passed by the Django itself when we add it inside the Middleware list like this: 'custom_middleware.middleware.SimpleMiddleware'

Method 2: call() in middleware

__call__() method is called once per request .This method invokes the middleware. Here is what it looks like:

def _call_(self, request):

        # Code that is executed in each request before the view is called

        response = self.get_response(request)

        # Code that is executed in each request after the view is called
        return response

You can add validation or feature to the request or response object before or after the view is called.

Method 3: process_view() in middleware

process_view() is called just before Django calls the view.

It should return either None or an HttpResponse object.

• If it returns None, Django will continue processing this request, executing any other process_view() middleware and, then, the appropriate view.

• If it returns an HttpResponse object, Django won’t bother calling the appropriate view; it’ll apply response middleware to that HttpResponse and return the result.

Method 4: process_exception() in middleware

Django calls process_exception() when a view raises an exception.

process_exception() should return either None or an HttpResponse object.

• If it returns an HttpResponse object, the template response and response middleware will be applied and the resulting response returned to the browser.

• Otherwise, default exception handling kicks in.

Method 5: process_template_response() in middleware

process_template_response() is called just after the view has finished executing if the response instance has a render() method, indicating that it is a TemplateResponse or equivalent.

It must return a response object that implements a render method. It could alter the given response by changing response.template_name and response.context_data, or it could create and return a brand-new TemplateResponse or equivalent.

That's all about middleware. I hope you like it.

In this article, we will discuss what signals are, how to create them, and some examples of how they can be used in Django applications.

What Are Signals?

Signals are a way for different parts of a Django application to communicate with each other. They allow one part of the application to send a message, or signal, to another part of the application when a particular event occurs.

Signals can be used to trigger actions when certain events happen within the application, such as when a user logs in or when a new record is added to the database. They can also be used to implement custom functionality, such as sending notifications or logging events.

Creating Signals in Django

To create a signal in Django, we need to define a sender and a receiver. The sender is the part of the application that sends the signal, while the receiver is the part of the application that receives the signal and responds to it.

Defining a Signal

To define a signal in Django, we first need to import the Signal class from the django.dispatch module. We can then create an instance of the Signal class, which will represent our signal.

from django.dispatch import Signal

my_signal = Signal()

In this example, we have created a signal called my_signal.

Connecting a Receiver

Once we have defined our signal, we need to connect a receiver to it. A receiver is a function that will be called when the signal is sent.

To connect a receiver to a signal, we use the receiver decorator provided by Django. The receiver decorator takes two arguments: the signal to which we want to connect the receiver, and the sender of the signal.

from django.dispatch import receiver

@receiver(my_signal, sender=MyModel)
def my_receiver(sender, **kwargs):
    # do something here

In this example, we have defined a receiver function called my_receiver. We have used the @receiver decorator to connect this function to our my_signal signal, and we have specified that the sender of the signal should be the MyModel class.

Sending a Signal

Now that we have defined our signal and connected a receiver to it, we can send the signal. To send a signal, we simply call the signal object and pass any data that we want to send with the signal.

my_signal.send(sender=MyModel, data="Hello, World!")

In this example, we are sending our my_signal signal and specifying that the sender of the signal is the MyModel class. We are also passing some data with the signal, which will be available to the receiver function when it is called.

Examples of Using Signals in Django

Now that we know how to create and use signals in Django, let's take a look at some examples of how they can be used in practice.

Logging User Actions

One common use case for signals is logging user actions. For example, we might want to log when a user logs in or logs out of our application.

To do this, we can create a signal that is sent when a user logs in or logs out. We can then connect a receiver function that will log the event to our application's logging system.

from django.contrib.auth.signals import user_logged_in, user_logged_out
from django.dispatch import receiver

@receiver(user_logged_in)
def log_user_logged_in(sender, request

Django Built-In Signals

Here are some examples of built-in signals that Django provides:

pre_save and post_save

The pre_save and post_save signals are sent before and after a model instance is saved to the database, respectively.

from django.db.models.signals import pre_save, post_save
from django.dispatch import receiver
from myapp.models import MyModel

@receiver(pre_save, sender=MyModel)
def my_pre_save(sender, **kwargs):
    # do something before MyModel is saved

@receiver(post_save, sender=MyModel)
def my_post_save(sender, **kwargs):
    # do something after MyModel is saved

In this example, we are defining two receiver functions, one for the pre_save signal and one for the post_save signal. Both of these functions are connected to the MyModel sender. The my_pre_save function will be called before the MyModel instance is saved to the database, and the my_post_save function will be called after the instance is saved.

pre_delete and post_delete

The pre_delete and post_delete signals are sent before and after a model instance is deleted from the database, respectively.

from django.db.models.signals import pre_delete, post_delete
from django.dispatch import receiver
from myapp.models import MyModel

@receiver(pre_delete, sender=MyModel)
def my_pre_delete(sender, **kwargs):
    # do something before MyModel is deleted

@receiver(post_delete, sender=MyModel)
def my_post_delete(sender, **kwargs):
    # do something after MyModel is deleted

In this example, we are defining two receiver functions, one for the pre_delete signal and one for the post_delete signal. Both of these functions are connected to the MyModel sender. The my_pre_delete function will be called before the MyModel instance is deleted from the database, and the my_post_delete function will be called after the instance is deleted.

user_logged_in and user_logged_out

The user_logged_in and user_logged_out signals are sent when a user logs in or logs out of the application, respectively.

from django.contrib.auth.signals import user_logged_in, user_logged_out
from django.dispatch import receiver

@receiver(user_logged_in)
def log_user_logged_in(sender, request, user, **kwargs):
    # log the user login event

@receiver(user_logged_out)
def log_user_logged_out(sender, request, user, **kwargs):
    # log the user logout event

What is python-decouple

python-decouple is a generic Python library that helps to organize settings (development, production, stage, etc) without having to redeploy the app.

It was specifically built for Django but now is used to manage multiple environments or settings across python development.

Here are the advantages of using python-decouple:

• You can store variables in .env or ini files.

• Setting default environment values.

• Conversion of environment values to correct data type.

Why not just use os.environ

It works, but since os.environ only returns strings, it’s tricky.

Let’s say you have an environment variable DEBUG=False. If you run

if os.environ['DEBUG']: 
  print(True) 
else: 
  print(False)

It outputs True, because os.environ['DEBUG'] returns the string "False". Since it’s a non-empty string, it will be evaluated as True.

Python Decouple provides a solution that solves this problem like this

from decouple import config
DEBUG = config('DEBUG', cast=bool)

Why use environment variables

A web application whether small or large will have a lot of app secrets such as SECRET_KEY, API keys, database credentials etc.

The convenient way for anyone to use these is to hardcode them in the source code. It works, but it is also the most insecure way. You often push the code to repositories for version management or share it among others resulting in exposing the app secrets.

The easiest and most secure way is to use these secrets as environment variables and import them directly into your app. Python decouple manages this for you. It also helps in managing application configurations and secrets based on the development environments.

How to install python decouple

You can install python-decouple using the command pip install python-decouple

Optional: If you are not using virtual environments to install third party packages, I would strongly advice you to learn about virtual environment to avoid version issues later.

How to use python decouple in django

Step 1: Create a .env file at the root level of your project

project
--- project
------ settings.py
------ urls.py
------ wsgi.py
--- .env

Step 2: Set your environment variables inside .env file, I have set mine like this:

DEBUG=True
SECRET_KEY=ARANDOMSECRETKEY
DB_HOST=HOSTNAME
DB_PASSWORD=PASSWORD

Step3: In your settings.py, access your environment variables like this:

from decouple import config

SECRET_KEY = config('SECRET_KEY')
DEBUG = config('DEBUG', cast=bool)

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': config('DB_NAME'),
     'USER': config('DB_USER'),
        'PASSWORD': config('DB_PASSWORD'),
        'HOST': config('DB_HOST'),
        'PORT':''
    }
}

That's it for setting up a basic configuration, if you want to know more have a look at the python-decouple official doc.

Note: Add .env file to .gitignore, every user should have their own seperate .env file which should not be pushed alongwith your repository.

A code snippet of python-decouple with django taken from the offical python-decouple doc.

# coding: utf-8
from decouple import config
from unipath import Path
from dj_database_url import parse as db_url


BASE_DIR = Path(__file__).parent

DEBUG = config('DEBUG', default=False, cast=bool)
TEMPLATE_DEBUG = DEBUG

DATABASES = {
    'default': config(
        'DATABASE_URL',
        default='sqlite:///' + BASE_DIR.child('db.sqlite3'),
        cast=db_url
    )
}

TIME_ZONE = 'America/Sao_Paulo'
USE_L10N = True
USE_TZ = True

SECRET_KEY = config('SECRET_KEY')

EMAIL_HOST = config('EMAIL_HOST', default='localhost')
EMAIL_PORT = config('EMAIL_PORT', default=25, cast=int)
EMAIL_HOST_PASSWORD = config('EMAIL_HOST_PASSWORD', default='')
EMAIL_HOST_USER = config('EMAIL_HOST_USER', default='')
EMAIL_USE_TLS = config('EMAIL_USE_TLS', default=False, cast=bool)

How to manage multiple django enviroment

Managing multiple environments is the most common requirement when we work in a team and across multiple servers like local or development, testing, staging, and production.

To solve this problem, you should have .env.template file at the root of your repository and this file should be pushed to your repository. Now any team member can follow this .env.template file to create .env file in their own system with their own set of values and the same with multiple servers.

That's it. I hope you can now manage environment variables.

In this article, I am assuming that you already have a Django website up and running using the Nginx web server on HTTP protocol. You can refer to the current Django project structure and deployment instructions if needed.

Note: This article is tested on the following tech stack: django, gunicorn, nginx, ubuntu 16. Steps are similar for other versions of ubuntu as well but if you get stuck somewhere, you can follow the instructions from the official documentation.

Install Certbot

First, ssh into your server as a sudo user and run the commands below to install certbot.

sudo apt-get update 
sudo apt-get install software-properties-common 
sudo add-apt-repository universe 
sudo add-apt-repository ppa:certbot/certbot 
sudo apt-get update sudo apt-get install certbot python-certbot-nginx

If you face issues while installing certbot via the above commands, install it via snapd otherwise directly jump to the next section. Follow these instructions to install snapd from the snapd official documentation.

Once snapd is installed, ensure that it's up to date

sudo snap install core; sudo snap refresh core

Remove the previously installed certbot packages via apt to avoid any conflict between apt and snap.

sudo apt-get remove certbot

Now, install certbot via snap.

sudo snap install --classic certbot

At last, link the installed snap to the user bin directory to access it globally.

sudo ln -s /snap/bin/certbot /usr/bin/certbot

Generating SSL certificates using certbot

Let certbot do this automatically, generating certificates and editing the Nginx config file to serve these certificates.

sudo certbot --nginx

Here, you will be asked to enter the names of the website you want to activate HTTPS for, something like this:

Which names would you like to activate HTTPS for? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
1: raturi.in 
2: www.raturi.in

Enter the corresponding number with a comma(,) if you have more than 1 website you want to add HTTPS and press enter. After that fill in the details, it asks, and proceed.

Finally, restart your Nginx server for the changes to reflect.

sudo service nginx restart

Now, visit your domain, you can check HTTPS there.

Note: If you don't want certbot to automatically edit your Nginx file, you can generate the certificates only using sudo certbot certonly --nginx and server these certificates manually.

Certbot Automating renewal

The Certbot packages on your system come with a cron job that will renew your certificates automatically before they expire. Since Let's Encrypt certificates last for 90 days, it's highly advisable to take advantage of this feature. You can test automatic renewal for your certificates by running this command

sudo certbot renew --dry-run