DEV Community: IOTA, IIITS

Host a Django website using Heroku

Ketan Lambat — Thu, 28 May 2020 08:56:50 +0000

Creating a website using the Django framework is among the most basic skills a web developer or a person interested in web-development has. If you want to get into it check this Django Tutorial

With your website done, you might want to show it to someone. But, it is a Django-based website, not just a few HTML-CSS pages with few static files that can be sent over mail. Of course, you can make it into a GitHub repo and share the URL to it, still, one need to clone the repo and then run the website using the command :

$ python manage.py runserver

A lot of hassle on both ends isn't it. What if you can just make a public URL for the website and use the URL alone to display your project. All this, without requiring any domain names or any paid servers as well.

Heroku is a cloud application platform that enables developers to build, run, and operate applications entirely in the cloud.

Prerequisites:

Set up the virtual environment and create your project there. If the virtual environment has not been set up initially, you can do so now by creating it and then installing all the project dependencies in it.

Create a Heroku Account

Confirm your email and set the password You should now get the Heroku Dashboard

Install the Heroku CLI

Confirm the installation using the command

(env)$ heroku --version

Get the migrations done:

(env)$ python manage.py makemigrations 
(env)$ python manage.py migrate

Add a Procfile

Heroku apps include a Procfile that specifies the commands that are executed by the app on startup.

Create a new file named "Procfile" (no file extension) in the project root (the folder where manage.py is located) and add the following content to it.

web: gunicorn {your-project-name}.wsgi —-log-file - 

example: 
web: gunicorn samplesite.wsgi —-log-file -

Ensure you replace samplesite with your project name (name of the folder containing the manage.py file)

The Procfile is a process file that tells the dyno (Lightweight Linux containers to run your application) the process to run for setting up your application.

web: gunicorn : start a web process using gunicorn, a production web server recommended for python applications.

samplesite.wsgi : to look for the wsgi (Web Server Gateway Interface) file inside the samplesite (your-project-name) folder

—-log-file - : log to stdout

Next, install gunicorn and django-heroku

(env)$ pip install gunicorn 
(env)$ pip install django-heroku

Create the requirements.txt file in the project root.

(env)$ pip freeze > requirements.txt

Create Heroku App

(env)$ heroku login

Confirm the Log In in the browser window which opens. You should get the following screen.

and the confirmation for the same in the terminal

Create Heroku App using terminal

You can choose any URL for the project (containing lowercase letters, digits & dashes only). If the heroku app name or the URL is not available you will get an error message.

(env)$ heroku create {project-url}

Alternative, using just

(env)$ heroku create

heroku will auto-generate a name for your app.

In settings.py
Add your app domain name to ALLOWED_HOSTS

ALLOWED_HOSTS = ['test-django-heroku.herokuapp.com']

Add this to the top of settings.py

import django_heroku

and this to the bottom of settings.py

 # Activate Django-Heroku. 
 django_heroku.settings(locals())

Setting up Heroku remote

We need to initialize a git repository to push the changes from the local machine on to the Heroku server.

(env)$ git init

add .gitignore

Create a .gitignore file with the following content (to prevent the cache from building up on the remote).

 # Environments 
 .env 
 env/ 
 # Django stuff: 
 __pycache__/ 
 *.log 
 *.pot 
 *.pyc 
 local_settings.py

Your project repo tree should be similar

env/
projectname/
    appname/     
    projectname/
        .      
        settings.py
        . 
    manage.py  
    Procfile
    requirements.txt
.gitignore`

Stage and commit the changes

(env)$ git add . 
(env)$ git commit -m "Project Initialized"

Add the Heroku remote

(env)$ git remote add heroku https://git.heroku.com/test-django-heroku.git

Make sure to change the git repo url with the one generated for your app. Check for the added remote using :

(env)$ git remote -v

Push the changes to the Heroku server

(env)$ git push heroku master

Here you might receive an error saying No default language could be detected for the app. So, use the following command to tell git to look for the project files in the projectname folder instead of the root of the git repo.

(env) git subtree push —-prefix projectname heroku master

You should get the following output for a successful deployment.

DONE! Your app is deployed and can be explored in the mentioned URL.

You can run the Django shell commands on the heroko app too using

heroku run bash

You will have the run the migrations on the heroku database as well

(env)$ heroku run python manage.py makemigrations 
(env)$ heroku run python manage.py migrate

Your app should now be listed on Heroku Dashboard

Explore the app and look out for what more can be done.

For serving the static files you will have to configure whitenoise, a static file service for python web-apps. The documentation explains it in a pretty straightforward manner.

Note: If you plan to use this hosted site for production and not just testing/demo purposes, ensure you use the PostgreSQL database as Heroku mentions it here.

Also, make sure to disable the DEBUG flags when in production mode.

C++ Templates and SFINAE

Ram Nad — Wed, 05 Feb 2020 17:42:28 +0000

Recently, I came across a problem while looking for good first issues on GitHub. I would like to share the problem and its solution with you in this post. Just for clarity, we would work with a simpler version of the problem.

Suppose there is a template class Container that takes a class as Backend conforming to a particular interface. This Container acts as a wrapper on the Backend providing it with extra functionalities.

template<typename Backend>
class Container {
    private:
    Backend b;
    int data;
    int data1, data2;

    public:
    Container(int data, int data1, int data2) : data(data), data1(data1), data2(data2) {}

    int get() {
        return b.getValue(data);
    }
};

Now all the Backends need to have the following particular function,

class Backend1 {
    public:
    int getValue(int data);
};

This function is called by a get() function inside our container. The problem is that we need to change this interface to add up new functionalities. So, we now need to call getValue() with 2 parameters, instead of 1. So, our interface should now be:

int getValue(int data1, int data2);

We cannot make this change suddenly, because many users and backends depend upon the old functionality. Therefore, for the backends that support new interface we will call getValue with two parameters else we would call it with one.

We need to somehow statically(that is at compile-time) detect if any backend supports the new interface we use it, else we should stick with older interface.

Now, this is where the magic of C++ templates come to picture.

class SupportedBackend {
    public:
    int getValue(int data1, int data2) {
        return data1 + data2;
    }
};

class UnsupportedBackend {
    public:
    int getValue(int data) {
        return data + 1;
    }
};

So, among above two backends, SupportedBackend supports new interface whereas UnsupportedBackend does not. (I could not come up with any other descriptive name)

Here, is the code that can do the work for us,

#include <type_traits>

template <class T>
class check_new_interface {
  template <class R>
  static auto check(int) -> decltype(std::declval<R>().getValue(0, 0));

  template <class>
  static double check(double);

 public:
  static constexpr bool value = sizeof(decltype(check<T>(0))) == sizeof(int);
};

check_new_interface<T>::value would be true if T supports new interface else it will be false.

Let us now understand the above code.

So, check_new_interface class has two template member functions with same name (but different signatures). Now the value of value depends upon the following expression: sizeof(decltype(check<T>(0))) == sizeof(int). This is where we need to understand a lot of things.

First, sizeof and decltype do not evaluate the expression they are called with. So, the following program would only print 4 (that is sizeof(int)) instead of hello4. (Did you notice that we did not define the check functions although we called it the above expression)

#include <cstdio>

int main() { printf("%lu", sizeof(std::printf("hello"))); }

Second, when C++ sees check<T>(0) expression, it trys to find a proper function declaration that matches this call. There are two options, so template function overload resolution comes into picture. As, 0 is an integer literal, so C++ would first try to associate this call with function that takes integer as its parameter. If it cannot do so it will then check other options. For example,

#include <iostream>

long echo_with_type(double a) {
  std::cout << "double: " << a << std::endl;
  return a;
}

void first_echo(int a) { echo_with_type(a); }

int echo_with_type(int a) {
  std::cout << "int: " << a << std::endl;
  return a;
}

void second_echo(int a) { echo_with_type(a); }

int main() {
  first_echo(2);
  second_echo(2);
  return 0;
}

If, you run the above code, you would find that first output would be double: 2 and second would be int: 2. This is because when first_echo function is called, it does not find any echo_with_type function with integer parameter so it calls the one which takes double as parameter, but second time it finds one with integer and therefore call its.

Similarly, in our situation for check<T>(0) compiler would try to substitute T into the first template before the second one (for similar reasons as above program). Now, this is where the real magic happens. When any type is substituted in place of R, then only if that type has a member function with signature getValue(int, int) the substitution would succeed. Else it will fail. So, in our case when we will substitute SupportedBackend then this substitution would be succeed but in case of UnsupportedBackend it will fail. (Sorry, I am skipping few details here, like what is declval and why we use it but we can get into that sometimes later.)

Now, if C++ did not support SFINAE, then the compiler would have thrown an error here. But luckily it does so we can continue.

SFINAE - Substitution Failure is not an Error

Basically SFINAE means that if a template substitution fails then compiler does not throw error but continues to find a valid template substitution until it succeeds. (If it does not find any then ofcourse it will throw error.)

So, in our case as well compiler continues to find a valid substitution for check<T>(0) [when T = UnsupportedBackend]. Because first template substitution failed, it will move to the second template and succeed. But when it succeeds for the second template then return type of check<T> would be double instead of int. (Where as in case of T = SupportedBackend it would be int)

So, it is clear that the check_new_interface::value would be true in case of SupportedBackend and false in case of UnsupportedBackend.

Now, we may be tempted to implement get() as follows:

int get() {
    if(check_new_interface<Backend>::value) {
        return b.getValue(data1, data2);
    } else {
        return b.getValue(data);
    }
}

But, compiler would give errors if we try to do this. The reason is although compiler knows for any given Backend whether if part will exceute or else part but it needs to generate code for both of them. So, obviously it will fail.

The solution again would be to use function overloading here. std::true_type and std::false_type are specialized types of class template std::integral_constant defined as following:

typedef std::integral_constant<bool, true> true_type;

typedef std::integral_constant<bool, false> false_type;

private:

inline int get(std::false_type) { return b.getValue(data); }

inline int get(std::true_type) { return b.getValue(data1, data2); }

public:

int get() {
return get(
    std::integral_constant<bool, check_new_interface<Backend>::value>());
}

Now, this would work flawlessly because, when compiler generates code for get() function then, it only needs to compile one of get(std::false_type) or get(std::true_type) depending upon the value of check_new_interface<Backend>::value.

So, finally we have our solution ready. You can find the complete code here.

I hope that you got to learn something new in this post. Thanks for reading.

Using Stream Builder in Flutter

Ashutosh Chauhan — Wed, 05 Feb 2020 11:43:00 +0000

Dart & Flutter was made with asynchronicity in mind. Dart provide really good support for Futures and Streams. For those who do not have a basic idea of asynchronous programming in dart can refer to this playlist.

We will create an App which will call an API after every second and update the page whenever the response is received, which would look something like below:

Lets start with creating a new Flutter Project.

Step 1: Create the project

You can use your favorite IDE (VS Code or any other) to start a new Flutter project. Once you have create a flutter lets edit the lib/main.dart. Keep the following code and remove everything else.

import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: Scaffold(),
    );
  }
}

Step 2: Requesting data from API

We will create a page which will show us the amount of likes a certain post has recieved. We won't be making the entire application only the Likes counter which will show us the amount of people who have liked a post. For simplicity we will use a dummy API which will repond with a random value.

Create a file lib/models.dart :

class Number {
  int value;

  Number(this.value);

  factory Number.fromJSON(Map<String, dynamic> json) {
    return Number(json['value']);
  }
}

We will use the class Number which will create a class from a json object.

Next, create another file lib/requests.dart :

import 'package:http/http.dart' as http;
import 'dart:convert';
import 'dart:async';
import 'models.dart';

Future<Number> getNumber({int num = 20}) async {
  http.Response res = await http.get(Uri.http("dummyresponse.pythonanywhere.com", "/api/$num"));
  return Number.fromJSON(json.decode(res.body));
}

Stream<Number> getNumbers(Duration refreshTime) async* {
  while (true) {
    await Future.delayed(refreshTime);
    yield await getNumber();
  }
}

The getNumber is an async method which waits for a network call to a dummy response server which generates a random number. (https://dummyresponse.pythonanywhere.com/api/31 will give random no. from 0 to 31)

The getNumbers method returns a stream which calls the API and retrieves the latest information, hence updating the information after every fixed duration.

Now, Since we have the stream let's get to the real stuff.

Step 3: Stream Builder

Create a new file lib/home_page.dart :

import 'package:flutter/cupertino.dart';
import 'package:flutter/material.dart';
import 'package:stream_builder_example/models.dart';
import 'package:stream_builder_example/requests.dart';

class HomePage extends StatefulWidget {
  HomePage({Key key}) : super(key: key);

  @override
  _HomePageState createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
          child: StreamBuilder(
        stream: getNumbers(Duration(seconds: 1)),
        initialData: Number(0),
        builder: (context, stream) {
          if (stream.connectionState == ConnectionState.done) {
            return Icon(
              Icons.check_circle,
              color: Colors.green,
              size: 20,
            );
          }
          if (stream.hasData) {
            return LikeCounter(stream.data.value);
          } else {
            return CircularProgressIndicator();
          }
        },
      )),
    );
  }
}

class LikeCounter extends StatelessWidget {
  static List<Color> colors = [ Colors.green, Colors.purpleAccent, Colors.deepPurple,  Colors.blueAccent, Colors.deepOrangeAccent ];
  final int num;

  LikeCounter(this.num);

  @override
  Widget build(BuildContext context) {
    return AnimatedContainer(
      duration: Duration(milliseconds: 250),
      padding: EdgeInsets.all(10),
      decoration: BoxDecoration(
        borderRadius: BorderRadius.circular(100),
        color: colors[num % colors.length],
      ),
      child: Row(
        mainAxisSize: MainAxisSize.min,
        children: <Widget>[
          Icon(Icons.favorite, color: Colors.white),
          Text(
            " $num Likes",
            style: TextStyle(color: Colors.white, fontSize: 20),
          ),
        ],
      ),
    );
  }
}

The LikeCounter is a stateless widget which shows the number of likes with different colors.

Let's see how the Stream Builder works.

StreamBuilder(
    stream: getNumbers(Duration(seconds: 1)),
    initialData: Number(0),
    builder: (context, stream) {
        if (stream.connectionState == ConnectionState.done) {
            return Icon(
                Icons.check_circle,
                color: Colors.green,
                size: 20,
            );
        }
        if (stream.hasData) {
            return LikeCounter(stream.data.value);
        } else {
            return CircularProgressIndicator();
        }
    },
)

The Stream builder needs mainly 3 parameters: stream, builder, and initialData. The initial is used as a dummy or empty element to act as the first element.

The builder method receives context and snapshot of the stream.

We can use stream.connectionState to find the status of the stream, details of state is given here.

We can use stream.hasData ad stream.data to build widget when the widget is build.

We can also use stream.hasError to build when an Error occurs.

Next, change the lib/main.dart and update HomePage() as Material App home :

import 'home_page.dart';

// ...   
return MaterialApp(
    title: 'Flutter Demo',
    theme: ThemeData(
        primarySwatch: Colors.blue,
    ),
    home: HomePage(),
);
// ...

Next Step: Use Complex Objects instead of Number

Since this is a rudimentary example we have not used a complete API. But streams provide a really good way to allow continuous chunk of data flowing through and only rebuilding the app when a value is updated. This method allows you to track values in real time without needing your user to refresh manually. This can be used in a wide variety of applications such as Social Apps, Live Sports Scores, etc.

The code for the final application can be found here:

JSON Web Tokens (Part 1)

Ram Nad — Tue, 04 Feb 2020 10:01:54 +0000

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

In this post I would like to explain how can we use JWTs for authentication in web applications. In the next part, we will be using NodeJS, Express and jsonwebtoken library for implementing a simple JWT based authentication. Note that, we would use the word system and server interchangeably.

So, a JWT looks typically like this:

Image Source: jwt.io

So, this token can be broken down into 3 parts each separted by a .(dot)

Header (Red colour)
Payload (Pink colour)
Signature (Light Blue colour)

The header and payload sections are just normal JSON strings that is encoded in base64. Now, there is a difference between encoding and encryption. Encryption is when you use a secret key to transform message into a cipher which can only be transformed back to original message if you have the key. But in encoding, we just transform the message into a format that is easy to transfer between computers. Anyone with an encoded message can transform it back and read its content(there is no key involved).

If you use a base64 decoder for decoding the header or payload section here is what you get,

{ "alg": "HS256", "typ": "JWT" }

{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }

Third and final part, signature is also base64 encoded but if you try to decode it, you would get a gibberish text.

Header

Header section contains some information about the nature of this token. For example, in the particular token above, typ contains information about the type of this token(which is JWT) and alg says that the algorithm used to sign this token that is HMCASHA256.

Note: We will explain what does sign means later in this post. But for now you can take the analogy of signature that people do on documents to say that I have verified it and I approve of it.

Payload

Payload section contains of a set of claims that a party makes with this token. So, the contents of payload section says when, where, why and by whom this token can be used. Again continuing with the example given, sub stands for subject and it contains information about whom is this token concerned with, name is evidently name of the person and iat means issued at, It is Unix timestamp of the moment when this token was issued.

Side Note: Unix Timestamp is number of seconds that has passed since January 1, 1970. considering that every day has 86400 seconds. Also since this is calculated relative to UTC, it is same for all computers around the world.

Side Note: You will come across names John Doe quite frequently if you read posts like this. This is the frequently used name to refer to a male whose name is not known or is being concealed. Jane Doe is used for females.

Now there are certain standard claims that is specified in RC 7519 for a particular purpose:

iss (issuer): Issuer of the JWT
sub (subject): Subject of the JWT (the user)
aud (audience): Recipient for which the JWT is intended
exp (expiration time): Time after which the JWT expires
nbf (not before time): Time before which the JWT must not be accepted for processing
iat (issued at time): Time at which the JWT was issued; can be used to determine age of the JWT
jti (JWT ID): Unique identifier; can be used to prevent the JWT from being replayed (allows a token to be used only once)

Now before we get to the third and most important part of JWTs, let us first consider a scenerio where JWT is used for user authentication.

Consider how user's are authenticated normally(that is without the use of tokens). So, when user logs in for the first time, he gives an username and password. The system checks if username and password is correct. If it matches with the database records, then systems creates a random string (called session identifier), stores it in the database along with user's identification and sends the identifier back to the user.(It is usually send as a cookie, but that does not matter for our disscussion)

Next time when user visits the website, he sends this identifier along with the request. When system recieves this identifier, it matches that with information in the database. If the identifier matches, then the system knows that user is genuine. To log out a user, system simply deletes this identifier from the database.

Image Source: Medium

Now why does the system believes in this identifier? The reason is that this identifier is usually a long and random string. So, it is not possible for anyone to know it. Also if someone tries to randomly generate all the possible tokens, it might take him 10¹⁸ billion years to test every combination.(Assuming that identifier is 128 bits long and it takes 1 second for testing 10,000 strings) For reference, current age of universe is 13.8 billion years.

There are few problem with this session based approach though. First one which is that for every request the system needs to hit database to check if session identiifer is valid. (This is problematic because database access takes time) Other similar but related problem is with microservice architecture. In this case, identifiers need to be stored in a central server, because different servers need to access this information.(Therefore, this would take even more time and is much more difficult to manage) Both of this problems can be solved with the help of the JWTs.

So in the case of JWTs, when user first logs in the system generates one of this tokens and send it to the user. The claims that system usually put in this token is sub to identify the user and other details like the user's privilege level. So, when user makes a request to the server, then system checks if the token is well formed JWT and just by decoding the payload section it can verify the user which this token identifies.

Image Source: Medium

Now, the only problem is anyone can generate this token. (Remember that header and payload are just encoded) So, anyone in this world can generate a token containing anyone else's identification and send it to the server. The system would then not be able to distinguish wether the token came from the right person or someone else. This is the place where the signature comes into picture.

Signature

Signature is used to verify that this token (JWT) is issued only by the server and no one else could generate it.

The idea is very simple. Each system has a long and unique secret key with itself. This key cannot be guessed by anyone else. (Because of similar reasons of session identifier) When the system generates a token it then sends it through a Message Authentication Code Algorithm(HMACSHA256 is one of them. There are many others) along with the secret key. Now this algorithm gives a pattern of bits as its result. This bit pattern is then encoded into base64 format to form the signature.

The bit pattern(which we will call signature from now) given out by the algorithm is not random but it has two important properties.

Given the signature, one cannot guess the value of secret key or the contents of the message.(This is to say that the algorithm computes a one-way function)
Second if we change the contents of message or the secret key even slightly the signature would change completely.

This two properties make sure that only way to guess the correct signature for any given message is to randomly try all possible combination. (Which would again take 10¹⁸ billion years) Therefore it is highly unlikely that anyone would be able to do it.

Note: Scientists say that sun would burn out within 4-5 billion years from now.

Now, when someone sends this token back to the server, it just generates the signature again using the same key and algorithm. If the resulting signature matches with the signature that came with the token, then server can be pretty sure that this is a valid token.

Note: For this particular HMACSHA256 algorithm the signature is 256 bits long. If you want a rough idea of how unlikely it is to guess a signature watch this 3Blue1Brown video.

I hope that you have an idea of how JWT is used. I feel that this post is getting a bit long. So, we will continue with how to implement JWT using NodeJS in next part of this post.

You can verify the example signature using jwt.io. Just enter the header and payload given above. The secret I used is hello.

References:

Paytm Payment Gateway Integration in Django

Ashutosh Chauhan — Sun, 02 Feb 2020 15:27:06 +0000

Paytm Payment Gateway Integration in Django

Synopsis: This is a great way to learn how to integrate payments in your Django application. The official docs from Paytm are here.

Note: You would require a Paytm Merchant Account to be able to use the Payment Gateway

The process of sending the request to the gateway is mentioned in the following document:

Image Source: Paytm

We will create an Django App from scratch to achieve our goal.

Step 0: Setting up the Project

First we'll create a virtual environment for out project.$

# Install Django & virtualenv if not already
$ pip install Django virtualenv
# create a new Django project
$ django-admin startproject pay2me
$ cd pay2me
# Initialize a new virtualenv with Py3 since Python 2 is dead
$ virtualenv env --python=python3
# Activate the virtual environment and intall Django
$ source ./env/bin/activate
(env)$ pip install Django

You can use the command $ source ./env/bin/activate to activate the virtual environment.

We would use the default Django User models for the authentication system to save time but you can use custom User model if you wish.

Now let's add login view to our project. open pay2me/urls.py and add entry to login/logout views.

from django.contrib.auth.views import LoginView

urlpatterns = [
    path('admin/', admin.site.urls),
    path('login/', LoginView.as_view(), name='login'),
]

Now to make login and logout pages we first have to migrate our changes and create a superuser. Run the following commands in the terminal.

(env)$ python manage.py makemigrations
(env)$ python manage.py migrate
(env)$ python manage.py createsuperuser

Now we can run the server by executing python manage.py runserver and visit http://localhost:8000/login to see the login page.

The page will not load since the login page template is missing so we will create a template for LoginView. Create a directory templates in the project's root directory and another directory registration in templates. Now add a file login.html in the registration directory and add the following to it.

<!DOCTYPE html>
<head>
    <title>Login</title>
</head>
<body>
    <h2>Login</h2>
    <form method="post">
        {% csrf_token %}
        {{ form.as_p }}
        <button type="submit">Login</button>
    </form>
</body>
</html>

The login page contains contain a form and a csrf_token which will be provided by the LoginView so we don't have to worry about it.

We would also have to modify pay2me/settings.py. Open the file, Navigate to the TEMPLATES setting and add 'templates' in the DIRS list, it should look like this:

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': ['templates'],
        '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',
            ],
        },
    },
]

This would help Django locate our registration/login.html template.

Since the template is all set, now restart the server and go to http://localhost:8000/login and the login form should look like this:

Let's continue to the next step.

Step 1: Making the UI

Since we are keeping this concise we will only have two pages:

Payment page : Where we will enter the amount we have to pay
Callback Page : The response received from Paytm carrying payment status

Lets start by making a new app to organize these features.

(env)$ python manage.py startapp payments

First of all let's add the payments app to the project. To do that we will add 'payments' in the INSTALLED_APPS list in pay2me/settings.py .

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'payments',
]

Now lets add the template files pay.html and callback.html in templates/payments in the payments app directory.

pay.html

<!DOCTYPE html>

<head>
    <title>Payment Home</title>
</head>

<body>
    <h2>Payment Home</h2>
    {% if error %}
    <h3>{{ error }}</h3>
    {% endif %}
    <form method="post">
        {% csrf_token %}
        <label for="username">Username: </label>
        <input type="text" name="username" required>
        <label for="password">Password: </label>
        <input type="text" name="password" required>
        <label for="amount">Amount: </label>
        <input type="number" name="amount" value="100">
        <input type="submit" name="submit" value="Submit" required>
    </form>
</body>

</html>

callback.html

<!DOCTYPE html>
<head>
    <title>Callback</title>
</head>
<body>
    <h2>Callback Messsage: </h2>                    <br>
    <h3> Checksum Verification: {{ message }} </h3> <br>
    MID: {{ MID }}                                  <br>
    TXNID: {{ TXNID }}                              <br>
    ORDERID: {{ ORDERID }}                          <br>
    BANKTXNID: {{ BANKTXNID }}                      <br>
    TXNAMOUNT: {{ TXNAMOUNT }}                      <br>
    CURRENCY: {{ CURRENCY }}                        <br>
    <h3> STATUS: {{ STATUS }} </h3>                 <br>
    RESPCODE: {{ RESPCODE }}                        <br>
    RESPMSG: {{ RESPMSG }}                          <br>
    TXNDATE: {{ TXNDATE }}                          <br>
    GATEWAYNAME: {{ GATEWAYNAME }}                  <br>
    BANKNAME: {{ BANKNAME }}                        <br>
    BIN_NAME: {{ BIN_NAME }}                        <br>
    PAYMENTMODE: {{ PAYMENTMODE }}                  <br>
    CHECKSUMHASH: {{ CHECKSUMHASH }}
</body>
</html>

The Payment page asks for user login information and payment amount, whereas Callback page shows the values of a lot of parameters which would be provided by Paytm upon completion of payment.

Step 2: Make Transaction model

Since any payment related application would require transactions we would create a Transaction model in payments/models.py as follows:

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

User = get_user_model()

class Transaction(models.Model):
    made_by = models.ForeignKey(User, related_name='transactions', 
                                on_delete=models.CASCADE)
    made_on = models.DateTimeField(auto_now_add=True)
    amount = models.IntegerField()
    order_id = models.CharField(unique=True, max_length=100, null=True, blank=True)
    checksum = models.CharField(max_length=100, null=True, blank=True)

    def save(self, *args, **kwargs):
        if self.order_id is None and self.made_on and self.id:
            self.order_id = self.made_on.strftime('PAY2ME%Y%m%dODR') + str(self.id)
        return super().save(*args, **kwargs)

The transaction model is defined in such a way that the order_id is unique and generated based on date of transaction. We can see there is a checksum which will store the checksum generated by python file.

We overrode the save method to automatically generate order_id from the date and time of the transaction.

Let's run the migrations again to add the Transaction model in the database.

(env)$ python manage.py makemigration
(env)$ python manage.py migrate

Step 3: Adding Paytm Settings

Add the following settings to pay2me/settings.py :

PAYTM_MERCHANT_ID = '<your_merchant_id>'
PAYTM_SECRET_KEY = '<your_paytm_secret_key>'
PAYTM_WEBSITE = 'WEBSTAGING'
PAYTM_CHANNEL_ID = 'WEB'
PAYTM_INDUSTRY_TYPE_ID = 'Retail'

Step 4: Create Views for Payments

Paytm has provided a repository for the checksum generation code here but the code is using a deprecated library pycrypto, the following code contains the modified file compatible with the latest pycryptodome library. So download the file and save it in your payments app with file name paytm.py.

Now lets begin the create the initiate_payment view that would receive the username, password and amount. Open payments/views.py and add the following code.

from django.shortcuts import render
from django.contrib.auth import authenticate, login as auth_login
from django.conf import settings
from .models import Transaction
from .paytm import generate_checksum, verify_checksum


def initiate_payment(request):
    if request.method == "GET":
        return render(request, 'payments/pay.html')
    try:
        username = request.POST['username']
        password = request.POST['password']
        amount = int(request.POST['amount'])
        user = authenticate(request, username=username, password=password)
        if user is None:
            raise ValueError
        auth_login(request=request, user=user)
    except:
        return render(request, 'payments/pay.html', context={'error': 'Wrong Accound Details or amount'})

    transaction = Transaction.objects.create(made_by=user, amount=amount)
    transaction.save()
    merchant_key = settings.PAYTM_SECRET_KEY

    params = (
        ('MID', settings.PAYTM_MERCHANT_ID),
        ('ORDER_ID', str(transaction.order_id)),
        ('CUST_ID', str(transaction.made_by.email)),
        ('TXN_AMOUNT', str(transaction.amount)),
        ('CHANNEL_ID', settings.PAYTM_CHANNEL_ID),
        ('WEBSITE', settings.PAYTM_WEBSITE),
        # ('EMAIL', request.user.email),
        # ('MOBILE_N0', '9911223388'),
        ('INDUSTRY_TYPE_ID', settings.PAYTM_INDUSTRY_TYPE_ID),
        ('CALLBACK_URL', 'http://127.0.0.1:8000/callback/'),
        # ('PAYMENT_MODE_ONLY', 'NO'),
    )

    paytm_params = dict(params)
    checksum = generate_checksum(paytm_params, merchant_key)

    transaction.checksum = checksum
    transaction.save()

    paytm_params['CHECKSUMHASH'] = checksum
    print('SENT: ', checksum)
    return render(request, 'payments/redirect.html', context=paytm_params)

Lets understand the view part by part:

def initiate_payment(request):
    if request.method == "GET":
        return render(request, 'payments/pay.html')

The first step is to check the method of the request. When the request method is GET then we will just return the payment page.

try:
        username = request.POST['username']
        password = request.POST['password']
        amount = int(request.POST['amount'])
        user = authenticate(request, username=username, password=password)
        if user is None:
            raise ValueError
        auth_login(request=request,     user=user)
    except:
        return render(request, 'payments/pay.html', context={'error': 'Wrong Account Details or amount'})

Then we verify the username and password entered by the user in the form and tries to log in the user. If the login details are invalid then the view returns back the login page with an error message.

    transaction = Transaction.objects.create(made_by=user, amount=amount)
    transaction.save()
    merchant_key = settings.PAYTM_SECRET_KEY

Next we create a Transaction object for our user and get our merchant key from settings.py.

    params = (
        ('MID', settings.PAYTM_MERCHANT_ID),
        ('ORDER_ID', str(transaction.order_id)),
        ('CUST_ID', str(transaction.made_by.email)),
        ('TXN_AMOUNT', str(transaction.amount)),
        ('CHANNEL_ID', settings.PAYTM_CHANNEL_ID),
        ('WEBSITE', settings.PAYTM_WEBSITE),
        # ('EMAIL', request.user.email),
        # ('MOBILE_N0', '9911223388'),
        ('INDUSTRY_TYPE_ID', settings.PAYTM_INDUSTRY_TYPE_ID),
        ('CALLBACK_URL', 'http://127.0.0.1:8000/callback/'),
        # ('PAYMENT_MODE_ONLY', 'NO'),
    )
    paytm_params = dict(params)

Then we create a dictionary for all the settings for the Paytm Checksum Generator to create a checksum.

    checksum = generate_checksum(paytm_params, merchant_key)

    transaction.checksum = checksum
    transaction.save()

    paytm_params['CHECKSUMHASH'] = checksum

Next after generating the checksum we add the checksum to the paytm_params dictionary as well as the Transaction object.

    return render(request, 'payment/redirect.html', context=paytm_params)

At the end we return the redirect page.

Step 5: Create a Redirect Page

Create a redirect page in payments/templates/payments/redirect.html:

<html>
    <head>
        <title>Merchant Check Out Page</title>
    </head>
    <body>
        <h1>Please do not refresh this page...</h1>
        <form method="post" action="https://securegw-stage.paytm.in/order/process/" name="f1">
            <table>
                <tbody>
                    <input type="hidden" name="MID" value="{{ MID }}">
                    <input type="hidden" name="WEBSITE" value="{{ WEBSITE }}">
                    <input type="hidden" name="ORDER_ID" value="{{ ORDER_ID }}">
                    <input type="hidden" name="CUST_ID" value="{{ CUST_ID }}">
                    <input type="hidden" name="INDUSTRY_TYPE_ID" value="{{ INDUSTRY_TYPE_ID }}">
                    <input type="hidden" name="CHANNEL_ID" value="{{ CHANNEL_ID }}">
                    <input type="hidden" name="TXN_AMOUNT" value="{{ TXN_AMOUNT }}">
                    <input type="hidden" name="CALLBACK_URL" value="{{ CALLBACK_URL }}">
                    <input type="hidden" name="CHECKSUMHASH" value="{{ CHECKSUMHASH }}">
                </tbody>
            </table>
        <script type="text/javascript">
            document.f1.submit();
        </script>
        </form>
    </body>
</html>

The redirect page contains a simple form that contains the fields from the dictionary. We used the javascript code to automatically post the form to the paytm gateway.

Step 6: Create the Callback View

The callback view is the view which would be called when paytm will respond with the status of the Transaction.

Add the following callback view in the payments/views.py

from django.views.decorators.csrf import csrf_exempt

@csrf_exempt
def callback(request):
    if request.method == 'POST':
        received_data = dict(request.POST)
        paytm_params = {}
        paytm_checksum = received_data['CHECKSUMHASH'][0]
        for key, value in received_data.items():
            if key == 'CHECKSUMHASH':
                paytm_checksum = value[0]
            else:
                paytm_params[key] = str(value[0])
        # Verify checksum
        is_valid_checksum = verify_checksum(paytm_params, settings.PAYTM_SECRET_KEY, str(paytm_checksum))
        if is_valid_checksum:
            received_data['message'] = "Checksum Matched"
        else:
            received_data['message'] = "Checksum Mismatched"
            return render(request, 'payments/callback.html', context=received_data)
        return render(request, 'payments/callback.html', context=received_data)

The callback view receives a post request from the paytm server. Then we retrieve the received data in a dictionary and and verify the checksum sent from paytm as to prevent forged requests. We then return the page with the details of the transaction and the message.

Step 7: Creating the routes.

As the final step, Let's make the URLs for the views and get this long tutorial over. Create/open urls.py in the payments app. Add the following routes.

from django.urls import path
from .views import initiate_payment, callback

urlpatterns = [
    path('pay/', initiate_payment, name='pay'),
    path('callback/', callback, name='callback'),
]

Now let's include these URLs in the pay2me/urls.py

from django.urls import include
urlpatterns = [
    # include 
    path('', include('payments.urls'))
]

Test Run: Try out a Payment

Now let's run python manage.py runserver and go to http://localhost:8000/pay/ to create a payment.

Fill the form.

This will redirect to the paytm payment gateway. Use any dummy payment methods.

You can also choose the status (Success/Failure) of the Transaction

Then you will finally land on the callback page which will show you the status of the transaction.

Github: Sample

Here is the link to the above sample code on Github.